DOM & rendering performance

Keep each frame cheap

Rendering performance is not one trick. It is the discipline of making DOM work, CSS work, and pixel work small enough that the browser can respond before the next refresh. This lesson builds on the measurements from Sizes, scrolling & coordinates, the node-building patterns from Creating & changing elements, the state styling choices from Styles & classes, the frame loop from Animation with JavaScript, and the observer APIs from Observers.

At 60Hz the browser has roughly 16.7ms for one frame. On a 120Hz display, the budget is roughly 8.3ms. JavaScript, style calculation, layout, paint, compositing, input handling, and browser overhead share that time. If your code burns the budget, the page janks.

The Measuring performance and Main thread lessons cover profiling and long tasks. Debounce & throttle limits how often handlers run. This lesson focuses on the rendering work each handler wakes up.

A frame can pass through five important stages. The browser can skip stages when nothing invalidates them, but this order is the working mental model:

1const pipeline = [2  "JavaScript",3  "Style",4  "Layout",5  "Paint",6  "Composite",7];8 9console.log(pipeline.join(" -> "));

1. JavaScript changes DOM, styles, classes, scroll positions, or data.
2. Style finds matching CSS rules and computed values.
3. Layout, also called reflow, computes box sizes and positions.
4. Paint draws pixels for backgrounds, borders, shadows, text, and images.
5. Composite moves and blends layers, often for transform and opacity.

The expensive part is not “CSS is slow” or “DOM is slow.” The expensive part is waking up more stages than the interaction needs, especially repeatedly inside one JavaScript task.

1const propertyCosts = {2  width: "layout",3  paddingTop: "layout",4  boxShadow: "paint",5  backgroundColor: "paint",6  transform: "composite",7  opacity: "composite",8};9 10console.log(propertyCosts.transform);11console.log(propertyCosts.width);

A layout read is not bad by itself. You often need offsetHeight, getBoundingClientRect(), scrollTop, or getComputedStyle(). The problem is reading layout immediately after writing layout-affecting styles, over and over. The browser must stop JavaScript and calculate layout synchronously so the read can be correct.

1function createInstrumentedLayout(count) {2  let dirty = false;3  let forcedLayouts = 0;4  const boxes = Array.from({ length: count }, (_, index) => {5    const box = {6      height: 24 + (index % 5),7      readHeight() {8        if (dirty) {9          forcedLayouts += 1;10          dirty = false;11        }12        return box.height;13      },14      writeHeight(next) {15        box.height = next;16        dirty = true;17      },18    };19    return box;20  });21  return { boxes, get forcedLayouts() { return forcedLayouts; } };22}23 24function runLayoutFlushModel(count, mode) {25  const model = createInstrumentedLayout(count);26  let totalHeight = 0;27 28  if (mode === "thrash") {29    for (const box of model.boxes) {30      box.writeHeight(box.height + 1);31      totalHeight += box.readHeight();32    }33  } else {34    const heights = model.boxes.map((box) => box.readHeight());35    heights.forEach((height, index) => {36      model.boxes[index].writeHeight(height + 1);37      totalHeight += height + 1;38    });39  }40 41  return { forcedLayouts: model.forcedLayouts, totalHeight };42}43 44console.log(runLayoutFlushModel(5, "thrash").forcedLayouts);45console.log(runLayoutFlushModel(5, "batched").forcedLayouts);

The fake model is intentionally simple: a write marks layout as dirty; the next layout read flushes it and increments forcedLayouts. That matches the browser rule you need to remember without depending on real timings.

1const boxes = [...document.querySelectorAll(".rp-run-box")];2 3for (const [index, box] of boxes.entries()) {4  box.style.inlineSize = 120 + index + "px";5  box.getBoundingClientRect();6}7 8console.log("touched " + boxes.length + " boxes");

The live demo uses real DOM boxes and real elapsed time, so results vary by machine. Tests assert only the deterministic model: thrash mode forces one layout per box; batched mode forces zero synchronous layouts because all reads happen before writes.

The safe order is boring and powerful: read all geometry, compute decisions, then write all changes. When the writes are visual, requestAnimationFrame is the natural place to perform them because it runs before the next paint.

