Rendering Pipeline & Observer Timing

Every observer in the browser answers the same question — what changed? — but each one answers it at a different moment in the frame. Code that works in a demo and flickers in production almost always has a timing assumption baked into it, and the fix starts with knowing exactly where each callback lands.

Concept Framing

The four observer families look alike from the outside: a constructor that takes a callback, an observe() method, and a disconnect(). That surface similarity hides the most important difference between them, which is when the callback runs. The Core Observer Fundamentals section covers what each API measures; this topic covers when it reports.

There are three distinct scheduling models in play:

• Microtask delivery. MutationObserver queues a microtask as soon as the first mutation record is created. The callback runs when the current script — and every other queued microtask ahead of it — finishes, long before the browser gets anywhere near style or layout.
• Rendering-step delivery. ResizeObserver and IntersectionObserver are computed during the update the rendering steps of the HTML event loop, after requestAnimationFrame callbacks and after style and layout have been brought up to date. ResizeObserver callbacks run inside those steps, before paint. IntersectionObserver computes its entries there too, but delivers them by queueing a task, so its callback runs after the frame has been painted.
• Buffered task delivery. PerformanceObserver delivers through a queued task as well, batching entries that accumulated since the last delivery, and it may be deferred further while the page is busy.

The consequence is that three pieces of code which all "react to the element changing" can observe three different states of the DOM and paint in three different frames. The IntersectionObserver API deep dive explains the geometry that is computed; here the question is only where in time the answer arrives.

Understanding the diagram above removes most of the mystery from observer bugs. A class toggled from an IntersectionObserver callback cannot affect the frame in which the intersection was measured, because that frame has already been painted. A size written from a ResizeObserver callback can affect the current frame, which is exactly why the browser has to guard against infinite loops — the subject of fixing "ResizeObserver loop limit exceeded".

Spec / Signature Reference Table

The table below summarises the scheduling contract for each family as the HTML and CSSOM specifications define it. "Frame of effect" means the earliest frame in which a DOM write made inside the callback can be painted.

Two properties in this table are easy to miss. First, ResizeObserver is the only observer whose callback runs with fresh layout and before paint, which makes it the correct place for measure-then-adjust work. Second, IntersectionObserver entries carry a time field — a DOMHighResTimeStamp taken when the intersection was computed, not when your callback runs — so comparing entry.time with performance.now() inside the callback tells you how late the delivery was.

Step-by-Step Implementation

The fastest way to internalise the model is to instrument it. The following steps build a small harness that logs each delivery point with its timestamp, so you can watch the ordering in your own browser.

Step 1: Stamp every phase with a shared clock

type Phase = 'task' | 'microtask' | 'mutation' | 'raf' | 'resize' | 'intersection' | 'performance';

interface Stamp { phase: Phase; t: number; frame: number }

const stamps: Stamp[] = [];
let frame = 0;

// Count frames with a rAF loop so every stamp can be tied to a frame number.
function tick(): void { frame++; requestAnimationFrame(tick); }
requestAnimationFrame(tick);

function stamp(phase: Phase): void {
  stamps.push({ phase, t: performance.now(), frame });
}

Each stamp records both the high-resolution time and the frame counter. Timestamps alone are misleading because two callbacks 0.3 ms apart can still land in different frames.

Step 2: Attach one of each observer to the same element

const box = document.querySelector<HTMLElement>('#probe')!;

new MutationObserver(() => stamp('mutation')).observe(box, { attributes: true });
new ResizeObserver(() => stamp('resize')).observe(box);
new IntersectionObserver(() => stamp('intersection')).observe(box);

new PerformanceObserver(() => stamp('performance'))
  .observe({ type: 'layout-shift', buffered: false });

Observing the same element with every family is what makes the comparison fair: the only variable left is the scheduling model.

Step 3: Trigger one change that every observer can see

document.querySelector('#go')!.addEventListener('click', () => {
  stamp('task');
  queueMicrotask(() => stamp('microtask'));
  requestAnimationFrame(() => stamp('raf'));
  box.style.width = box.offsetWidth === 200 ? '320px' : '200px'; // resize + attribute
  box.style.transform = 'translateY(0)';                           // no-op for layout
});

Changing the inline width writes the style attribute (a mutation), changes the box size (a resize) and can change the intersection ratio if the element straddles the viewport edge.

