A Browser Game Performance Checklist That Starts With Evidence

/01

Write down the moment that feels wrong

Choose a specific scene, action, and device before opening a profiler. For example: start a fresh session, enter the first arena, and trigger the same enemy wave. Record the build identifier, browser version, viewport, device, and whether the device has already been running the game. Save the exact steps beside the trace so another developer can reproduce the same workload.

Decide what improvement would matter for this game. An occasional pause during an aiming action deserves different treatment from a slightly slower optional menu. Keep startup, sustained gameplay, and repeated scene transitions as separate scenarios. A single average frame rate can hide a disruptive pause inside otherwise smooth play.

• Keep the baseline artifact available so you can compare the candidate with the same build settings.
• Use an actual target device when possible; desktop throttling is a useful investigation aid, not a substitute for device evidence.
• Record which measurements were unavailable instead of filling the report with guessed values.

/02

Separate loading cost from runtime cost

Measure a fresh load and a repeat visit independently. Identify when the page appears, when useful game content appears, and when input actually works. For this audit, define readiness as a visible, responsive playable state. A loading bar reaching its end is only a UI event unless the game can proceed.

Inspect which resources are required before that first interaction. Ask whether the first level needs the entire soundtrack, every cosmetic, or the next chapter’s textures. Any proposed deferral should include its later loading behavior: reducing startup time is not useful if entering the next room reliably stalls. Keep an explicit list of resources whose absence would make the first scene incorrect.

/03

Trace the expensive window before changing code

Chrome’s Performance panel can capture runtime activity and connect a visible slowdown with work on the main thread. Record the smallest interval that contains the problem, then inspect the work around the hitch. The official Chrome walkthrough explains the recording and frame-analysis controls; their exact appearance can differ across versions.

Turn the trace into a hypothesis tied to an owner. If an enemy spawn coincides with repeated asset parsing, investigate that path. If opening a DOM-based inventory coincides with expensive layout work, inspect the menu’s reads and writes. If rendering appears expensive, gather renderer-specific evidence before changing image quality. A busy JavaScript function and a GPU bottleneck require different interventions.

/04

Check time, input, and background behavior

MDN documents that requestAnimationFrame generally follows the display refresh rate and should use elapsed time when calculating animation progress. Check whether the game accidentally makes movement or animation speed depend on the number of rendered frames. Keep any existing fixed-step simulation rules intact while investigating; changing simulation timing can alter collision outcomes and game balance.

Switch away from the game and return during the same test. The Page Visibility API exposes document visibility, while browsers can pause animation callbacks and throttle timers in the background. Decide how your game handles that gap: pause local play, discard stale input, and resume from a coherent state. An online game may require reconciliation with its server instead. Verify that returning does not create a giant movement step or leave a button logically pressed.

/05

Repeat the boundary where memory should settle

Play, return to the menu, and start again several times using the same route. Look for a trend after comparable cleanup points, rather than treating every temporary increase as a leak. Chrome’s memory tools offer heap snapshots and allocation recordings for examining retained JavaScript objects and detached DOM elements.

Connect a suspicious retained object to the code that owns its lifetime. Scene transitions, event listeners, timers, audio objects, and caches are useful places to investigate. JavaScript heap measurements do not describe every resource a browser game uses, so keep GPU or engine memory questions separate when the available tools cannot answer them. Releasing everything indiscriminately can also make reloads slower; document the intended lifetime before changing it.

/06

Give the agent one hypothesis and one acceptance check

A useful AI handoff includes the reproducible steps, artifact identity, trace location, suspected owner, allowed change, and the evidence required afterward. Ask for the smallest justified intervention. Keep screenshots and recordings free of unrelated personal information before sharing them with any tool.

Run the same scenario against the candidate and the baseline under comparable conditions. Repeat enough times to see whether the apparent difference survives normal variation, and inspect gameplay correctness as well as timing. Preserve changes only when the evidence supports the result. If the result is inconclusive, keep that uncertainty in the report and choose the next measurement.

Scenario: first arena, same enemy wave, target mobile browser
Evidence: baseline build ID, recording, device and browser details
Question: which owned operation explains the spawn hitch?
Change scope: the confirmed hot path only
Acceptance: repeat the scenario, compare traces, verify gameplay