1function createFrameScheduler(requestFrame) {2  const reads = [];Run3  const writes = [];4  let scheduled = false;5 6  function schedule() {7    if (scheduled) return;8    scheduled = true;9    requestFrame(flush);10  }11 12  function measure(task) {13    reads.push(task);14    schedule();15  }16 17  function mutate(task) {18    writes.push(task);19    schedule();20  }21 22  function flush() {23    scheduled = false;24    const readBatch = reads.splice(0);25    const writeBatch = writes.splice(0);26    readBatch.forEach((task) => task());27    writeBatch.forEach((task) => task());28  }29 30  return { measure, mutate };31}32 33const frames = [];34const log = [];35const scheduler = createFrameScheduler((flush) => frames.push(flush));36scheduler.mutate(() => log.push("write: transform"));37scheduler.measure(() => log.push("read: rect"));38frames.shift()();39console.log(log.join(" -> "));

Libraries such as FastDOM popularized two words for this: measure for reads and mutate for writes. The tiny scheduler in the step-through is real code: even if a write is requested first, the flush runs the read queue first.

1const list = document.createElement("ul");2const fragment = document.createDocumentFragment();3 4for (const label of ["Read", "Measure", "Mutate"]) {5  const item = document.createElement("li");6  item.textContent = label;7  fragment.append(item);8}9 10list.replaceChildren(fragment);11console.log(list.children.length);12console.log(fragment.childNodes.length);

Build many nodes off-page, then insert once. DocumentFragment moves its children into the destination, so after replaceChildren(fragment) the fragment is empty. This is different from repeatedly appending visible nodes one by one.

1const card = document.createElement("article");2card.className = "card";3card.classList.toggle("is-open", true);4card.style.setProperty("--progress", "0.64");5 6console.log(card.className);7console.log(card.style.getPropertyValue("--progress"));

Styles & classes explained the split: classes choose designed states, while inline styles and custom properties carry truly dynamic values. That split also helps performance because CSS can own groups of declarations instead of JavaScript churning many individual inline styles.

1.feed-card {2  contain: layout paint style;3  content-visibility: auto;4  contain-intrinsic-size: 1px 180px;5}

CSS containment limits how much a subtree can affect the rest of the page. content-visibility: auto lets the browser skip rendering off-screen content while keeping the DOM mounted. contain-intrinsic-size reserves space so scroll position does not jump before the content is rendered.

A list with 10,000 rows does not need 10,000 DOM nodes if the user can see only a few at a time. Virtualization, also called windowing or virtual scrolling, renders the visible rows plus an overscan buffer. Top and bottom spacers keep the scrollbar the same height as the full list.

1const totalRows = 10000;Run2const rowHeight = 32;3const viewportHeight = 160;4const scrollTop = 328;5const overscan = 2;6 7const firstVisible = Math.floor(scrollTop / rowHeight);8const lastVisible = Math.floor((scrollTop + viewportHeight - 1) / rowHeight);9const startIndex = Math.max(0, firstVisible - overscan);10const endIndex = Math.min(totalRows - 1, lastVisible + overscan);11const beforeHeight = startIndex * rowHeight;12const afterHeight = (totalRows - endIndex - 1) * rowHeight;13 14console.log(startIndex + "-" + endIndex);15console.log(beforeHeight + ":" + afterHeight);

Fixed-height rows are the easy case because scrollTop / rowHeight gives the first visible index. Variable-height rows need measurement, caching, and correction when real heights change. That is why many production virtualizers maintain an index of measured row offsets.

Measure before changing architecture. Chrome DevTools has two places to check rendering work. The Rendering tab can show paint flashing and layout shift regions. The Performance panel records a timeline where layout work appears as purple Layout blocks; forced synchronous layout warnings are named Forced reflow.

1// In Chrome DevTools:2// 1. More tools -> Rendering -> Paint flashing.3// 2. Performance panel -> record an interaction.4// 3. Look for purple "Layout" blocks.5// 4. Expand warnings named "Forced reflow".

When a recording shows purple layout blocks under your event handler, inspect the call stack. If the stack points to a geometry read after a write, fix ordering. If paint dominates, reduce paint area or isolate subtrees. If JavaScript dominates, move to the main-thread responsiveness techniques.

