Rendering & the event loop

Frames between tasks

A browser does not paint after every JavaScript statement. It runs a task, drains the microtasks created by that task, and then may get a chance to update the screen. That chance is called a rendering opportunity. It is where a browser can prepare and paint a new frame.

This lesson continues the HTML event loop processing model. That lesson established tasks and microtasks. Here the missing piece is the frame: where visual work fits, why requestAnimationFrame is special, and why grouping DOM work helps a page feel responsive.

The useful question is not “when does JavaScript paint?” JavaScript does not paint. The browser owns rendering and chooses its opportunities. Your code can prepare state at the right time, then let the browser calculate style, layout, and paint.

Rendering opportunities and frame rate

A display that refreshes at 60 hertz can show about 60 pictures each second. Dividing one second by 60 gives roughly 16.7 milliseconds per picture. That is a helpful mental budget, not a deadline that the web platform guarantees. A faster display, a busy page, or a hidden tab can change what opportunities the browser provides.

1const picturesPerSecond = 60;2console.log((1000 / picturesPerSecond).toFixed(1));

Line 1 names a common display rate. Line 2 divides 1,000 milliseconds by 60 and prints 16.7. This only describes a useful example. Do not write code that assumes each rAF timestamp advances by exactly 16.7.

When a task runs too long, the browser cannot run its rendering steps until that task returns. This is why expensive JavaScript makes a page miss visual updates. The browser may then show the next complete frame later instead of showing a half-finished one.

requestAnimationFrame timing

requestAnimationFrame, often shortened to rAF, asks the browser to call a function before a future paint. It is the normal place to prepare a visual change such as moving a card, applying a progress value, or updating an animation state. It is not a timer and it does not make a frame happen by itself.

1requestAnimationFrame((time) => console.log("before the next paint", time > 0));

Line 1 queues a callback. When the browser reaches an appropriate rendering opportunity, it calls the function with a high-resolution timestamp. The callback prints before the next paint true in a browser because the timestamp is a positive time value.

1requestAnimationFrame((time) => console.log("before the next paint", time > 0));2setTimeout(() => console.log("timer task"), 0);3Promise.resolve().then(() => console.log("promise microtask"));4console.log("task finished");

Line 1 asks for a frame callback. Line 2 queues a timer task. Line 3 queues a promise microtask. Line 4 prints task finished immediately. The stable ordering fact is that promise microtask runs before timer task, because microtasks drain after the current task before another task is selected. The rAF callback waits for a rendering opportunity and runs before that opportunity's paint.

Do not claim a fixed order between an arbitrary timer and a particular future rAF callback. Browser scheduling can vary. Instead, use the guarantees that matter: a promise reaction does not interrupt the task that scheduled it, and rAF is part of the rendering update rather than a regular timer task.

What happens in one frame

The HTML standard's “update the rendering” algorithm has many details. The plain version is still useful: the browser handles resize and scroll-related work, updates media queries and animations, runs rAF callbacks, then calculates style and layout before it paints. Observers fit into that rendering update too.

This order explains why rAF is a preparation point. If an rAF callback changes a class or a transform, the style and layout phase that follows can include that change. A callback that reads layout after changing it can still ask the browser for a current measurement, so placement helps but does not remove the need to batch reads and writes.

1const model = { clock: 0, task: "change cart", microtasks: ["save cart"], frames: [] };Run2 3function runTurn(state) {4  const events = [`task: ${state.task}`];5  events.push(...state.microtasks.map((name) => `microtask: ${name}`));6  state.clock += 16.7;7  events.push("frame: requestAnimationFrame");8  events.push("frame: style, layout, paint");9  state.frames.push(state.clock);10  return events;11}12 13console.log(runTurn(model).join(" | "));

Style, layout, and paint

Style means deciding which CSS rules apply. Layout means calculating box sizes and positions. Paint means drawing the visible pixels for the current result. They are different jobs, even though developers often say “render” for all of them.

1const cart = document.querySelector("[data-cart]");2requestAnimationFrame(() => {3  cart?.classList.add("is-open");4  console.log("cart state prepared");5});

