What is it?
A browser receives HTML, CSS, and JavaScript and turns them into the page on your screen. It builds a tree of elements (the DOM), applies styles to each one, runs JavaScript that may change the tree, computes layout, and paints pixels. Every site you'll ever build is some flavor of this same pipeline.
Why it matters
Most performance problems live inside this pipeline. If you understand the order — parse, style, layout, paint — you can read a slow page like a mechanic reads an engine. You stop guessing and start naming what's wrong.
What to learn
- The DOM: what it is and how the browser builds it
- The CSSOM and how style cascades resolve
- The render tree: what makes it into the picture and what doesn't
- Layout vs paint vs composite: three different costs
- The main thread and why blocking it freezes interactions
- The critical rendering path: what has to finish before first paint
Common pitfall
Animating layout properties (width, height, top, left) and wondering why
it stutters. Layout is expensive — every frame the browser has to recalc
positions. Stick to transform and opacity; they only touch the
compositor.
Resources
Primary (free):
- web.dev — How browsers work · docs
- MDN — Critical rendering path · docs
- Inside look at modern browsers — Kosamia (Google) · article
Practice
Open a real production website in Chrome devtools. Switch to the Performance tab and record a page load. Identify one of each: a Style Recalc, a Layout, a Paint, and a Composite. Done when you can point at each step in the timeline and explain what triggered it.
Outcomes
- Name the four phases of the rendering pipeline in order.
- Explain why CSS transforms perform better than layout-changing properties.
- Read a Performance panel timeline and identify the main blocking work.
- Decide whether a UI bug is a layout issue or a paint issue.