Real-world patterns

Rendering performance work shows up in autocomplete menus, draggable panels, dashboards, editors, infinite feeds, and data grids. The practical decision tree is:

• Use debounce or throttle to limit expensive input and scroll handlers, then still keep each handler cheap.
• Use ResizeObserver and IntersectionObserver instead of polling with scroll handlers when the browser can tell you about size or visibility changes.
• Use a renderer or framework to patch changed nodes instead of replacing large chunks of DOM with innerHTML.
• Use class toggles for designed states, CSS variables for data, and transform/opacity for motion when the visual design allows it.
• Use virtualization for huge app-like lists, and content-visibility for long document-like pages where keeping content mounted matters.

The next lesson, Loading performance, moves from rendering work after code runs to shipping and loading less work in the first place.

Misconceptions and trade-offs

• “Transforms are free.” They are often compositor-friendly, but too many layers consume memory and can make compositing expensive.
• “`will-change` fixes animation.” It is a short-lived hint. Leaving it everywhere is a cost.
• “`innerHTML` is the fastest render.” It may be simple, but it reparses markup and can destroy focus, selection, listeners, and typed state.
• “Virtualization is always best.” It can break find-in-page and hide content from assistive technology when rows are unmounted.
• “The browser will batch everything for me.” The browser batches many things, but a synchronous geometry read after a write asks for the answer right now.

Practice exercises

console.log((1000 / 60).toFixed(1));

console.log((1000 / 60).toFixed(1));

let dirty = false;
let forcedLayouts = 0;
function writeStyle() { dirty = true; }
function readLayout() {
  if (dirty) {
    forcedLayouts += 1;
    dirty = false;
  }
}
for (let index = 0; index < 3; index += 1) {
  writeStyle();
  readLayout();
}
console.log(forcedLayouts);

let dirty = false;
let forcedLayouts = 0;
function writeStyle() { dirty = true; }
function readLayout() {
  if (dirty) {
    forcedLayouts += 1;
    dirty = false;
  }
}
for (let index = 0; index < 3; index += 1) {
  writeStyle();
  readLayout();
}
console.log(forcedLayouts);

const rowHeight = 32;
const viewportHeight = 160;
const scrollTop = 328;
const overscan = 2;
const firstVisible = Math.floor(scrollTop / rowHeight);
const lastVisible = Math.floor((scrollTop + viewportHeight - 1) / rowHeight);
const startIndex = Math.max(0, firstVisible - overscan);
const endIndex = lastVisible + overscan;
console.log(startIndex + "-" + endIndex);

const rowHeight = 32;
const viewportHeight = 160;
const scrollTop = 328;
const overscan = 2;
const firstVisible = Math.floor(scrollTop / rowHeight);
const lastVisible = Math.floor((scrollTop + viewportHeight - 1) / rowHeight);
const startIndex = Math.max(0, firstVisible - overscan);
const endIndex = lastVisible + overscan;
console.log(startIndex + "-" + endIndex);

const reads = [];
const writes = [];
const log = [];
reads.push(() => log.push("read"));
writes.push(() => log.push("write"));
reads.forEach((task) => task());
writes.forEach((task) => task());
console.log(log.join(" -> "));

const reads = [];
const writes = [];
const log = [];
reads.push(() => log.push("read"));
writes.push(() => log.push("write"));
reads.forEach((task) => task());
writes.forEach((task) => task());
console.log(log.join(" -> "));

Quiz

Answer these by identifying the rendering stage first, then checking whether a geometry read happens after a write.

Key takeaways

• Think in stages: JavaScript, Style, Layout, Paint, Composite.
• Forced synchronous layout happens when a geometry read needs fresh layout after a write.
• Batch reads before writes; use requestAnimationFrame for visual mutations.
• Build DOM in fragments, use classes and CSS variables intentionally, and avoid big innerHTML rerenders for stateful UI.
• Virtualize huge app-like lists, but use content-visibility when content should stay mounted.

Next, Loading performance focuses on shipping less JavaScript and loading it smarter, so there is less work to parse and execute before rendering begins.