Rendering & the event loop

Frames between tasks

A browser does not update the screen after every line of JavaScript. It works in turns:

1. It runs one task, such as a click handler or a timer callback, all the way to the end.
2. It runs every microtask that the task created, such as promise callbacks.
3. Then it may update the screen.

That chance to update the screen is called a rendering opportunity. A frame is one new picture of the page. At a rendering opportunity, the browser can get a new frame ready and draw it. Drawing it is called painting.

This lesson builds on the HTML event loop. That lesson explained tasks and microtasks. This lesson adds the frame:

• where drawing work fits between tasks,
• why requestAnimationFrame is special,
• why grouping page changes keeps a page smooth.

JavaScript does not draw the screen. The browser does, and it chooses when. Your code's job is to change the page at the right moment. Then the browser works out the styles, the layout, and the pixels.

Rendering opportunities and frame rate

A screen shows a new picture many times each second. This speed is the refresh rate, measured in hertz (Hz). A 60 Hz screen shows about 60 pictures each second.

One second is 1,000 milliseconds (ms). So at 60 Hz, each picture lasts about 16.7 ms. This is a helpful rough budget for your work. It is not a promise. A faster screen, a busy page, or a hidden tab all change how often the browser draws.

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

Line 1 stores the number of pictures each second. Line 2 divides 1,000 ms by 60 and prints 16.7. Use this number to plan, not to time things. Don't write code that expects each frame to start exactly 16.7 ms after the last one.

While a task is running, the browser cannot draw. It must wait until the task ends. So a slow task makes the page miss frames. The browser does not show a half-finished change. It shows the next complete frame, later.

requestAnimationFrame timing

requestAnimationFrame asks the browser to call your function before it draws the next frame. People often shorten its name to rAF. rAF is the usual place to get a visual change ready, for example:

• moving a card,
• showing a new progress value,
• taking the next step of an animation.

rAF is not a timer. It does not make a frame happen. It only waits for the next frame that the browser chooses to draw.

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

Line 1 hands a function to the browser. When the browser is about to draw a frame, it calls the function. It passes in a timestamp: the time of this frame, in milliseconds since the page started. The timestamp is above 0, so the function prints before the next paint true.

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

Here is what each line does:

1. Line 1 asks for a rAF callback.
2. Line 2 queues a timer task with a 0 ms delay.
3. Line 3 queues a promise callback, which is a microtask.
4. Line 4 prints task finished right away.

One order is always the same: promise microtask prints before timer task. Microtasks run as soon as the current task ends, before the browser picks another task. The rAF callback waits for the next frame and runs just before that frame is painted.

The order of the timer and the rAF callback is not fixed. It depends on when the browser draws its next frame. So rely only on these two rules:

• A promise callback never interrupts the task that created it.
• A rAF callback is part of drawing a frame. It is not a regular timer task.

What happens in one frame

The HTML standard describes frame work in a long list of steps called "update the rendering". In short, the browser:

1. runs resize events, then scroll events;
2. checks media queries (CSS rules that depend on the screen size) and moves running CSS animations forward;
3. runs rAF callbacks;
4. works out style and layout (the next section explains both);
5. sends updates to observers, objects that watch elements for you (you'll meet them below);
6. paints the new frame.

Read the table below from top to bottom. Each row is one step of a frame, in the order the browser runs it.

This order is why rAF is the place to get a change ready. If a rAF callback changes a class or a transform, the style and layout steps right after it include that change.

Putting code in rAF does not fix everything, though. If the callback changes the page and then asks for a size, the browser must still work out the layout early to answer. So you still need to group reads and writes. The section "Batch work into one frame" shows how.

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

People often say "render" for all of the browser's drawing work. It is really three separate jobs:

• Style: decide which CSS rules apply to each element.
• Layout: work out each box's size and position on the page.
• Paint: draw the pixels you see.

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

1. Line 1 finds the cart element on the page.
2. Line 2 asks the browser to run a function before the next frame.
3. Line 3 adds the class is-open to the cart. The ?. skips this if no cart was found.
4. Line 4 prints cart state prepared when the function runs.

After the function ends, the browser decides which style rules apply. It works out the layout if needed. Then it paints the new result.

Some CSS changes cost less than others. Changing transform (which moves or scales an element) often does not change the layout of the boxes around it. Changing width may need a new layout. This is a useful clue, not a rule. Not every transform is free, and not every width change is slow. Measure a real interaction before you rewrite 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(" | "));

This small model writes one turn of the loop as text. It records the task first, then its microtask, then the frame steps. It leaves out most of the browser's real steps on purpose, to show one thing clearly: your task finishes before the browser can start frame work.

Resize, scroll, and observers

Resize and scroll events don't fire at random points in your code. They run at the start of frame work: resize events first, then scroll events. After that, the browser checks media queries. So a page reacts to a new window size in a steady, predictable order.

An observer is an object that watches elements and calls your function when something about them changes. You don't have to keep checking yourself.

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

1. Line 1 finds the card element.
2. Line 2 makes a ResizeObserver, an observer that watches sizes. Its function gets a list of entries, one for each watched element that changed.
3. Line 3 prints the card's width from the first entry.
4. Line 4 closes the function.
5. Line 5 starts watching the card, if it was found.

