The rendering pipeline

From DOM to pixels

A browser does not draw a DOM node directly. It works through a rendering pipeline: it works out which rules apply, measures boxes, draws pixels, and puts finished surfaces together on screen.

These stages are connected, but they are not a promise that every change runs every stage. A text color change does not normally move a box. A width change can move many boxes. The property you change helps the browser decide what must be updated.

This follows From HTML to running script. That lesson explains how a document and its scripts arrive. This lesson begins once JavaScript or user input changes the page that the renderer will draw.

Style, layout, paint, and composite

Style calculation finds the CSS values that apply to an element. It combines browser defaults, your selectors, inherited values, and inline styles into values such as a color, display mode, width, and transform.

Layout measures boxes and places them. It answers questions such as how wide a card is, where its text wraps, and where the next card begins. Layout is also called reflow in many performance tools.

1const box = document.createElement("div");2box.style.width = "120px";3document.body.append(box);4console.log(box.offsetWidth);

Line 1 creates a box. Line 2 gives it a width. Line 3 attaches it to the document. Line 4 reads its measured width and prints 120. The read is useful because it connects a CSS value to a real layout result.

Paint draws pixels for visible parts: text, backgrounds, borders, shadows, and images. Compositing puts painted surfaces in their final order, clips them, and applies properties such as transforms and opacity.

Forced synchronous layout

Browsers try to delay rendering work so several changes can be handled together. A style write can mark layout dirty. That is normally helpful because the browser can wait until the next frame instead of measuring after every single change.

A forced synchronous layout happens when JavaScript asks for current geometry after making a change that may affect geometry. Values such as offsetWidth, getBoundingClientRect(), and some computed styles need an up-to-date answer.

1const box = document.createElement("div");2box.style.width = "120px";3document.body.append(box);4console.log(box.offsetWidth); // 120

Line 1 creates the element. Line 2 writes 120px. Line 3 makes the box part of the page. Line 4 asks for a number now, so the browser returns 120 after resolving the needed layout work.

This is not automatically a bug. A drag handle, a tooltip, or a positioning calculation may truly need current geometry. It becomes a problem when code makes the browser repeat that work many times in one update.

1const box = document.createElement("div");Run2box.style.width = "120px";3document.body.append(box);4const width = box.offsetWidth;5console.log(width);

Read and write without thrashing

Layout thrashing is an avoidable pattern: write a style, read geometry, write another style, then read geometry again. Each read can demand that the browser catches layout up before the loop continues.

1const cards = [...document.querySelectorAll(".card")];2for (const card of cards) {3  card.style.width = `${card.offsetWidth + 10}px`;4}

Line 1 collects cards. Line 3 reads offsetWidth and writes a new width in the same expression. With a larger list, the next card's read can force layout after the previous card's write. The exact browser work varies, but the pattern creates unnecessary pressure.

1const cards = [...document.querySelectorAll(".card")];2const widths = cards.map((card) => card.offsetWidth);3for (const [index, card] of cards.entries()) {4  card.style.width = `${widths[index] + 10}px`;5}

Line 2 reads the old widths before any new width is written. Lines 3 through 4 then make all writes together. The browser can usually process the grouped update at the next rendering opportunity instead of answering a fresh geometry question per card.

1const first = countLayouts(["write", "read", "write", "read"]);Run2const second = countLayouts(["read", "read", "write", "write", "frame"]);3console.log(first);4console.log(second);

1const first = countLayouts(["write", "read", "write", "read"]);2const second = countLayouts(["read", "read", "write", "write", "frame"]);3console.log(first);4console.log(second);

Layers and compositing

A layer is a separately composited surface the browser may create for an element or part of the page. A layer lets the compositor move, clip, or fade already-painted pixels without necessarily asking layout or paint to do the same work again.

For example, an element being transformed may be placed on a useful layer. will-change: transform is a hint that an element is likely to change. A transform animation can also lead the browser to prepare the right surface.

1.card {2  will-change: transform;3}

Line 1 chooses the card. Line 2 gives the browser a hint about a future transform. The code does not promise a layer, and it does not make every animation fast. It only gives the browser information it may use.

Too many layers waste memory because each surface needs backing storage. They can also add compositing work. Use a hint near an interaction you measured, then remove it when it no longer describes the page.

What triggers reflow and repaint

Property names provide a useful first guess. A change to width, height, top, or a font can change geometry, so the browser generally needs style, layout, paint, and composite work. The word reflow is another name for layout.

1const changes = [2  ["width", "layout, paint, composite"],3  ["background-color", "paint, composite"],4  ["transform", "often composite only"],5];6console.log(changes.map(([property, work]) => `${property}: ${work}`).join(" | "));