Step 4: Print the ordering after two frames

function report(): void {
  const base = stamps[0]?.t ?? 0;
  console.table(stamps.map((s) => ({ phase: s.phase, ms: +(s.t - base).toFixed(2), frame: s.frame })));
  stamps.length = 0;
}
document.querySelector('#go')!.addEventListener('click', () => {
  requestAnimationFrame(() => requestAnimationFrame(report));
});

In Chromium, Firefox and Safari the printed order is consistent: task, mutation and microtask (in queue order), raf, resize, then intersection one frame number later, with performance last. If your own output differs, something in your page is forcing an early layout — which is itself worth knowing.

Threshold / Configuration Variants

Configuration options do not change which scheduling model an observer uses, but several of them change how often the callback is queued and how much work it carries. The table maps the options that matter for timing.

The delay option on IntersectionObserver v2 is the only one that directly throttles delivery. Every other lever reduces the number of reasons to deliver rather than the delivery rate.

Edge Cases & Gotchas

Forced layout moves the goalposts. Reading offsetWidth or getBoundingClientRect() inside a MutationObserver callback forces a synchronous layout. That does not make ResizeObserver fire early — it still waits for the rendering steps — but it does mean you paid for layout twice in one frame. The batching reads and writes guide shows how to avoid the double cost.

Background tabs skip rendering entirely. When a tab is hidden, browsers stop running the update-the-rendering steps. requestAnimationFrame, ResizeObserver and IntersectionObserver all go quiet; MutationObserver keeps firing because it is tied to DOM changes, not frames. Code that assumes "a mutation will be followed by a resize callback" stalls in a background tab and then receives a burst when the tab becomes visible.

Throttled frames on low-power mode. Safari on iOS in Low Power Mode and several Android browsers cap rendering at 30 Hz. Every rendering-step observer halves its maximum delivery rate. Nothing breaks, but animations driven from IntersectionObserver callbacks look twice as coarse.

Iframes run their own rendering steps. A cross-origin iframe may be throttled or skipped while off-screen, so an observer inside it can be several frames behind the parent. The iframe troubleshooting guide covers the visible symptom.

The first observation is special. Calling observe() on either rendering-step observer schedules an initial notification for the next rendering opportunity, even when nothing has changed. That is why callbacks fire on initial render — or, when the element is detached, why they do not.

Framework Integration Patterns

Frameworks add their own scheduling layer on top of the browser's, and the interaction is where most timing bugs come from.

React batches state updates and commits them in a task or microtask depending on the trigger. An IntersectionObserver callback that calls setState produces a render that commits after the post-paint task — so a visibility-driven class change is always at least one frame behind the scroll that caused it. For work that must land in the same frame, move the measurement into a ResizeObserver callback or apply the change imperatively to the element through a ref:

import { useEffect, useRef } from 'react';

export function useSameFrameWidth<T extends HTMLElement>(apply: (el: T, width: number) => void) {
  const ref = useRef<T>(null);
  useEffect(() => {
    const el = ref.current;
    if (!el) return;
    const ro = new ResizeObserver(([entry]) => {
      // Runs after layout, before paint: an imperative write here lands this frame.
      apply(el, entry.contentBoxSize[0].inlineSize);
    });
    ro.observe(el);
    return () => ro.disconnect();
  }, [apply]);
  return ref;
}

Vue flushes component updates in a microtask by default (flush: 'pre'). A watcher reacting to a ref that an IntersectionObserver callback set will run in that callback's task, and the DOM patch follows in the same microtask checkpoint — still one frame behind the measurement. The Vue composables topic covers flush: 'post' for reads that need the patched DOM.

Angular runs change detection after every task that zone.js intercepts, which includes observer callbacks. A busy IntersectionObserver therefore triggers application-wide change detection on every scroll crossing unless the observer is created outside the zone.

Choosing the Observer by When You Need the Answer

Most teams pick an observer by what it measures and then fight its timing. It is often simpler to invert the choice: decide when the answer must be available, then pick the mechanism whose delivery point matches.

You need to react before the next paint, with fresh geometry. Use ResizeObserver. It is the only callback that runs after layout and before paint. Resizing a canvas backing store, choosing a compact layout for a card, or clamping a popover to its container all belong here. The price is discipline: every write must either target a deeper element or be idempotent, or the loop guard will push work to the next frame.