The browser calls the ResizeObserver function during frame work, after style and layout. That is why it can report the card's current size. You don't need a timer to check the size again and again.

IntersectionObserver runs a little later in the same frame work, after layout. It tells you when an element starts or stops overlapping the visible part of the page.

Keep the work in both observers small. If a ResizeObserver function keeps changing sizes, the browser must do layout again. It may then report an error about a "ResizeObserver loop".

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

1. Line 1 finds the product card.
2. Line 2 makes an IntersectionObserver. Its function also gets a list of entries. [entry] takes the first one out of the list.
3. Line 3 prints product is visible when the card is in view.
4. Line 4 closes the function.
5. Line 5 starts watching the card.

This is simpler than checking on every timer tick whether the card is visible.

Batch work into one frame

The DOM is the browser's list of everything on the page. Your code does two kinds of things with it:

• A read asks a question, such as "how wide is this element?"
• A write changes something: a class, a style, some text, or the elements themselves.

After a write, the layout is out of date. If you read a size right after, the browser must stop and work out the layout early to answer you. Code that writes, reads, writes, and reads again makes the browser do this over and over. This is 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});

• Line 1 reads the price element's width. getBoundingClientRect() gives an element's size and position.
• Line 2 reads the cart element's width. Both reads come before any write.
• Line 4 asks the browser to run the writes before the next frame.
• Line 5 sets the cart's width to the two widths added together.
• Line 6 adds the class has-total to the cart.

This code does not promise an exact number of layouts. It gives the browser one clear group of writes, instead of mixing reads and writes.

A common pattern for handling input:

1. Each input event runs as its own task. Save the newest value.
2. Queue one rAF callback, if none is waiting yet.
3. In that callback, use the newest value once to change the page.

If ten pointer moves arrive before the next frame, the page changes once, not ten times.

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 a page in a tab you are not looking at. Browsers do less work for hidden pages, to save battery and processing power:

• rAF callbacks usually stop until the page is visible again.
• Timers are throttled: the browser runs them less often than you asked.

So neither rAF nor timers can tell you how much real time has passed.

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 says the page is not visible.
• Line 2 says animation can run only when the page is visible. Here it can't.
• Line 3 picks "throttled scheduling", because the page is hidden.
• Line 5 prints rAF is paused.
• Line 6 prints throttled scheduling.

Real browsers have more rules than this model. The rule for your code is still simple: when the page is visible again, carry on from the current state. Don't expect the missed animation steps to have happened.

The visibilitychange event fires when a page is hidden or shown. Use it to pause extra work, or to refresh the display when the page comes back. To find out how much time has passed, read a real clock when work starts again, such as performance.now(), which gives the time in milliseconds. Don't count rAF calls and treat them as seconds.

Practical page updates

Say a shopping cart panel follows the pointer while a reader drags it open. Here is the plan:

1. Each pointer move runs as a task. Its handler saves the newest pointer position.
2. If no rAF callback is waiting, the handler queues one.
3. The rAF callback reads the saved position once and moves the cart once, 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 newest x position, starting at 0. Line 2 stores whether a rAF callback is already waiting.
• Line 4 runs a function on every pointer move.
• Line 5 saves the newest position. event.clientX is the pointer's distance from the left edge of the window.
• Line 6 stops here if a callback is already waiting.
• Lines 7 and 8 mark a callback as waiting and queue it.
• Line 9 makes the visual change. It sets the CSS variable --cart-x to the newest position.
• Line 10 clears the waiting flag, so a later pointer move can queue a new callback.
• Line 11 prints the position that was used.

So the page changes at most once per frame, however many pointer moves arrive.

A few more habits help:

• Keep the rAF callback short.
• Get values ready in ordinary tasks when you can.
• Avoid slow page searches, such as document.querySelector, inside an animation that runs every frame.
• Stop the animation when its part of the page is removed.

To learn more, see rendering performance, animation, observers, and the main thread.

Common misconceptions

• "rAF is an exact 60 fps timer." (fps means frames per second.) rAF is a function the browser calls before it draws a frame. How often it runs, and whether it runs at all, depends on the browser and the screen.
• "A timer with a 0 ms delay runs right away." It queues a later task. That task runs only after the current task and its microtasks finish.
• "Every change to the page is drawn right away." The browser collects changes and decides when to draw them.
• "rAF removes all layout cost." It puts visual work at a good time. But mixing reads and writes inside it can still cause extra layout work.
• "Background tabs keep animations running." Hidden pages usually pause rAF and run timers less often.

Each row below is a common belief. The middle column says what is true. The last column says what the tool does not promise.

Each row below is one way to run code later. Read across to see when it runs and what it is good for.

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

For each question, keep three things apart: the current task, its microtasks, and a frame that may come later.

Key takeaways

• The browser draws a frame only after a task and its microtasks finish, never in the middle of your code.
• At 60 Hz, 16.7 ms is a useful rough budget. rAF callbacks are not promised to run exactly that far apart.
• rAF runs before style, layout, and paint, so it is the place to get a visual change ready.
• Resize, scroll, media queries, animations, observers, and paint each have a fixed place in a frame.
• Read sizes first. Then group your page changes into one rAF callback.
• Hidden pages can pause rAF and slow timers, so counting callbacks does not measure time.

Coming next: Events, microtasks & ordering.