Line 1 finds a cart element. Line 2 queues the before-paint callback. Line 3 changes one class, and line 4 prints cart state prepared when the callback runs. The browser then decides which style rules apply, computes layout if needed, and eventually paints the new result.

A property such as transform can often be updated without changing the layout of surrounding boxes, while a property such as width may require layout. That is a useful performance clue, but it is not a promise that every transform is free or every width change is bad. Measure a real interaction before rewriting it.

1const state = { clock: 0, task: "change cart", microtasks: ["save cart"], frames: [] };2 3function runTurn(model) {4  const events = [`task: ${model.task}`];5  events.push(...model.microtasks.map((name) => `microtask: ${name}`));6  model.clock += 16.7;7  if (model.clock >= 16.7) {8    events.push("frame: requestAnimationFrame");9    events.push("frame: style, layout, paint");10    model.frames.push(model.clock);11  }12  return events;13}14 15console.log(runTurn(state).join(" | "));

The model first records a task, then its microtask, then a frame phase. It deliberately compresses the browser's algorithm. Its job is to make the boundary visible: JavaScript code finishes a task before the browser can reach the next frame work.

Resize, scroll, and observers

A resize event and a scroll event are not random callbacks sprinkled between your JavaScript lines. In the rendering update, the browser runs resize steps first and scroll steps next. Media queries are evaluated after that, which lets a page react to a changed viewport consistently.

1const card = document.querySelector("[data-card]");2const observer = new ResizeObserver((entries) => {3  console.log("card width", entries[0].contentRect.width);4});5if (card) observer.observe(card);

Line 1 gets the element. Line 2 creates a ResizeObserver. Line 3 logs the measured width when the browser delivers an entry. Line 4 starts observing. ResizeObserver belongs in the rendering update after style and layout work, which is why it can report an element's current size without you using a timer to check repeatedly.

IntersectionObserver comes later in the same broad update, after layout work. It tells code that an element intersects a root or viewport. Both observers should do small work. If an observer changes sizes again and again, the browser may need more layout work and can report a resize-observer loop problem.

1const card = document.querySelector("[data-product]");2const observer = new IntersectionObserver(([entry]) => {3  if (entry.isIntersecting) console.log("product is visible");4});5if (card) observer.observe(card);

Line 1 selects a product card. Line 2 creates an observer. Line 3 prints product is visible when the entry intersects. Line 4 closes the callback, and line 5 starts observation. This is a cleaner signal than checking visibility on every timer tick.

Batch work into one frame

DOM reads ask questions such as “what is this element's width?” DOM writes change classes, styles, text, or nodes. When code repeatedly writes and then reads, each read may need the browser to make layout current early. This pattern is often called layout thrashing.

1const priceWidth = price.getBoundingClientRect().width;2const cartWidth = cart.getBoundingClientRect().width;3 4requestAnimationFrame(() => {5  cart.style.width = `${cartWidth + priceWidth}px`;6  cart.classList.add("has-total");7});

Lines 1 and 2 read both measurements before a write. Line 4 schedules the visual change. Lines 5 and 6 group the writes in one callback. This code does not guarantee a number of layouts, but it gives the browser one clear batch instead of interleaving read and write demands.

A common practical pattern is: handle input in its task, store the latest value, and use one pending rAF callback to apply visual changes. If ten pointer events arrive before the next frame, the callback can use the newest value once instead of doing ten separate visual updates.

1const actions = ["read", "write", "read", "write"];Run2 3function countLayouts(plan) {4  let dirty = false;5  let layouts = 0;6  for (const action of plan) {7    if (action === "write") dirty = true;8    if (action === "read" && dirty) {9      layouts += 1;10      dirty = false;11    }12  }13  return layouts + Number(dirty);14}15 16console.log(countLayouts(actions));

1const reads = ["measure cart", "measure price"];2const writes = ["move cart", "show total"];3 4function countLayouts(plan) {5  let dirty = false;6  let layouts = 0;7  for (const action of plan) {8    if (action === "write") dirty = true;9    if (action === "read" && dirty) {10      layouts += 1;11      dirty = false;12    }13  }14  return layouts + Number(dirty);15}16 17console.log(countLayouts(["read", "read", "write", "write"]));

