Scheduling Observer Work Off the Critical Path

An observer callback is just a task on the main thread, and every millisecond it spends is a millisecond an input event waits. The fix is rarely to make the callback faster in total — it is to do the urgent part now and schedule everything else behind the user's next interaction.

Concept Framing

The other topics in Performance Optimization & Memory Management reduce how much work observers do: throttling and debouncing cuts the number of callbacks, DOM query minimization cuts the layout cost inside them, and pooling cuts the per-instance overhead. This topic is about when the remaining work runs.

A realistic intersection callback for a product grid does several things when a batch of cards enters the viewport: it swaps image sources, starts prefetching detail pages, records impressions, hydrates interactive widgets and perhaps renders recommendations. Only the first is visible within the next frame. The rest can happen a few hundred milliseconds later without anyone noticing — unless they all run in the same task, in which case a tap on "Add to cart" during that task waits for all of them.

Interaction to Next Paint (INP) measures exactly that wait: the time from an input to the next frame that reflects it. A 150 ms observer callback that happens to overlap a tap adds up to 150 ms to that interaction. The browser's scheduling APIs exist to break such tasks into pieces with room for input in between.

Spec / Signature Reference Table

The scheduling primitives available today differ in priority, cancellation and whether they keep your place in line.

scheduler.yield() is the key newer primitive. Unlike setTimeout(0), the continuation it returns is scheduled ahead of other queued tasks of the same priority, so yielding does not mean losing your place behind every third-party script on the page. Support is in Chromium-based browsers and arriving elsewhere; a fallback to setTimeout or postTask is straightforward.

Step-by-Step Implementation

Step 1: Classify the work inside the callback

type Urgency = 'frame' | 'soon' | 'idle';

interface WorkItem { urgency: Urgency; run: () => void }

frame work must affect the next paint (setting src, adding a class). soon work should happen within a few hundred milliseconds but may yield to input (hydrating a widget). idle work can wait for a quiet moment (analytics, prefetch).

Step 2: Write a portable yield

