DOM & rendering performance

Keep the work for each frame small

When something on a page changes, the browser draws the page again. Each new drawing of the screen is called a frame. Rendering performance is about keeping the work for each frame small. Then the page reacts fast and moves smoothly.

This lesson uses ideas from earlier lessons:

• measuring elements, from Sizes, scrolling & coordinates
• making new elements, from Creating & changing elements
• classes and inline styles, from Styles & classes
• running code once per frame, from Animation with JavaScript
• being told when an element changes, from Observers

A screen redraws many times each second. This speed is called the refresh rate. It is measured in hertz (Hz): 60Hz means 60 times a second. So at 60Hz, the browser has about 16.7ms to make one frame. (A millisecond, ms, is a thousandth of a second.) At 120Hz it has about 8.3ms.

That time is shared. Your JavaScript uses it. The browser's own drawing steps use it. Handling clicks and key presses uses it too. If the work takes longer, the browser misses a frame and the page stutters. People call this stutter jank.

const refreshRates = [60, 120];
for (const refreshRate of refreshRates) {
  console.log((1000 / refreshRate).toFixed(1));
}

Line 1 lists two refresh rates, 60 and 120. Line 3 divides 1,000 milliseconds (one second) by each rate. Then toFixed(1) rounds the answer to one decimal place. So the code prints 16.7 and then 8.3. This is the time between two frames. Your JavaScript gets only part of it.

Other lessons cover nearby topics:

• Measuring performance shows how to time your code.
• Main thread shows how to split up long tasks.
• Debounce & throttle shows how to run a handler less often.

This lesson is about the drawing work that each handler causes.

To draw a frame, the browser can run up to five steps, always in the same order. This list of steps is called the rendering pipeline. The browser skips a step when nothing has changed for it.

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

The code prints the five steps joined by arrows. Here is what each step does:

1. JavaScript: your code runs. It may change elements, styles, classes, or the scroll position.
2. Style: the browser works out which CSS rules apply to each element.
3. Layout (also called reflow): the browser works out how big each box is and where it sits.
4. Paint: the browser draws the pixels: backgrounds, borders, shadows, text, and images.
5. Composite: the browser puts the painted parts together on the screen. A painted part that can move on its own is called a layer. Moving or fading a whole layer can happen in this step alone. That is often how transform and opacity work.

CSS is not slow, and the DOM is not slow. The cost comes from waking up more steps than a change needs. It gets much worse when your code does that many times in a row.

Different CSS properties wake up different steps. The next example lists a few common ones.

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);

• Lines 2 and 3 change the size of a box, so they need layout. Paint and composite follow.
• Lines 4 and 5 change only how the box looks, so they start at paint.
• Lines 6 and 7 can often be done in the composite step alone.
• The last two lines print composite and layout.

Here is a small message box, called a toast, that slides up and fades in. It changes only transform and opacity.

.toast {
  opacity: 0;
  transform: translateY(8px);
  transition: transform 180ms ease, opacity 180ms ease;
}

.toast.is-visible {
  opacity: 1;
  transform: translateY(0);
}

@media (prefers-reduced-motion: reduce) {
  .toast { transition: none; }
}

• The first rule (lines 1 to 5) starts the toast 8px lower and fully see-through (opacity: 0). Line 4 says both changes should animate over 180ms.
• The second rule (lines 7 to 10) applies when the toast gets the is-visible class. It moves the toast to its final place and makes it fully visible.
• The last rule (lines 12 to 14) turns the animation off when the user has asked their device for less motion.

Browsers can often do these two changes in the composite step. It still depends on the page and the device.

will-change is a hint to the browser. It says: "this element is about to change this property, so get ready."

const card = document.createElement("article");
card.style.willChange = "transform";
console.log(card.style.willChange);
card.style.willChange = "auto";
console.log(card.style.willChange);

Line 2 tells the browser the card may soon move with transform. Line 4 sets the hint back to auto, which means "no hint". So the code prints transform, then auto.

A hint does not promise a faster animation. Add one only after you have measured a real problem.

The table below compares the four steps after JavaScript. Read one row at a time: the step, what it works out, what wakes it up, and how to keep it small.

Sometimes your code needs the size or position of an element. Asking for it is called a layout read. Common layout reads are:

• offsetHeight
• getBoundingClientRect()
• scrollTop
• getComputedStyle()

A layout read is fine on its own. The problem is a read that comes right after a write: a change that can move or resize things, like a new width. The browser can't give you an old answer. So it pauses your JavaScript and runs layout right away. This is called a forced layout (or forced reflow).

