Mozilla's WebRender lifted janky 15 FPS pages to 60 FPS with game-engine rendering

Browsers had spent years getting smoother by doing less: invalidating only changed rectangles, caching pieces as layers, compositing them, and finally moving both jobs onto the GPU. On Mozilla Hacks in October 2017, Lin Clark explained why pages still janked. Layers cost memory and transfer time, and browsers have to guess how many a page needs. Too many layers fill memory and lag the compositor; too few mean a repainted layer is composited without anything changing, touching every pixel twice. Animating a background color forces a whole-layer repaint no matter what.

WebRender, Servo technology arriving in Firefox as Quantum Render, followed a different precedent: 3D game engines repaint every pixel of every frame and hold 60 FPS more reliably than browsers, on GPUs with hundreds or thousands of cores that shade pixels in parallel. So WebRender removed the paint/composite boundary. Layout output became a display list of high-level drawing instructions tied to no graphics API. WebRender's RenderBackend converted that list into batched GPU draw calls, and the GPU repainted the page's whole visible scene every frame, with no layer guessing.

Making whole-frame redraw affordable took work elimination. Off-screen items were culled before they reached the GPU. A render task tree planned the minimum number of expensive offscreen textures for filters and stacking contexts. Draw calls were batched to keep the GPU's parallel cores busy. Rendering was split into an opaque front-to-back pass that skipped covered pixels and a translucent back-to-front pass — z-culling, the article said, and a big win on typical pages. Text glyphs stayed a CPU job but were cached in a texture kept from frame to frame.

The goal was consistency, not just speed: no performance cliffs, smooth 60 FPS however large the display or however much of the page changed. The article reported that pages which chugged along at 15 FPS in Chrome or in the Firefox of the day ran at 60 FPS with WebRender, and framed the work as preparation for 4K displays and for WebVR, which renders a frame for each eye at 90 FPS.

Stop guessing layers: hand the GPU a high-level display list and repaint the whole page every frame, game-engine style

GPUs have hundreds to thousands of cores that shade pixels in parallel, so repainting the whole visible page every frame is the workload they were built for, not a CPU-sized job.

A retained display list is a small, API-agnostic description of the scene, so the CPU builds commands once and the RenderBackend can cull, order and batch them before any pixel work happens.

Whole-scene redraw removes the layer guess and its failure modes: no misjudged layer counts, no double handling of pixels, so frame times stop falling off performance cliffs.

Work elimination keeps redraw cheap: culling, fewer offscreen targets, batching and z-culling shrink what the GPU shades, while CPU-rendered glyphs live in a texture cache, not the per-frame path.

When incremental heuristics keep hitting worst-case cliffs, change the model: describe the whole scene once and let massively parallel hardware redraw it each frame

WebRender was not in the Firefox Quantum release that followed: Lin Clark wrote in the article's comments that it would not land until after Firefox 57, and the piece planned integration through 2018 under the Quantum Render project, with an early version already available behind a flag. The demo it linked showed pages that ran at 15 FPS in Chrome or in the day's Firefox running at 60 FPS with WebRender, and the explainer drew 853 points and 207 comments on Hacker News on October 10, 2017.