The short answer
Players tolerate simple graphics and do not tolerate stutter. Consistency of frame rate matters more than peak detail, and download size decides whether they ever start.
Both are budgeting problems, best set before building rather than optimised afterwards.
Set the budgets first
| Budget | Why |
|---|---|
| Total download | Decides how many people wait |
| Time to interactive | Decides how many stay |
| Frame rate floor | Stutter is worse than low detail |
| Memory ceiling | Exceeding it crashes the tab |
| Battery | Heat throttles the device mid-session |
The memory row catches people out on older devices. A browser tab that is terminated looks like a broken game, not a device limit.
What actually causes stutter
- Allocating objects during play, which triggers collection pauses.
- Too many separate draw calls rather than batched ones.
- Large textures being uploaded mid-game.
- Layout or DOM work happening inside the frame loop.
- Doing expensive work every frame that could be done occasionally.
Point one is the most common and the least visible. Pooling objects and reusing them removes a whole class of intermittent pauses.
Cut the download
- Compress and correctly size every texture
- Load later levels or assets only when needed
- Strip unused library code from the bundle
- Prefer generated or procedural content over stored assets where it suits
- Start the game while remaining assets load in the background
The last one changes the perceived wait more than any size reduction. Playing during loading is better than a faster loading bar.
Test on the wrong device deliberately
Keep an ordinary, several-year-old phone for testing and treat it as the target. If it runs well there it runs well everywhere.
Also test with the battery low and the device warm, because throttling changes behaviour substantially and that is a normal playing condition.