Now picture a loop that does "write, read, write, read" for many elements. The browser runs layout once for every element. This is called layout thrashing.

Real timings change from one computer to the next. So the next example uses a small pretend model instead of the real browser. It follows the same rule, and it always gives the same answer.

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);

How the model works:

• Each box has a height, a readHeight() method, and a writeHeight() method.
• A write sets dirty to true (line 16). Here dirty means "the layout is out of date".
• A read checks dirty (line 8). If it is true, the read adds 1 to forcedLayouts and sets dirty back to false (lines 9 and 10).
• In "thrash" mode, each box is written and then read straight away (lines 30 and 31).
• In "batched" mode, all heights are read first (line 34). Then all boxes are written (lines 35 to 37).

With 5 boxes, the code prints 5 for thrash mode and 0 for batched mode.

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 demo above uses real boxes on the page and real time, so your timings will differ from anyone else's. The forced-layout count comes from the pretend model, so it never changes. Thrash mode forces one layout per box. Batched mode forces none, because every read happens before any write.

The fix is simple. Do the work in three steps:

1. Read all the sizes and positions you need.
2. Decide what to change.
3. Write all the changes.

When the writes change what the user sees, put them inside requestAnimationFrame. This browser function takes a callback and runs it once, just before the next frame is drawn.

Some libraries, such as FastDOM, use two words for this: measure for reads and mutate for writes. The step-through below is a tiny scheduler: a helper that decides when each task runs. It keeps reads in one list and writes in another.

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(" -> "));

The code asks for the write first (line 36) and the read second (line 37). When the frame runs, the scheduler still runs the read first, so the code prints read: rect -> write: transform.

The next example updates the screen only once per frame, even when new values arrive faster. It uses its own small requestAnimationFrame on line 4, so you can see what happens. That version saves each callback in the frames list instead of waiting for a real frame.

const frames = [];
let pending = false;
let latestX = 0;
function requestAnimationFrame(callback) { frames.push(callback); }

function moveTo(x) {
  latestX = x;
  if (pending) return;
  pending = true;
  requestAnimationFrame(() => {
    pending = false;
    console.log("translateX(" + latestX + "px)");
  });
}

moveTo(12);
moveTo(28);
console.log(frames.length);
frames.shift()();

• Lines 16 and 17 call moveTo twice, first with 12 and then with 28, before any frame runs.
• Each call saves the newest value in latestX (line 7).
• Only the first call asks for a frame. On the second call, pending is already true, so line 8 stops it.
• Line 18 prints 1, because only one callback is waiting.
• Line 19 runs that callback. It prints translateX(28px), the newest value.

The real requestAnimationFrame runs its callback once, just before the next paint. It still runs on the main thread, the same place as the rest of your page code.

When you add many elements, you can build them away from the page first. A DocumentFragment is a light container that is not on the page. You put elements inside it, then add them all to the page in one step.

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);

• Line 2 makes the fragment.
• Lines 4 to 7 make three li items and put them in the fragment.
• Line 10 moves all three items into the list with replaceChildren.
• Line 11 prints 3: the list now has three children.
• Line 12 prints 0: the items moved out, so the fragment is now empty.

This is one change to the page, instead of three separate ones.

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"));

Line 2 gives the card the class card. Line 3 adds the class is-open. Line 4 sets the CSS variable --progress to 0.64. So the code prints card is-open and 0.64.

The Styles & classes lesson explained when to use which. A class picks a look you designed in CSS. An inline style or CSS variable carries a value that keeps changing, like a number.

This also helps speed. One class change can switch many CSS rules at once. Your JavaScript doesn't have to set many inline styles one by one.

Long pages can also tell the browser to skip drawing parts that are off the screen:

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

• Line 2, contain, says the card's insides don't affect the rest of the page. So the browser can redo style, layout, and paint for one card without checking the whole page.
• Line 3, content-visibility: auto, lets the browser skip drawing cards that are off the screen. The cards stay in the DOM.
• Line 4, contain-intrinsic-size, gives each skipped card a stand-in size of 180px tall. Without it, the page could jump while you scroll.

Think of a list with 10,000 rows. The user can see only a few rows at a time, so the page doesn't need 10,000 elements. It can create only the rows on the screen, plus a few extra. This is called virtualization. It is also called windowing or virtual scrolling.

A virtual list has three parts:

