From bytes to two trees
The HTML arrives as a byte stream. The browser decodes it to characters, tokenises those into start tags, end tags and text, and the tree builder turns the token stream into the DOM incrementally — the parser does not wait for the last byte, which is why a slow-streaming document can still show something early.
CSS is processed into a parallel structure, the CSSOM. It has to be separate because the cascade needs it to be: a declaration's winner depends on origin, specificity and order across every stylesheet, so no element's computed style is final until every stylesheet that applies has been parsed. The DOM and CSSOM are then combined into the layout tree (called the render tree in older material), which holds only the nodes that generate boxes. An element with display: none produces no box and is absent from that tree; visibility: hidden produces a box, occupies space, and is present.
What blocks what
These two are different failure modes and conflating them is the commonest sloppiness in the answer.
A stylesheet is render-blocking, not parser-blocking. The parser carries on building the DOM behind it, but the browser will not paint content until pending stylesheets have been fetched and parsed, because painting first would show unstyled text and then reflow it. So a stylesheet on a slow third-party host delays first paint even though the DOM was ready long ago.
A classic <script src> with no attribute is parser-blocking. The parser stops at that tag, fetches, executes, and only then resumes, because the script may call document.write. defer removes that: the fetch happens in parallel and execution is postponed until parsing is complete, in document order, just before DOMContentLoaded. async also fetches in parallel but executes at whatever moment the fetch completes, out of order, and can interrupt parsing. Module scripts are deferred by default.
The two interact in a way that catches people out. A classic script must wait for any stylesheet that is still loading, because the script might read a computed style and would otherwise see a value that is about to change. So one slow stylesheet in the head can stall a script placed well below it.
Style, layout, paint, composite
Once the trees exist, and again on every subsequent change, the browser runs a fixed pipeline.
Style resolves declarations into a computed value for every property on every element. Layout, also called reflow, works out geometry: box sizes and positions in the flow, which is inherently interdependent, since one element's width changes its siblings' positions. Paint rasterises the boxes into lists of drawing commands, grouped into layers. Composite hands those layers to the compositor, which places and transforms them and produces the frame, often on a separate thread or the GPU.
The stages are ordered, so invalidating an earlier one drags the later ones with it. Changing width invalidates layout, therefore also paint and composite. Changing background-color skips layout but still requires paint and composite. Changing transform on an element that already has its own compositor layer skips both layout and paint.
Which properties land where
Properties that feed geometry force layout: width, height, padding, margin, border-width, top/left/right/bottom, display, position, float, font-size, font-family, line-height, text-align, and the flex and grid sizing properties.
Properties that only change pixels within a box already sized force paint but not layout: color, background-color, background-image, box-shadow, border-radius, outline-color, visibility.
transform and opacity are the two that can be changed without layout or paint in every major engine, and they are the two you should be animating. Chromium can also run filter animations on the compositor, but treat that as an engine-specific extension rather than something to rely on cross-browser. The qualifier matters: compositor-only holds when the element has been promoted to its own layer. Without promotion, a transform change still means repainting the layer the element shares with its neighbours. will-change: transform is the declarative way to request promotion, and it is a hint with a real cost — every promoted layer consumes memory and compositing work, so applying it to a list of five hundred rows makes things worse, not better.
Why the read is what hurts
Style and layout are normally deferred: you can set a dozen properties in one function and the browser coalesces them into a single layout before the next frame. That batching is what makes DOM writes cheap.
Reading a geometry property destroys it. offsetWidth, offsetHeight, offsetTop, clientWidth, scrollTop, scrollHeight, getBoundingClientRect() and getComputedStyle() for a layout-dependent value must all return a correct answer now. If there are pending style or layout invalidations, the browser has no choice but to flush the pipeline synchronously before returning. That is a forced synchronous layout, and it is entirely caused by the read, not by the write in front of it. A write on its own is queued; a read on its own is nearly free; a read after a write pays for a whole layout.
Put that pair inside a loop and every iteration invalidates layout and then immediately demands it back, so one pass over n elements costs n layouts instead of one. That is layout thrashing, and it scales with the size of the invalidated subtree as well as with n, which is why it tends to be invisible on a ten-row test fixture and catastrophic on a real page.
( el boxes) {
el.. = el. + + ;
}
widths = boxes.( el.);
boxes.( {
el.. = widths[i] + + ;
});
The mistake that survives a code review
The fix that gets offered most often is "wrap it in requestAnimationFrame", and it does not work, because the scheduler was never the problem. A read-then-write pair inside a single rAF callback forces layout exactly as it did outside one. What fixes it is ordering: every read completes before the first write begins. requestAnimationFrame is useful in combination with that, because it puts the writes at the start of a frame where they will be flushed once, but on its own it just relocates the thrash.
The related half-answer is saying "transform is GPU-accelerated so it is free" without checking whether the element is on its own layer. When you need to be sure of either, record a performance profile and look at the frame: forced layouts are flagged in the trace, and the trace names the line of script that triggered them.
Writes are batched and reads are not. Any time a read of geometry sits after a write in the same synchronous block, you have bought a layout you did not need, and the fix is to reorder rather than to reschedule.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).