Rendering in background tabs

A hidden page is not a small visible page. Browsers save battery and CPU by reducing work for background documents. In normal browser use, rAF callbacks stop or pause when a document is hidden, and timer callbacks are throttled. Do not use either one as a wall-clock guarantee.

1const pageVisible = false;2const animationCanRun = pageVisible;3const timerPolicy = pageVisible ? "normal scheduling" : "throttled scheduling";4 5console.log(animationCanRun ? "rAF can run" : "rAF is paused");6console.log(timerPolicy);

Line 1 models a hidden page. Line 2 says animation cannot run in that model. Line 3 chooses a throttled timer policy. Lines 5 and 6 print rAF is paused and throttled scheduling. The real browser has more policies, but the application rule is simple: resume from current state when the page becomes visible instead of expecting background animation steps to have happened.

Use visibilitychange to pause optional work or refresh a display when it becomes visible again. For elapsed time, compare a real clock value when work resumes. Do not count rAF calls and assume they represent every missed second.

Practical page updates

Suppose a shopping cart follows a pointer while a reader drags it open. The pointer event is a task. Store the latest pointer position in that handler. If no rAF callback is pending, queue one. The rAF callback reads the stored position once and writes one transform for the next frame.

1let latestX = 0;2let pending = false;3 4window.addEventListener("pointermove", (event) => {5  latestX = event.clientX;6  if (pending) return;7  pending = true;8  requestAnimationFrame(() => {9    document.documentElement.style.setProperty("--cart-x", `${latestX}px`);10    pending = false;11    console.log("updated cart", latestX);12  });13});

Line 1 stores the latest input. Line 4 updates it for every pointer task. Lines 5 through 7 ensure only one rAF callback is waiting. Line 9 makes the visual write, line 10 unlocks a future callback, and line 11 logs the value that was used. This avoids treating every input event as a separate paint request.

Keep the rAF callback short. Prepare values in ordinary tasks when possible, avoid expensive DOM queries inside a tight animation loop, and stop visual work when a component unmounts. For more page-level tools, continue with rendering performance, animation, observers, and main thread.

Common misconceptions

• “rAF is a precise 60 fps timer.” It is a before-paint callback. The rate and even whether it runs depend on the browser.
• “A timer with zero delay runs immediately.” It creates a later eligible task after the current task and microtasks finish.
• “Every DOM write paints now.” Browsers batch work and decide when to update rendering.
• “rAF removes all layout cost.” It coordinates visual work; interleaved reads and writes can still cause extra layout work.
• “Background tabs keep animations alive.” Hidden documents commonly pause rAF and throttle timers.

Practice exercises

const order = [];
Promise.resolve().then(() => order.push("promise"));
setTimeout(() => order.push("timer"), 0);
order.push("task");
setTimeout(() => console.log(order.join(",")), 10);

const order = [];
Promise.resolve().then(() => order.push("promise"));
setTimeout(() => order.push("timer"), 0);
order.push("task");
setTimeout(() => console.log(order.join(",")), 10);

requestAnimationFrame(() => {
  cart.classList.add("is-open");
});

const plan = ["read", "read", "write", "write"];
console.log(plan.join(" then "));

const visible = false;
console.log(visible ? "animate" : "pause animation");

Check your understanding

Answer by keeping three layers separate: the current task, its microtasks, and a possible future rendering opportunity.

Key takeaways

• A frame is browser work that can happen after a task and its microtasks, not after every JavaScript line.
• At 60 Hz, 16.7 ms is a useful rough budget, not a guaranteed rAF interval.
• rAF runs before style, layout, and paint at a rendering opportunity, so it is for visual preparation.
• Resize, scroll, media queries, animations, observers, and paint have defined places in the rendering update.
• Read layout values first, then group DOM writes into one rAF callback when visual work is involved.
• Background documents can pause rAF and throttle timers, so callback counts are not a clock.

Coming next: Events, microtasks & ordering.