export function yieldToMain(): Promise<void> {
  const s = (globalThis as { scheduler?: { yield?: () => Promise<void> } }).scheduler;
  if (s?.yield) return s.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

Step 3: Process entries with a time budget

const BUDGET_MS = 8;

export async function processEntries(
  entries: IntersectionObserverEntry[],
  handle: (e: IntersectionObserverEntry) => void,
): Promise<void> {
  let sliceStart = performance.now();
  for (const entry of entries) {
    handle(entry);
    if (performance.now() - sliceStart > BUDGET_MS) {
      await yieldToMain();                 // let input and rendering in
      sliceStart = performance.now();
    }
  }
}

A budget of around 8 ms per slice leaves room for the browser to run an input handler and still produce a frame at 60 Hz.

Step 4: Route non-frame work to the right scheduler

export function schedule(item: WorkItem): void {
  const s = (globalThis as { scheduler?: { postTask?: Function } }).scheduler;
  if (item.urgency === 'frame') return item.run();
  if (item.urgency === 'soon') {
    s?.postTask ? s.postTask(item.run, { priority: 'user-visible' }) : setTimeout(item.run, 0);
    return;
  }
  'requestIdleCallback' in window
    ? requestIdleCallback(() => item.run(), { timeout: 2000 })
    : setTimeout(item.run, 200);
}

The timeout on requestIdleCallback matters: on a page that is never idle — an animation loop, a busy dashboard — idle callbacks would otherwise never run and analytics would be lost.

Threshold / Configuration Variants

The right budget and routing depend on what the page is doing.

Edge Cases & Gotchas

Yielding reorders side effects. After await yieldToMain(), anything may have happened: the element may have been removed, the component unmounted, the route changed. Re-check entry.target.isConnected (or an abort signal) after each yield before touching it.

Entries are stale after a long wait. An entry describes the intersection at entry.time. If soon work runs 300 ms later, the element may have scrolled away again. For work that should only happen while visible — starting a video, say — check current state rather than trusting the old entry.

Idle callbacks can starve. A page with a continuous requestAnimationFrame loop or a constantly busy thread may never be idle. Always pass timeout, and flush pending analytics on visibilitychange to hidden.

Microtasks do not yield. await Promise.resolve() or queueMicrotask continues in the same task; input cannot run in between. Only a new task (or scheduler.yield) gives the browser a turn.

Frameworks have their own schedulers. React's concurrent rendering already yields between units of render work, and calling startTransition from an observer callback marks the state update as interruptible. Vue and Angular do not yield during a render, so large observer-triggered updates there benefit more from manual slicing.

A Worked Example: Product Grid Callback

To make the classification concrete, here is a single callback from an e-commerce category page before and after scheduling. The page shows a grid of product cards; when cards enter the viewport, it loads their images, records impressions for merchandising analytics, prefetches the product detail data for cards that stay visible, and hydrates the "quick add" button.

Before, all four jobs ran in the callback for every entering card. With twenty cards entering on a fast scroll, the callback took about 90 ms on a mid-range phone, and taps on "quick add" buttons that were already visible regularly waited behind it.

After, the callback does only the image swap synchronously. Hydration of each card's button is posted at user-visible priority, in entry order, so the cards the user is looking at become interactive within a frame or two. Impressions are appended to a batch that an idle callback sends as one beacon. Prefetches are posted at background priority with a dwell check, and aborted if the card leaves before the task runs.

The measured result on the same device: the callback itself dropped to under 2 ms, the worst tap delay during a scroll dropped from about 90 ms to about 10 ms, and the total work done was unchanged — it simply stopped competing with the user. That last point matters when arguing for the change: scheduling does not remove work, it moves it out of the user's way, so there is no functional risk of dropping features.

Framework Integration Patterns

React's transition API maps cleanly onto the soon category:

import { startTransition, useCallback, useState } from 'react';

export function useVisibleIds() {
  const [ids, setIds] = useState<Set<string>>(new Set());
  const onEntries = useCallback((entries: IntersectionObserverEntry[]) => {
    // Frame work: imperative, immediate.
    for (const e of entries) if (e.isIntersecting) (e.target as HTMLImageElement).src ||= (e.target as HTMLElement).dataset.src ?? '';
    // Soon work: re-rendering lists of visible items can be interrupted by input.
    startTransition(() => {
      setIds((prev) => {
        const next = new Set(prev);
        for (const e of entries) {
          const id = (e.target as HTMLElement).dataset.id!;
          e.isIntersecting ? next.add(id) : next.delete(id);
        }
        return next;
      });
    });
  }, []);
  return { ids, onEntries };
}

In Vue, wrap non-urgent reactive updates in a postTask or idle callback; in Angular, run the observer outside the zone and re-enter only for the frame work, as described in running observer callbacks outside NgZone.

Debugging Checklist

• Record a Performance trace while scrolling a heavy section and look for tasks over 50 ms that start with your observer callback.
• Enable the Interactions track and tap during the scroll; check the input delay portion of each interaction.
• Confirm yields actually split the task — you should see several short tasks instead of one long one.
• Check that idle work eventually runs on a busy page (log when it does; the timeout should fire).
• After adding yields, verify nothing touches disconnected elements (watch for errors on fast route changes).
• Use the Long Animation Frames API in the field to find callbacks that still block frames.

The field attribution side is covered in observing long animation frames (LoAF).

FAQ

Related

• Yielding from Observer Callbacks with scheduler.yield — slicing long callbacks
• Deferring Non-Urgent Observer Work with requestIdleCallback — analytics and prefetch
• Prioritising Observer Tasks with scheduler.postTask — explicit priorities
• Keeping Observer Callbacks Under the INP Budget — measuring the result
• Callback Throttling & Debouncing — doing less work in the first place

↑ Back to Performance Optimization & Memory Management for Observer APIs