Performance of a web game

Ask for numbers, not adjectives. "It lags on my phone" starts with questions, not a change: which device, how many frames a second, how many milliseconds of JS in a frame, how many draw calls.

Running the game is on request. Measuring with perf.mjs, the probe on a phone, screenshots and playthroughs take time and a running game: do them only when the developer asks to check, measure or profile performance. Otherwise, apply sections 2 to 4 as you write and review the code (the order of fixes, the draw-call habits, the 60 fps cap, the warm-up rule), and say what stays unmeasured. When the developer has asked for a measurement, measure before and after every change on the same setup, and revert a change that doesn't move the numbers.

1. Measure, after the warm-up (when asked)

The first 5–10 seconds are not the game's real speed: shaders compile and the first meshes are built and uploaded. The same phones reach a normal frame rate afterwards. Never judge performance inside that window.