You need to know about structural change as soon as it happens, geometry irrelevant. Use MutationObserver. It is the earliest notification the platform offers, and it batches naturally, so a framework re-render that touches two hundred nodes produces one callback. Keep the callback to bookkeeping — registering new targets with other observers, updating counts — and never read layout there.

You need to know that something became visible, and a frame of latency is acceptable. Use IntersectionObserver. Almost every product use — lazy loading, analytics impressions, pausing media, starting reveal animations — tolerates a frame of lag, which is why it is the most widely used of the four. When the effect must stay pinned to the scroll offset, reach for CSS (position: sticky, scroll-driven animations) instead.

You need to know what the page cost, eventually. Use PerformanceObserver. Its entries describe work that already happened; delivering them late is harmless and keeps the measurement from adding to the cost it measures.

Measuring Timing in the Field

Lab traces show the ordering on your machine. Real users run on slower CPUs, busier pages and throttled frame rates, and the delivery gaps that matter only show up there. A small amount of field instrumentation turns "it flickers on some phones" into a number.

interface DeliveryStats { count: number; over16: number; over50: number; max: number }

const stats: DeliveryStats = { count: 0, over16: 0, over50: 0, max: 0 };

export function trackDelivery(entries: IntersectionObserverEntry[]): void {
  const now = performance.now();
  for (const e of entries) {
    const lag = now - e.time;           // computation → callback
    stats.count++;
    if (lag > 16) stats.over16++;
    if (lag > 50) stats.over50++;
    stats.max = Math.max(stats.max, lag);
  }
}

// Report once, when the page is being hidden — the last reliable moment.
addEventListener('visibilitychange', () => {
  if (document.visibilityState !== 'hidden' || stats.count === 0) return;
  navigator.sendBeacon('/rum/observer-delivery', JSON.stringify(stats));
});

Call trackDelivery(entries) at the top of any intersection callback you care about. The ratio of over50 to count is a direct measure of how often the main thread was too busy to deliver promptly, and it correlates closely with poor interaction latency — the same congestion delays input handlers. Pair it with the long-task correlation technique to find what was occupying the thread.

For ResizeObserver there is no time field, but counting callbacks per frame with a rAF-driven frame counter reveals loop iterations in the field: more than two per frame during a resize means a callback is writing to its own depth.

Debugging Checklist

• Record a trace in the Performance panel and find the Run Microtasks block that contains your MutationObserver Record a trace in the Performance panel and find the Run Microtasks block that contains your `MutationObserver` callback — it should sit inside the task that caused the mutation.
• Look for your ResizeObserver Look for your `ResizeObserver` callback under the frame's rendering work (labelled per browser), between Layout and Paint.
• Confirm IntersectionObserver Confirm `IntersectionObserver` callbacks appear in a separate task after Paint; if they appear inside a long task, the page's main thread is starving the queue.
• Compare entry.time with performance.now() Compare `entry.time` with `performance.now()` inside intersection callbacks; a gap over 50 ms means delivery was delayed by other work.
• Check document.visibilityState Check `document.visibilityState` when a callback seems missing — rendering-step observers do not fire in hidden tabs.
• Search the callback for layout reads (offsetHeight, getBoundingClientRect, getComputedStyle Search the callback for layout reads (`offsetHeight`, `getBoundingClientRect`, `getComputedStyle`) and move them out if the trace shows a Recalculate Style or Layout block inside it.

// Paste into the console to measure delivery lag for any intersection observer.
const lag = new IntersectionObserver((entries) => {
  const now = performance.now();
  for (const e of entries) console.log(e.target, `lag ${(now - e.time).toFixed(1)} ms`);
}, { threshold: [0, 1] });
document.querySelectorAll('img, section').forEach((el) => lag.observe(el));

FAQ

Related

• Where IntersectionObserver Callbacks Run in the Event Loop — the post-paint task in detail
• ResizeObserver and the Update-the-Rendering Steps — depth-ordered delivery and the loop guard
• MutationObserver Microtask Timing Explained — why records arrive before layout
• Why Observer Callbacks Lag One Frame Behind — diagnosing visibility-driven flicker
• Syncing Observer Callbacks with requestAnimationFrame — aligning work to the next frame

↑ Back to Core Observer Fundamentals & Browser APIs