Create a repeatable stress scene
Build a test state with a known number of moving objects, overlapping effects, and text labels. Capture a recording or fixed seed so each run presents roughly the same work. Compare an empty-scene baseline with the crowded scene, then inspect whether time is spent in JavaScript updates, canvas drawing, image decode, or style and layout work.
If drawing dominates, test batching similar paths, reducing unnecessary state changes, or rendering only regions that changed. If update logic dominates, profile collision checks and object iteration instead. MDN's Canvas optimization guide describes these as options to evaluate, not universal switches that guarantee a speedup.
Change one cost and verify the result
Choose one suspected cost, such as repeatedly drawing a static background, cache that background in an offscreen canvas, and compare before and after using the same scene. Verify the visual output at different sizes and after a resize; caching can become incorrect if it uses stale dimensions or scales text differently.
Record the device, browser, scene, and action used for the comparison. A result from one machine is useful for diagnosing that run, but it does not establish performance for every browser or device. Retest the original interaction, because an optimization that improves a synthetic scene can still make input feel worse elsewhere.
Questions about canvas game performance
Should I redraw only changed pixels?
It depends on scene complexity and how costly full redraws are. Partial rendering adds bookkeeping and can create stale pixels around moving objects, so compare both approaches with the same reproducible scene.
Are canvas batching tips guaranteed to help?
No. They are useful hypotheses. Measure the target browser and workload, then keep a change only when it improves the observed bottleneck without breaking rendering.