From “it works” to “it ships”

A game that runs at 60 fps on your dev machine can crawl on a phone, lose progress on refresh, and never reach a second player. This lesson covers the three engineering disciplines that turn a prototype into a real product: profiling & optimization, saving state, and basic online multiplayer with WebSockets. This is a concept lesson — the techniques apply to every game in the track.

Measure first: the DevTools Performance panel

Never optimize on a hunch. Open DevTools, go to the Performance tab, record a few seconds of gameplay, and look at the flame chart. You are hunting for three things: long scripting bars (your update logic), long rendering/painting bars (canvas draws), and frequent GC sawtooth spikes in the memory timeline (garbage collection pauses). The performance.now() timer and console.time let you bracket suspicious code precisely.

profile.js

The 16.67 ms budget.

60 fps means each frame must finish in 1000/60 ≈ 16.67ms — including update, physics, render, AND the browser’s own compositing. If your code uses 14ms you have almost no headroom. Aim to keep your work under ~8–10ms.

Killing garbage-collection stutter

The number-one cause of micro-stutter in JS games is allocation in the hot loop. Every {x,y} literal, every arr.map(), every new vector object creates garbage that the GC must later collect, freezing the frame. The fixes: reuse objects, pool entities, and avoid array methods that allocate.

nogc.js

// BAD: allocates a new object every frame, every entity function update(e) { e.vel = { x: e.vel.x, y: e.vel.y + g }; } // GOOD: mutate in place — zero allocation function update(e) { e.vy += g; } // BAD in hot loop: creates intermediate arrays each frame bullets.filter(b => b.alive).forEach(draw); // GOOD: plain for-loop, no closures, no temp arrays for (let i = 0; i < bullets.length; i++) { const b = bullets[i]; if (b.alive) draw(b); }

Render hot-path optimization

Canvas drawing is often the real bottleneck. Key wins: batch state changes (set fillStyle once, draw many), cull off-screen entities, pre-render static or expensive art to an offscreen canvas once and blit it, and snap drawing coordinates to integers (sub-pixel positions force the browser to anti-alias, which is slower and blurrier).

render-opt.js

// Pre-render an expensive tile once into an offscreen canvas const off = document.createElement('canvas'); off.width = off.height = 32; const octx = off.getContext('2d'); drawFancyTile(octx); // runs ONCE function render() { for (let i = 0; i < tiles.length; i++) { const t = tiles[i]; if (!onScreen(t, cam)) continue; // cull ctx.drawImage(off, (t.x - cam.x) | 0, (t.y - cam.y) | 0); // |0 snaps to int, blits cached pixels } }

Tip.

Run Chrome’s Rendering tab with “Paint flashing” on to see exactly which regions repaint each frame, and “Frame Rendering Stats” for a live fps/GPU overlay. If everything flashes every frame in a mostly-static scene, you’re over-drawing.

Saving & loading with localStorage

Persisting progress is just serializing a plain-data snapshot to JSON and storing it under a versioned key. Keep a schema version so future updates can migrate old saves instead of crashing on them. Never store live class instances — store the data you need to reconstruct them.

save.js

localStorage is synchronous & small.

Writing blocks the main thread, so do NOT save every frame — save on level change, on pause, and via the visibilitychange event. The quota is only ~5MB per origin, and the data is plain text the player can edit, so never trust it for anti-cheat.

Basic online multiplayer with WebSockets

WebSockets give you a persistent, low-latency, bidirectional channel — ideal for real-time games. The browser opens a socket; a small server relays messages between players. Start with the simplest possible model: each client sends its own input/state, the server broadcasts to everyone, and each client renders the others.

net-client.js

server.js (Node + ws)

import { WebSocketServer } from 'ws'; const wss = new WebSocketServer({ port: 8080 }); let nextId = 1; wss.on('connection', (sock) => { const id = nextId++; sock.on('message', (buf) => { const msg = JSON.parse(buf); msg.id = id; const out = JSON.stringify(msg); wss.clients.forEach(c => { if (c !== sock && c.readyState === 1) c.send(out); }); // relay to others }); });

Smooth the network.

20 Hz updates look jerky if drawn raw. Interpolate remote players toward their latest received position each frame (lerp by ~0.2), and buffer a frame or two so a dropped packet doesn’t freeze them. This hides jitter without needing prediction.

Authoritative vs. trusting.

A relay server (above) trusts every client — fine for co-op or friendly games. For competitive play, the server must own the simulation and validate inputs, or players will cheat by sending fake positions. Start with a relay, graduate to authoritative when stakes rise.

🎮 Build This: Optimization / Online — Co-op Lobby

This EXTENDS a prior game (the top-down Zelda-like adventure or the twin-stick shooter are ideal) by profiling it and adding save + co-op. It does not start a new genre.

Record a Performance profile during heavy gameplay; identify your single worst scripting and rendering cost.
Eliminate hot-loop allocations: convert closures/maps to plain for-loops and mutate vectors in place. Re-profile to confirm GC sawtooth shrinks.
Cull off-screen entities and pre-render one expensive sprite to an offscreen canvas; snap draws to integers.
Add versioned save()/load() via localStorage; persist on level change and visibilitychange, with a migration path.
Stand up the Node ws relay server and connect two browser tabs; render the remote player as a second avatar.
Send state at 20 Hz and interpolate the remote player each frame so movement looks smooth.