• The viewport is the part of the list you can see.
• Overscan is a few extra rows above and below the viewport. They are ready in case you scroll fast.
• Two empty spacers, one at the top and one at the bottom, take up the space of all the other rows. They keep the scroll bar the same size as for the full list.

The step-through below works out which rows to create. The list has 10,000 rows, each 32px tall. The viewport is 160px tall and scrolled down 328px. There are 2 rows of overscan.

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.ceil((scrollTop + viewportHeight) / rowHeight) - 1;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);

const rowHeight = 32;
const viewportHeight = 64;
const scrollTop = 0.5;
const firstVisible = Math.floor(scrollTop / rowHeight);
const lastVisible = Math.ceil((scrollTop + viewportHeight) / rowHeight) - 1;

console.log(firstVisible + "-" + lastVisible);

Here scrollTop is 0.5, so the viewport runs from 0.5px to 64.5px. Each row is 32px tall, so row 2 starts at 64px. A thin strip of row 2 is on the screen.

• Line 4 finds the first row: Math.floor(0.5 / 32) is 0.
• Line 5 finds the last row: Math.ceil(64.5 / 32) is 3, and 3 minus 1 is 2.
• So the code prints 0-2.

A shortcut that subtracts one whole pixel would work out Math.floor(63.5 / 32), which is 1. It would miss row 2 whenever scrollTop is not a whole number.

When every row has the same height, the math is easy: scrollTop / rowHeight, rounded down, gives the first row on the screen. When rows have different heights, the list must measure each row, remember the sizes, and fix them when a row changes. That is why real list libraries keep a saved list of where each row starts.

The table below compares three ways to show a long list. Read across a row to see what each way keeps on the page, when it fits best, and what it costs.

Measure first, before you change how your code is built. Chrome DevTools has two places to check drawing work:

• The Rendering tab can flash the parts of the page that get painted again. It can also show areas where the layout jumped.
• The Performance panel records a timeline of what the browser did. Layout work shows as purple blocks named Layout. A forced layout gets a warning 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 the recording shows purple Layout blocks under your event handler, open its call stack: the list of functions that led there. Then:

• If it points to a size read right after a write, change the order: reads first, then writes.
• If paint takes most of the time, make the painted area smaller, or use contain to keep each part separate.
• If JavaScript takes most of the time, use the ideas from the Main thread lesson.

Where this shows up in real code

You will meet these problems in search boxes with suggestions, panels you can drag, dashboards, editors, endless feeds, and big data tables. Here is what to use:

• Use debounce or throttle to run heavy typing and scroll handlers less often. Still keep each handler small.
• Use ResizeObserver and IntersectionObserver to be told when an element changes size or comes into view. Then you don't have to check it in every scroll handler.
• Use a small renderer or a framework to change only the elements that changed. Don't replace big parts of the page with innerHTML.
• Use classes for looks you designed, CSS variables for numbers, and transform and opacity for movement when the design allows it.
• Use virtualization for huge app-like lists. Use content-visibility for long pages where the content should stay on the page.

The next lesson, Loading performance, is about the work before your code runs: sending and loading less code in the first place.

Common misunderstandings

• "Moving things with transform costs nothing." It often skips layout and paint. But each layer uses memory, and too many layers make the composite step slow.
• "will-change makes animation fast." It is only a hint, meant for a short time. Leaving it on many elements wastes memory.
• "innerHTML is the fastest way to update." It is short to write, but the browser must read the whole HTML string again. It also throws away focus, selected text, event listeners, and anything typed into inputs.
• "Virtualization is always best." Rows that aren't on the page can't be found with find-in-page, and some screen readers can't reach them.
• "The browser groups all my changes for me." It groups many of them. But a size read right after a write asks for the answer now, so the browser must run layout at once.

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.ceil((scrollTop + viewportHeight) / rowHeight) - 1;
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.ceil((scrollTop + viewportHeight) / rowHeight) - 1;
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

For each question, first ask which step the code wakes up. Then check whether a size read comes right after a write.

Key takeaways

• The browser draws a frame in up to five steps: JavaScript, Style, Layout, Paint, and Composite.
• A forced layout happens when your code reads a size or position right after a write.
• Do all reads first, then all writes. Put changes the user sees inside requestAnimationFrame.
• Build many elements in a fragment. Use classes for designed looks and CSS variables for numbers. Don't rebuild big parts of the page with innerHTML.
• Use a virtual list for huge app-like lists. Use content-visibility when the content should stay on the page.

Next, Loading performance is about sending less JavaScript and loading it in a smarter way. Then the browser has less code to read and run before it can draw the page.