Profiling the browser
Core details
Goal: decide if the problem is script, layout, paint, network, or memory—then change one thing and re-measure.
Chromium Performance workflow (repeatable)
- Record one clean interaction (no extra extensions).
- Identify long tasks (>50 ms blocks)—they delay input and frame delivery.
- Bottom-up: sort JS by self time; jump to call tree for hot stacks.
- Markers for Recalculate Style, Layout, Paint—map to code that reads geometry after writes or heavy selectors.
- Network track: LCP candidate, priority, blocking resources.
- Frames view: dropped frames vs GPU composite cost.
Common classifications
| Signal | Often is |
|---|---|
| Long purple Layout bars | forced sync layout / thrash |
| Long Script | main-thread compute; consider chunk or worker |
| LCP late | slow TTFB, render-blocking CSS/JS, huge image without priority |
| Memory sawtooth | allocation churn; snapshot diff for dominators |
Understanding
The browser batches work until it must paint—or until JS forces layout. Profiling without this model leads to “memo everything” theater while the real issue is getBoundingClientRect in a scroll handler.
Lab (Lighthouse) catches regressions; CrUX validates field reality on real devices and networks.
Senior understanding
| Trap | Recovery |
|---|---|
| Optimizing JS while layout dominates | batch reads/writes; reduce invalidation |
will-change everywhere | GPU memory pressure; validate Layers panel |
| Ignoring INP / interaction | long tasks block input responsiveness |
Diagram
Loading diagram…
See also
Last updated on
Spotted something unclear or wrong on this page?