Part 8 · 2 chapters · ~20 min

Rendering, Layers and Coverage

The Rendering drawer's live overlays (paint flashing, layout shift regions, layer borders, scrolling performance issues, the fps meter) and its emulations, the Layers panel with per-layer memory and compositing reasons, and Coverage as the measure of bytes shipped against bytes run.

22

The Rendering drawer

live overlays
  1. Paint flashing: green over every repainted region, per frame. A whole-page flash on hover is the pathology; a flash larger than the element is its shadow or filter; no flash during an animation means it composites. The cheapest paint diagnostic there is.
  2. Layout Shift Regions: blue over every element that moved between frames. Reload with it on: each flash is a CLS source to attribute; the Performance panel's Layout Shifts lane gives the score.
  3. Layer borders: orange outlines for compositor layers, cyan grid for raster tiles. One orange box is cheap; one per list row is the explosion; a will-change element shows its own.
  4. Scrolling performance issues: red over elements that force main-thread scrolling (non-passive wheel or touch listeners, repainting fixed elements), with the reason in a tooltip.
  5. Frame Rendering Stats: an fps meter and GPU memory; the before-and-after number for any rendering change.
emulations
  1. CSS media: prefers-color-scheme, prefers-reduced-motion, forced-colors, print. Vision deficiencies: protanopia, deuteranopia, tritanopia, achromatopsia, blurred vision: an accessibility review in one click. "Disable local fonts", "Disable AVIF / WebP" to test fallbacks.
the order
Paint flashing for "why does hovering spin the fan"; shift regions for "what moved"; layer borders for "what is composited"; scrolling issues for "why does scrolling stick"; the fps meter as the number. Then a Performance recording for the numbers behind what you saw.
go to the lab
  1. /paint/hover-shadow with Paint flashing on: hover the cards; the green region is larger than the card (the blur). Enable the fix: no flash.
  2. /perf/cls-hunt with Layout Shift Regions on: trigger the shifts and count the blue flashes; name each source before opening Performance.
  3. /paint/non-passive-scroll with Scrolling performance issues on: the box is red with "has a non-passive wheel listener"; toggle passive: the red goes.
  4. /paint/transform-vs-left with Paint flashing and the fps meter: the top track flashes every frame; the bottom never; read the fps under 6× CPU throttling for each (comment one out with H in Elements).
THE RENDERING DRAWER
live overlays for paint, layout shift, layers, scrolling and more, with no recording
swipe the figure sideways, or tap expand for full screen
1/6
paint flashing
Paint flashing: every repaint flashes its region green for a frame. Hover, scroll, type, animate: whatever flashes is being repainted, and the size of the flash is the cost. A whole-page flash on a hover is the pathology; a flash larger than the element is a shadow or a filter extending the region; no flash during an animation means it composites.
23

Layers and Coverage

Layers
  1. A tree of compositor layers, a rotatable 3D view, and per-layer details: size, memory estimate (width × height × 4 bytes), paint count, slow-scroll regions, and the compositing reasons: a will-change hint, a 3D transform, a video, an active accelerated animation, a composited scroll container, or "overlaps another composited layer" (the assumed-overlap chain: one promoted element forces the ones stacked above it into layers).
  2. The explosion, in numbers: 400 rows with will-change: transform at 1200 × 40 px is 192 KB each, ~77 MB of GPU memory, and a Composite Layers event that grows with the count; without the hint, one layer of ~2 MB. Promote what moves; nothing else (the Browser course part 5).
Coverage
  1. Record (or reload and record), use the page across several routes, stop. Per file: total and unused bytes with a red bar; click to open in Sources with red marks on lines that never ran and blue on lines that did. Export to JSON for a diff across builds.
  2. What it finds: a vendor chunk 92% unused on this route (split it: the Architecture course), a CSS file 90% unused everywhere (a dead-CSS audit), a polyfill bundle 100% unused in a modern browser (conditional loading). "Unused" means not needed for this path, not useless: record a realistic session before deleting anything.
  3. The pairing: Coverage with the Network panel's Size column is "bytes shipped versus bytes needed"; with the Performance panel's Evaluate Script events it is "parse and compile cost of bytes that never ran". Streaming compilation (the Browser course part 2) reduces that cost; not shipping removes it.
go to the lab
  1. /paint/layer-explosion: open Layers with the explosion on; count the layers and sum the memory in the details; toggle the fix and read the tree again. Then record a scroll in Performance for each and compare the Composite Layers events.
  2. Open Coverage, reload and record on the lab's home, then visit six routes and stop. Read the lab bundle's unused percentage after one route versus six; open it in Sources and find a route component in red that you did not visit.
  3. On /style/theme-toggle, record Coverage for the toggle alone: the inline <style> rules used versus unused show the dark theme's selectors going blue only after the click.
LAYERS AND COVERAGE
every compositor layer with its memory and reason; every byte of CSS and JS by whether it ran
swipe the figure sideways, or tap expand for full screen
1/6
the Layers panel
The Layers panel: a tree of layers on the left (the root, then each composited element), a 3D view in the middle (rotate to see stacking), and details on the right for the selected layer: size, compositing reasons, memory estimate (width × height × 4 bytes), paint count, and slow-scroll regions. Select a layer and the page highlights it.