React, Vue, and INP observability in production

Users report the search bar “feels slow” on your React dashboard. INP reports 380 ms p75. You deploy a fix and INP drops to 90 ms. You do not get paged three weeks later when another engineer’s PR reverses the improvement — because you never wired LoAF telemetry to your CI pipeline.

How React 18 schedules work

React’s scheduler runs reconciliation in cooperative chunks of 5 ms. After each chunk, it yields to the browser using MessageChannel.postMessage — the only cross-browser mechanism that queues a task without the 4 ms clamp of setTimeout. The browser’s loop gets to run input, render, and other tasks; React resumes on the next task to do the next 5 ms chunk.

This is the implementation of “concurrent React”: a single render is split across many tasks, none of which exceeds the 50 ms long-task threshold. useTransition marks a state update as low-priority, allowing input updates to interrupt it. Understand the loop and React’s scheduler stops being mysterious.

Vue 3’s scheduler

Vue 3 batches reactive updates within a microtask: a write to a ref schedules a microtask that flushes all pending updates at the end of the current task. This means many writes in one task collapse into one update — but it also means the flush is a microtask and can prolong starvation if it triggers more reactive writes.

Vue exposes nextTick(callback) for code that wants to run after the flush; underneath, this is just another microtask scheduled after the flush microtask.

Production INP root-cause pipeline

Recipe for INP root-cause in production:

Subscribe to LoAF entries with PerformanceObserver. For each entry, record the firstUIEventTimestamp, the entry’s renderStart, and the array of scripts with attribution. When INP fires for a slow interaction (also via PerformanceObserver), correlate by interaction id: find the LoAF that overlapped the input, attribute the time to the heaviest script, send to telemetry with the script URL and function name (resolved via sourcemap server-side). This pipeline turns “users are complaining about lag” into “deploy 3a4f1c regressed search input by adding a 320 ms reducer call.”

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.entryType === 'long-animation-frame') {
      const heaviest = entry.scripts
        .sort((a, b) => b.duration - a.duration)[0];
      sendToTelemetry({
        frameStart: entry.startTime,
        frameDuration: entry.duration,
        scriptUrl: heaviest?.sourceURL,
        functionName: heaviest?.sourceFunctionName,
        charPosition: heaviest?.sourceCharPosition,
      });
    }
  }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

INP as CI gate. Production telemetry catches regressions after they reach users. A realistic gate: a synthetic Playwright/Puppeteer test in headless Chrome reproduces the critical interaction (type a query in search, open a menu, switch a tab), measures INP via the same PerformanceObserver code as in prod, and blocks merge if p75 crosses the budget. Key detail: headless Chrome on a CI runner is typically faster than a mid-range phone, so without --cpu-throttling-rate=4 (or CDP equivalent) the test passes locally and fails in prod. Bundle-size budgets add a second layer: JS size converts directly to parse+compile time, which converts to long tasks at load. Without all three layers — synthetic INP gate, bundle budget, and production LoAF alerts — a regression slips in silently and lives until the next manual profile.