Line 1 creates three property examples. Lines 2 through 4 pair each one with likely work. Line 5 prints width: layout, paint, composite | background-color: paint, composite | transform: often composite only.

Color and background-color normally keep the same geometry but need new pixels, so they repaint. Transform and opacity can often be composite-only in most browsers, but filters, blending, clipping, descendants, and browser choices can change the real result.

Off-main-thread animation

The main thread runs JavaScript, event handlers, much of style and layout, and other page work. The compositor can often keep a prepared transform or opacity animation moving while a busy main thread is temporarily doing JavaScript.

This is why CSS transitions, CSS animations, and the Web Animations API are good fits for movement and fading when they animate transform or opacity. It is an opportunity, not a guarantee: keep the animated content simple and check a trace.

1const box = document.createElement("div");2box.style.width = "40px";3box.style.height = "40px";4document.body.append(box);5box.animate(6  [{ transform: "translateX(0px)", opacity: 1 }, { transform: "translateX(80px)", opacity: 0.5 }],7  { duration: 300, fill: "forwards" },8);9console.log("animation started");

Lines 1 through 4 create a visible 40-pixel box. Lines 5 through 8 start an animation from one transform and opacity value to another. The last line prints animation started, proving the example started without claiming a timing result.

For an everyday guide to moving interface elements, see animation. For CSS property changes, see styles and classes and sizes and coordinates.

Browser evidence

The important observable fact is small: after a browser page writes a width and then reads geometry, the read reflects that new width. This does not reveal an engine's private implementation, but it proves that JavaScript receives current geometry when it asks.

1const box = document.createElement("div");2box.style.width = "120px";3document.body.append(box);4console.log(box.offsetWidth);5console.log(getComputedStyle(box).width);

Line 1 makes a box. Line 2 sets its width. Line 3 attaches it. Line 4 prints 120; the following computed-style version prints 120px. The lesson test runs these stable facts in Chrome when Chrome can start and skips the evidence check otherwise.

1const box = document.createElement("div");2box.style.width = "120px";3document.body.append(box);4console.log(getComputedStyle(box).width);

Do not turn this fact into a clock claim. Browser timings depend on the device, document, and frame schedule. The stable lesson claim is only that the read reflects the style update.

Practical rendering habits

Start with the visible problem. If typing, dragging, or scrolling feels uneven, record a performance trace before changing properties. Look for long JavaScript tasks and repeated style, layout, paint, or composite work around the interaction.

Then reduce unnecessary work. Keep DOM changes small, read geometry before writing new geometry, and prefer transform or opacity for motion when that matches the design. These are hypotheses to test, not rules to apply blindly.

• Read layout values together before writing new layout-affecting styles.
• Use transforms for movement and opacity for fading when the visual result is correct.
• Use will-change for a measured, temporary reason rather than everywhere.
• Inspect the browser trace; do not guess from one property name alone.

Connect this lesson with rendering performance, which applies these ideas to everyday page speed, and rendering and the event loop, which explains when the browser gets a chance to paint.

Common misconceptions

• “Every DOM change lays out the whole page immediately.” Browsers often defer work until it is needed or until a frame.
• “Reading geometry is always bad.” A current measurement is sometimes necessary; repeated read-after-write loops are the concern.
• “`will-change` makes anything fast.” It is a hint with memory cost, not a permanent optimization switch.
• “Transform is always free.” It can often avoid layout and paint, but large layers and visual effects still cost work.
• “Off-main-thread means JavaScript is ignored.” A compositor animation may continue, but long JavaScript tasks still hurt input and other page work.

Practice exercises

const box = document.createElement("div");
box.style.width = "75px";
document.body.append(box);
console.log(box.offsetWidth);

function countLayouts(steps) {
  let dirty = false;
  let layouts = 0;
  for (const step of steps) {
    if (step === "write") dirty = true;
    if ((step === "read" || step === "frame") && dirty) {
      layouts += 1;
      dirty = false;
    }
  }
  return layouts;
}
console.log(countLayouts(["write", "read", "write", "read"]));

panel.style.transform = "translateX(0)";

Check your understanding

Use the pipeline names precisely, then separate a property rule of thumb from a measured result on a real page.

Key takeaways

• Style finds applicable CSS values, layout decides geometry, paint draws pixels, and composite arranges prepared surfaces.
• A geometry read after a relevant style write can force the browser to resolve layout now.
• Group reads before writes to avoid repeated layout decisions in one update.
• Layers can help compositing, but too many layers consume memory.
• Transform and opacity can often animate smoothly through compositing in most browsers.
• Profile a real interaction before choosing an optimization.

Coming next: How input reaches your event handlers. You will follow a pointer, touch, or keyboard action from hit testing to the JavaScript listener that receives it.