DEV Community: Przemyslaw Kalka

How to Profile a Real-Time UI

Przemyslaw Kalka — Sat, 08 Aug 2026 11:33:28 +0000

The dashboard came up in under a second, and every loading number was green. None of that was the problem. Once the feed went live, with a vol-surface fit recomputing on every tick, the chart began to stutter and lag.

That is a different kind of problem, and you find it a different way. A load audit runs once and hands you a score; this you profile, by driving the UI under its real workload and reading the trace. The hard part is knowing what to read. By the end of this post you will know, for each way a real-time UI comes apart under load, exactly where to look in DevTools and which number matters.

Load is not run-time. Loading is the cost of coming up; run-time is the cost of staying responsive while the data keeps arriving.

Performance isn't one speed

Inside the run-time regime, "is it fast?" stops having one answer. A live UI is governed by three independent rates that keep competing long after load completes. They are a producer, a transformation, and a presentation; in a browser UI they show up as input, compute, and display, the last being the rate at which the screen itself can present new frames, fixed by the hardware at 60 to 120 Hz. The one rate you set is none of these: it is the cadence at which you commit to the screen, the knob you tune between them.

Performance is governed by competing rates, not a single speed. The diagnostic unit is not time; it is the relationship between three rates.

Run-time failures are mismatches between competing rates, not a single measure of speed. Compute numbers read off a 5.07 s Performance trace of the demo under a 500 Hz feed, 249 fits; a fast feed genuinely outruns the fit.

Used this way, the model is a procedure, not a taxonomy. Performance debugging is relationship debugging: you are not measuring one speed, you are finding the two rates whose relationship has broken down. The procedure is the same every time.

Identify the input rate.
Identify the compute rate.
Identify the display rate.
Find the pair that is out of step.
Measure that mismatch.
Narrow the class of likely fixes.

The rest of this post runs that procedure once per mismatch: every diagnosis below is these six steps applied, with the DevTools surface and the number for each.

You profile it, you don't audit it

A page-load audit works because loading is predictable: every user loads the same bytes the same way, so one automated pass characterises it. Run-time is the opposite. The expensive work is triggered by what the user and the feed do, it is specific to your workload, and it sits on no single path. You do not audit it; you drive the actual scenario, open the chain, fire the vol shock, drag the slider, and record a Performance trace while it runs. That is closer to end-to-end testing than to a one-shot audit.

This is the honest place for Core Web Vitals. They are very good at the regime they were built for, the pay-per-load web where a faster load lifts revenue, and they stop here by design. Even Interaction to Next Paint (INP), the closest of them, times a discrete interaction; a feed that drives a chart on its own fires none. There is no run-time metric in that toolkit because a workload-specific cost generally has to be profiled under representative load, not captured by a single generic pass.

The load audit on the demo: a perfect Performance score, and silent about run-time. LCP 0.8 s, TBT 0, CLS 0.001. True, and not the question this post asks.

Read the three rates directly from the trace:

Input: instrument it, or take the feed's tick rate (a performance.mark per event). It is a range, not a number: read it during a vol event, not a calm market, or you measure the easy case.
Compute: the task's duration on the Main or Worker track, and it is two numbers, not one: the median governs whether you keep up with the feed, the p99 governs the worst frame. Both are ranges too. The same fit runs faster on your dev box than on a trader's locked-down laptop or a VDI session, so a local reading is an optimistic floor, not the number every desk sees.
Display: the screen's refresh, 60 or 120 Hz, the ceiling your commits live under. Read your own commit and frame cadence against it from the Frames track and React's Profiler; that cadence is the knob, healthy when you throttle it well below the ceiling, broken when the feed drives it.

Once you can see all three, the failures are the gaps between them.

I will show each gap, and beside it what correct looks like, from demo.oracaus.dev, which fits a fifty-expiry surface to a streaming chain and stays smooth doing it. Its trace under the worst case is the reference for healthy: a near-idle main thread with the feed running hot.

The same UI profiled under a 500 Hz feed with a vol shock running: the main thread is busy about a quarter of the 5.07 s window, idle the rest, and the Frames track is clean. This is the reference for healthy.

The method on one screen

Here is the whole method at a glance. The rest of the post is one row at a time, with the DevTools steps and the healthy trace for each.

You see	Rates	Look here	Measure	Likely fix
renders far exceed paints; work thrown away	input > display	React Profiler commits; Main track	commits/sec vs frames painted	subscribe once, throttle commits below the display
data lagging, queue growing	input > compute	Worker/Main track; User Timing; queue depth	compute median vs inter-input interval	coalesce to the latest input
output doesn't match the input shown (correctness)	the tear, not a rate pair	on screen; coherence check	does the output's input match the input on screen (timing is only the precondition)	commit input and output as one snapshot
stutter, dropped frames	compute per frame > display budget	Frames track; Main flame; Performance Monitor	p99 frame time, dropped frames, layouts/sec	move compute off-thread; compositor, cut redraw, cut allocation

Re-rendering faster than you paint

Symptom. The component re-renders on every input event, far more often than the screen repaints. Most of that work is thrown away before anyone sees it. It is worse than waste: those renders run on the main thread, so they help starve the next frame, feeding the dropped-frame failure below.

Renders fire at the feed rate; only the three that land on a paint survive. The rest is thrown away.

Look here. Open React DevTools, switch to the Profiler, and record while the feed runs. If it reports that profiling is not supported, the build stripped the instrumentation: profile a development or profiling build instead (for React, the react-dom/profiling entry, which stays minified and production-representative). A naive component commits on every update, a dense picket fence of bars in the commit timeline; in the Performance panel, the same work packs the Main track between paints.

Measure. Commits per second against frames actually painted. If commits run at the feed rate while the screen paints at 60 or fewer, the difference is pure waste.

Healthy. Commits track a cadence you choose, not the feed's, and that cadence sits well below the display's 60 to 120 Hz ceiling. Profiled against a 500 Hz feed, the demo commits at a deliberate 5 Hz throttle, not 500, each commit a median 0.1 ms of React work.

Likely fix. Stop letting the feed set your commit rate: subscribe to the feed once and let the UI commit at a cadence you set, rather than threading every tick through props.

Compute falling behind the feed

Symptom. Results lag the feed, and under load the lag grows. What is on screen is several ticks old, and getting older.

Each fit outlasts several ticks, so its result is stale on arrival; without coalescing, the lag grows.

Look here. Open the Performance panel, record under load, and find the compute task on the Main track, or the Worker track if you moved it off-thread; read its duration. Bracket it with User Timing, a performance.mark at the input and a performance.measure at the result, to put an input-to-result latency on the Timings track. If you queue inputs, instrument the queue depth: a growing queue is the tell.

Measure. Compute median against the inter-input interval, not the p99. The backlog grows without bound exactly when the typical fit outlasts the gap between ticks: that is a utilisation fact, governed by the median (or mean), not the tail. You can sit with a p99 above the interval and a median below it, draining the queue on every calm stretch, which is bounded bursty lag, a different failure. Once the median crosses the interval, you cannot keep up tick-for-tick, so either the queue grows without bound or you coalesce.

Healthy. Input-to-result latency stays bounded and queue depth does not trend upward, because each fit runs against the latest chain with the intermediate ticks coalesced away, not because back-to-back execution keeps up. At a 36 ms median against a 2 ms interval, processing every tick in order diverges without bound; that is the broken case.

Full-surface fits on the worker thread, each a median 36 ms (about 57 ms at p99). The gap stays bounded because each fit runs against the latest chain, intermediate ticks coalesced away, not because the thread keeps up tick-for-tick. Off the main thread, so a fit that outlasts a frame never blocks one.

Likely fix. Coalesce: absorb the intermediate inputs and compute against the latest. This is backpressure's lossy path, keep the newest and drop the rest, so you stay one result behind instead of falling endlessly further back.

The answer that no longer matches the input

You reach this one by fixing the others, and it is the residual they leave behind. Coalesce the backlog away, with no async involved at all, and the one result you do show was still computed during a fit the input moved underneath, so it is paired with an input it never matched. Moving heavy work off the main thread, the fix for the budget failure, only widens that window; it does not create the bug. And you cannot tune your way out: input rate climbs with volatility and compute time climbs on slower hardware, so on a busy feed or a slow machine the compute loses the race, however fast it is on your own box. The answer has to be structural, not a faster fit.

Symptom. The output on screen is paired with an input it was never computed from, a frame that was never true. In the demo, the fitted curve pulls off the quotes it was built from.

Look here. Not in the flame chart. You see it on screen, the fitted curve pulling off the quotes it was fit to, or you catch it with a coherence metric. The timing precondition, though, is visible: the compute taking longer than the gap between inputs.

Measure. A coherence check: does the input the output was computed from match the input on screen. That check, and not any timing statistic, is what makes this its own failure. The timing condition, compute outlasting the gap between inputs, is only the precondition, and it is shared with the backlog failure above; it is not the measure here.

Healthy. The output on screen always matches the input on screen: every pair is committed from the one snapshot it shares.

Likely fix. Commit the input and its output together as one snapshot. This is the one failure the profiler cannot show you; I took it apart in full in its own post.

A frame that misses its budget

Symptom. The visible jank: stutter, dropped frames, a frame rate that sags and spikes. The work for a frame overran the display's budget, 16.7 ms at 60 Hz or 8.3 ms at 120, and the frame missed its slot.

Look here. Open the Performance panel and record under load; the Frames track flags long and dropped frames, and clicking one opens the Main track flame chart showing where the time went, scripting, style recalculation, layout, paint. For a live read, open the Performance Monitor (press Cmd+Shift+P, or Ctrl+Shift+P on Windows, and run "Show Performance Monitor"), then enable CPU usage, Layouts per second, Style recalculations per second, and JS heap size; it plots them live as the feed runs, which a single trace cannot. The Rendering tab's Frame Rendering Stats overlays live frame rate on the page itself.

Measure. Read the worst frames, your p99, and the dropped-frame count straight from the Frames track; the long tasks (over 50 ms, marked with a red corner) on the Main track; and layouts-per-second live in the Performance Monitor. The mean frame time will look fine; it is the worst frames the user feels.

Healthy. Frames stay inside budget, the main thread runs no long tasks and sits idle between paints, and the redraw cost stays flat rather than climbing.

Under the hot feed the monitor holds steady: the JS heap sawtooths between roughly 50 and 95 MB without trending up, DOM nodes flat near 3,100, CPU around a quarter. Layouts and style recalculations hold in the single digits, peaking near 10 a second, never thrashing or climbing. No memory leak, no node leak.

Likely fix. It depends on which part of the frame is heavy. If it is scripting, a synchronous computation blocking the main thread, move it off-thread, usually into a worker; that is the compute failure above, surfacing as jank. If it is the rendering itself: move the animation to the compositor (covered here), cut the redraw work or drop to canvas, or kill the allocation the garbage collector is paying for.

Where this comes from

I did not assemble this from blog posts; I learned to read these traces on trading desks, in FX, rates and derivatives, where a frame that lies is a mispriced quote. The pieces are old and not mine alone: Nolan Lawson on main-thread cost, the reactive-streams world on backpressure, the React team on concurrent rendering, the game world on frame pacing. What I am adding is one repeatable procedure for reading them: find the relationship that is breaking down.

Try it on your own UI

You can put this to work in a few minutes, without any of my code. Take a real-time UI of your own, drive its worst scenario, and record a Performance trace while it runs, not while it loads.

Run-time performance is governed by competing rates, and a janky real-time UI is a mismatch between two of them. It answers a different class of question from your loading metrics, not a replacement for them.

Find the input. Find the compute. Find the display. Find the relationship that is breaking down. That tells you where to look next.

I Cancelled the Stale Request. The Render Still Lied.

Przemyslaw Kalka — Tue, 23 Jun 2026 07:00:00 +0000

The pattern is the correct one. An input changes, a useEffect fires the async compute, an AbortController cancels the one still in flight, and setState commits the result. I had moved the heavy work off the render path, wired all of it, and cancelled cleanly. Under load the chart still drew a shape the data never made. Not stale, not a race I had forgotten to guard: one frame, stitched from two different moments.

Cancellation had handled the old request. It had never promised that the result I committed was paired with the input I committed it against.

Three properties get conflated into one.

Freshness: how recent the output is.
Cancellation: whether obsolete work was prevented from committing.
Coherence: whether the frame was ever true as a whole.

They are independent. You can cancel perfectly, render the freshest input, and still commit a frame that was never true.

Once a derivation runs asynchronously, "showing the right thing" stops meaning the latest result and starts meaning a result paired with the input it was computed from. React's default, where each piece of state updates on its own, quietly breaks that pairing the moment the compute outlasts the gap between inputs. And the rule for what to do when a fresh input lands mid-compute inverts depending on the kind of input: a slider and a market tick want opposite handling. That asymmetry is the part I had not seen written down, and it is the second half of this post.

The pattern you trust

You have shipped this one, and it worked: a typeahead box. The user types, a useEffect fires a fetch, an AbortController cancels the request still in flight, a spinner holds the gap, and the matching results commit. It is correct, and it stays correct for two supports that are easy to stop noticing:

The browser enforces the cancel. Abort a fetch and the response never reaches your code, so a stale result cannot surface to be mispaired.
The input is an intent. When the query moves you genuinely want the work in flight gone, so cancel-and-restart is exactly the right policy.

Heavy local compute removes the first support. A live feed removes the second. The rest of this post is those two changes, one at a time, and the one invariant that survives both.

The first change: heavy local compute

The fix was correct. It also opened this hole, by taking the first of those two supports away.

Last time, the question was where a re-drawing chart actually spends its time. This post starts one move earlier, at the decision that made the chart async in the first place. A fit, a revaluation, a Monte Carlo that takes longer than a frame cannot run in the render body without freezing the UI, so you move it off the main thread, into a worker, and the interface stays responsive. That is the right call, and the bug only exists because I made it: I had already solved the performance problem, and that is what created the correctness one.

A fetch the browser would have cancelled for you; a worker will not, unless the compute polls the abort signal mid-flight, which the heavy synchronous work you moved there rarely does. Its result comes back later, and "later" is long enough for the input to have moved. The result lands tagged, in your head, to the input that started it, and gets committed next to whatever the input happens to be now. Nobody wrote a bug. The bug is structural: going async split one operation into "what I asked" and "what came back", and nothing in the default model keeps those two paired when they reach the screen.

Thirty lines that lie

You do not need a vol surface to see it. Here is the whole phenomenon, and the output is an arithmetic lie you cannot argue with.

// The async compute (stands in for any heavy derivation)
function asyncSquare(n: number, signal: AbortSignal): Promise<number> {
  return new Promise((resolve, reject) => {
    const t = setTimeout(() => resolve(n * n), 120); // one heavy compute
    signal.addEventListener("abort", () => {
      clearTimeout(t);
      reject(new DOMException("aborted", "AbortError"));
    });
  });
}

// The textbook pattern, done correctly
function IncoherentSquare() {
  const [n, setN] = useState(2);
  const [sq, setSq] = useState(4);

  useEffect(() => {
    const ctrl = new AbortController();
    asyncSquare(n, ctrl.signal)
      .then(setSq)
      .catch(() => {});
    return () => ctrl.abort(); // cancels the stale request, correctly
  }, [n]);

  return (
    <>
      <input type="number" value={n} onChange={(e) => setN(+e.target.value)} />
      <p>
        {n}² = {sq}
      </p>
    </>
  );
}

n updates synchronously, the instant you type. sq updates only when a compute finishes, 120 ms later. They are two independent pieces of state, and the last line composes them as if they moved together. Settle on 7 and it reads 7² = 49, correct. Now change to 9: for the next 120 ms the line reads 9² = 49, the new input shown against the previous input's output. Keep the input moving faster than the compute and the gap never closes.

The AbortController is correct, and it is beside the point. There is nothing here for better cancellation to fix: with 9 in the box only one compute is in flight, and the lie is on screen the entire time it runs. n updates now, sq updates later, and the two are no longer coupled. The bug is not a leftover request to clean up. It is two independent values composed as if they were one. Cancellation is not coherence.

Call the complete input state observed when a derivation begins its snapshot. The bug then has a one-line name.

A frame that combines inputs from one snapshot with a derived output computed from another.

Coherence and freshness are independent properties. A coherent frame can be old. An incoherent frame can pair your newest input with an output left over from an earlier one. 9² = 49 shows the newest input, 9, against a stale answer: the defect is not age, it is the pairing. The rest of this post is a single rule, every emitted frame pairing its input and output from one snapshot, and the two guarantees that hold it up.

The compute starts against snapshot 7 and finishes after the input has moved to 9. Pairing the output with the live input is the lie. Pairing it with the snapshot it used is the fix.

The same bug, with money on it

Squares are unarguable but cheap. Here is the same failure with a cost attached.

The live demo fits a volatility surface to a streaming option chain, the kind of heavy compute a trading desk runs on the client. Two panels run the identical fit against the identical feed. The top commits on every tick the textbook way. The bottom holds the pairing this post is about.

Hit the vol shock. It is the square again, now a curve and a cloud of dots: the dots from the latest tick, the curve from a fit a few ticks back, painted as one picture. At the top the curve pulls away from the dots at the strikes that just moved; at the bottom it holds. Every point on the torn curve is real, and as a whole it matches no chain that existed at any single instant. The same failure as the square, now with a position behind it.

It is tempting to read the bottom panel as "more up to date". The fit takes as long as it takes, and within itself the bottom panel is not ahead of anything: its curve and its dots come from the same tick. It does run fresher than the top panel here, because the naive panel additionally lets its fit queue back up and a saturated queue commits older work, but that queue is a separate failure from the tear. The demo shows two numbers per panel to keep the distinction honest:

Coherence error: how far the curve on screen sits from the quotes on screen, in the same frame. This is what the pairing fixes. At the top it already runs from tens to hundreds of per cent with the feed calm, and crosses 2000% under the shock. At the bottom it holds around 15% in both regimes, the scale of the fit's own residual against the deliberately noisy quotes.
Ground-truth fit error: how far each panel's fitted parameters sit from the true surface they were fitting. This is the fitter's own error, the irreducible cost of recovering parameters from noisy quotes, and the pairing neither improves nor worsens it. It is the same on both panels, calm and under shock: when the coherence error above explodes, this number does not move. The gulf above is the tear, not a difference in fit quality.

So the claim is narrow and it is measurable: coherence error diverges while
ground-truth fit error stays equal. A coherent frame a few ticks behind is a real past state you can act on. An incoherent frame is a tuple that was never true at any instant. The fix buys you the first and cannot buy you the second.

The invariant

State the goal as one sentence and the rest follows:

Every emitted frame composes (input, output) from the same snapshot.

Two guarantees uphold it, and it is worth adding them one at a time, because they fix different failures.

Atomic commit kills the false tuple. Keep the input and the output in one object and commit them together, pairing the output with the input it was actually computed from:

// Guarantee 1: commit the pair, not two slots
.then((out) => setPair({ in: n, out })); // n is the input this compute started on

Now no frame is internally false. You never see 9² = 49 again. A single store, whether useState with one object or a useReducer, gives you the atomic commit and no more false tuples. One object is only half the fix. In the timer above, the cleanup truly cancels: clearTimeout stops the superseded compute, so it never resolves and there is nothing stale to commit. That is why the timer alone never shows the next failure. A worker makes no such promise. Its abort is a message the worker cannot read until the compute in hand returns, so a synchronous fit you tried to cancel runs to completion and hands you its result anyway, still tagged in your head to an input you have already left:

No id tag: the cancelled compute returns anyway
n → 7   start compute A             id 1
n → 9   abort A, start compute B    id 2   (A is mid-compute; the abort waits)
        A returns {in: 7, out: 49}         you are already on 9
        B returns {in: 9, out: 81}

Both pairs are true. Commit them as they land and you paint 7² = 49 for an input you abandoned before 9² = 81 arrives; under a moving slider, a whole backlog of abandoned inputs paints ahead of the latest. The cancel did nothing the worker could honour.

Identity-based admission keeps only the current one. Tag each input with a monotonic id and commit only a response whose id is still current:

// Guarantee 2: drop a response that is no longer current
const id = ++currentId.current;
// later, when the response lands:
.then((out) => { if (id === currentId.current) setPair({ in: n, out }); });

The first guarantee makes each frame true. The second keeps only the current input's frame. Put exactly that way, the two imply the invariant: every committed pair is internally consistent, and a superseded response is dropped rather than committed, so you never paint a result for an input you have moved past. Each emitted frame draws its input and output from one snapshot, and only the latest is painted.

Split the work across a pool, or let the compute itself await, and responses can arrive out of order for real; the same id covers that case too. With one synchronous worker the order already holds, and the id still earns its place, because the cancel cannot stop the superseded compute from coming back.

Here is the minimal correct core, the same repro with both changes in place:

// The minimal coherent core
function CoherentSquare() {
  const [n, setN] = useState(2);
  const [pair, setPair] = useState({ in: 2, out: 4 }); // 1: one store, one pair
  const currentId = useRef(0);

  useEffect(() => {
    const id = ++currentId.current; // 2: identity tag for this input
    const ctrl = new AbortController();
    asyncSquare(n, ctrl.signal)
      .then((out) => {
        if (id === currentId.current) setPair({ in: n, out }); // drop stale
      })
      .catch(() => {});
    return () => ctrl.abort();
  }, [n]);

  return (
    <>
      <input type="number" value={n} onChange={(e) => setN(+e.target.value)} />
      <p>
        {pair.in}² = {pair.out}
      </p>
    </>
  );
}

It reads 2² = 4, then a beat later 7² = 49, then 9² = 81. Never 9² = 49, and never a result for an input you have left. It lags, and it is always true: coherence, not recency, in two lines of difference.

Why an identifier, and not the obvious alternatives. A timestamp ties correctness to input timing: it holds until two snapshots fall in the same millisecond, which a counter never has to rule out. Value equality collapses two distinct snapshots that happen to hold equal inputs. No tag at all, leaning on cancellation, cannot tell you whether a late response belongs to the input on screen. A monotonic identifier, unique by construction, survives all three, which is the only reason it is there.

The second change: a live feed

The coherent square is correct, but it has only ever faced one kind of input. Cancelling on every change to n bakes in an assumption: that n is an intent, where the latest value is the only one you want, so the work for everything before it should be thrown away. For a slider or a typed field that is exactly right, and you have shipped it before: it is the typeahead reflex, cancel the request for the value the user moved past and wait for the one that matches.

It is wrong for a market tick, which typeahead never has to face, because a search box only ever emits intents. Cancel and restart on every tick, with a feed faster than the fit, and nothing ever finishes:

Cancel-and-restart on every tick, feed faster than the fit
fit needs 60 ms;   a tick lands every 20 ms
t=0    tick1   start fit
t=20   tick2   cancel, restart   (20 ms of work binned)
t=40   tick3   cancel, restart   (binned again)
t=60   tick4   cancel, restart   ...

The fit is always part-way into a compute it will never be allowed to complete, and nothing commits. The opposite policy absorbs the ticks: tick1's fit runs to completion, each later tick is noted as the single pending input, and when the fit lands it commits tick1's result and immediately starts the next fit against tick4, the latest input then waiting. You stay a fit behind, and you always finish.

So inputs come in two kinds, and the policies are opposites:

streaming absorbs: a change mid-compute does not cancel; the in-flight completes against its tagged snapshot.
intent cancels-and-restarts: a change mid-compute supersedes the in-flight.

Mixed inputs are the common case, not the exception. The demo runs both at once: a streaming chain underneath and an intent control on top. There is deliberately no third "always use the latest" kind. If that is what you want, you do not need any of this.

Why the things you would reach for do not fix it

This two-way asymmetry is also where the usual tools stop short. Cancellation is the typeahead reflex; like the others it guarantees something real, and none of it is the pairing:

Tool	Guarantees	Does not guarantee
Cancellation (`AbortController`, `switchMap`)	request cancellation	the committed pair
Scheduling (`useDeferredValue`, `useTransition`)	render prioritisation	input-output pairing
Caching (react-query, SWR)	server-state freshness	snapshot coherence

None of them sit at the commit boundary, where an input and an output become one frame. Debouncing an intent or throttling a feed only makes collisions rarer; and keeping the input and the output in separate setStates is the defect itself, not a fix, because the input commits the instant it changes and the output commits when the compute returns, two writes React has no reason to pair.

Where this leaves you, and where Oracaus fits

The invariant and the two guarantees are the transferable part. You can hold them by hand for one derivation. @oracaus/coherent-derivation packages those same two guarantees with the input-kind policies, the tear-free read, and worker and lifecycle handling. One hook, a synthetic-feed demo, no public adopters yet: take it as a worked reference as much as a dependency.

Check it yourself

Open the demo, trigger the vol shock, and watch the two panels. Then watch the two numbers: coherence error diverges on the naive panel while ground-truth fit error stays level across both. The picture is the hook, the number is the claim, reproduce the number.

A perf fix that keeps the interface responsive can still hand the user a frame that was never true. That is composition incoherence: cancellation does not prevent it, recency does not describe it. The moment a derivation runs asynchronously, coherence stops being something the framework hands you and becomes something your architecture has to keep.

The Animation Wasn't Where the Time Went

Przemyslaw Kalka — Fri, 05 Jun 2026 17:40:23 +0000

A chart that never holds still has two clocks. New data lands several times a second and the plot redraws: in the rig I will use here, about 200 points and a fitted curve at 5 Hz. Separately from that, the y-axis occasionally rescales when the reader changes what it spans, and I want that rescale to glide rather than jump.

A chart with 200 dots and a fitted curve.

So two things happen on the same element at once: a transform animation rescale) and a high-frequency content update (the redraw). The instinct is that the hard part is keeping the animation cheap while the redraw keeps firing. I built a rig to measure it, and the instinct pointed at the wrong thing. A transform, handed to the compositor, stays cheap even while the chart redraws at 5 Hz, and the two layout costs I braced for came to nothing. The bill was the redraw itself.

More precisely than the title lets on: in this workload, a compositor-driven transform stays cheap even while the chart redraws at 5 Hz, and the two layout costs I braced for measured as nothing. The bill was the redraw itself.

The naive rescale: interpolate on the main thread

The obvious way to animate a range change is to interpolate it yourself. On each requestAnimationFrame, compute an intermediate range and re-render the chart at it. It works, and it looks smooth.

It also runs the entire animation on the main thread. Every frame recomputes the scales and rebuilds the plot, which is the same redraw cost you already pay at 5 Hz, now paid at 60 Hz for the length of the transition. For that window the animation competes for the main thread with the very updates it is animating over.

Measurements come from a production-built Chrome rig reproducing the workload of the live demo (about 200 moving nodes and a transform rescale, no CPU throttling). Each figure below is total main-thread time accumulated over a five second trace, not a per-frame or per-second number:

5 s window · ~200 nodes · production build · no throttle

                      Scripting   Rendering   Painting   ~main thread
rAF (per-frame)         43 ms       48 ms       16 ms       ~107 ms
WAAPI transform         17 ms       19 ms        4 ms        ~40 ms

The fix: a composited transform, on an element that can take it

The rescale is, geometrically, a pure transform. Re-render the content at the new range immediately, then animate a translateY and scaleY from the value that makes the new layout look like the old range back to identity. Two things have to hold for that to stay off the main thread, and the second is easy to miss.

First, animate transform only, and let React commit once. The keyframes touch nothing but transform; React renders the chart a single time, at the new range, then stays out of the transition. That alone is most of the drop from 107 ms to 40 ms: the main thread stops rebuilding the chart sixty times a second.

Second, animate an element the compositor will actually promote. Chrome runs transform animations on the compositor for HTML and replaced elements, but not for SVG child elements. Put the animation on an inner <g> and it falls back to per-frame main-thread layout, silently, with no warning. So the chart is two layers: a static base SVG for the axes and grid, and an interior layer for the dots, curve and cursor, wrapped in an HTML <div>. The transform animates the <div>.

// yRange changed. The interior is already re-rendered at the new range;
// animate the wrapper from "looks like the old range" to identity.
const sy = (newMax - newMin) / (oldMax - oldMin);
const ty =
  MARGIN.top * (1 - sy) + (innerH * (oldMax - newMax)) / (oldMax - oldMin);

// `layer` is the HTML wrapper around the interior SVG, pinned over the
// base with `inset-0` and `transform-origin: 0 0`, so the maths is the
// same as it would be in the SVG view-box.
layer.animate(
  [
    { transform: `translateY(${ty}px) scaleY(${sy})` },
    { transform: "translateY(0px) scaleY(1)" },
  ],
  { duration: 300, easing: "cubic-bezier(.4, 0, .2, 1)", fill: "forwards" },
);

The compositor handoff.

With both in place the main thread hands off once and goes quiet: the two
keyframes interpolate on the compositor's own thread while the main thread carries only the 5 Hz baseline. The picture on screen is identical; what dropped is main-thread work, not a jump in frame rate.

Confirm it composited; the Animations lane will not tell you. This is the step that is easy to skip, because a transform animation shows up in DevTools' Animations lane whether or not it is on the compositor. The real check is the animation event in a trace: its compositeFailed field reads zero when the animation is composited, and a non-zero bitmask of reasons when it is not. The inner <g> reports a non-zero value; the HTML wrapper reports zero. Skip the check and it is easy to ship a "compositor" animation that is quietly running on the main thread, costing a little layout on every frame.

rAF: Scripting 43, Rendering 48, Painting 16 ms; ~107 ms on the main thread.

WAAPI: Scripting 17, Rendering 19, Painting 4 ms; ~40 ms.

The absolute figures are small because this workload is modest. What matters is where the work lands and how it scales: on the main thread, cost grows with redraw frequency and node count. On the compositor, the transform is largely independent of both.

Two layout costs that didn't bite

Both are versions of the same worry: the browser quietly redoing layout, the pass that works out where every element sits, on each one of those 5 Hz frames. On a hot path that is exactly the kind of cost that hides. I built the rig partly to catch them. Neither fired.

The forced reflow. Layout is normally batched: your code can change a hundred things and the browser works out the new geometry once, just before it paints. But the moment your code reads a geometry value back (an element's position or size), the browser has to stop and compute layout right then. That synchronous, on-demand layout is a forced reflow, and on a hot path it is a classic offender. A CSS-transition build of the rescale includes one: it commits the start state with a geometry read before the transition begins.

It does not cost, and the reason is specific. The thing being animated is a
composited transform, which the browser resolves without touching layout. So when the code forces the read, the transform has invalidated no layout; the read just pulls forward the layout the redraw would do that frame anyway. It reorders work, it does not add it. The two builds come out indistinguishable: 2.5 ms of layout against 2.2 ms over five seconds. A forced reflow only bites when it makes layout run twice (read, change something that invalidates layout, read again). This one runs it once.

Forced reflow: expected two passes, measured one.

The moving reference box. A transform scales and moves an element around a reference box. Tie that box to the element's own content and, next to a constant redraw, it looks like a trap: a box that wraps content shifting every frame shifts too, and the browser might re-resolve the transform against it each time, layout on every redraw. The HTML wrapper closes this off by construction. Its reference box is the chart rectangle, pinned by inset-0; it does not track the dots moving inside it, so there is nothing to re-resolve.

Where the cost actually is

With the animation handed off and the two suspected costs ruled out, the trace points somewhere flat and unglamorous. The dominant per-redraw cost is setAttribute and Recalculate style, together around a third of main-thread time: mutating a couple of hundred SVG nodes' geometry five times a second, and the style invalidation that follows. It is identical across every build, because it has nothing to do with how the rescale is animated.

One redraw, bottom-up: setAttribute and Recalculate style dominate, layout ~5% ('Profiling overhead' is DevTools, not the page).

The lever, then, is the redraw, not the transition: fewer nodes, batched attribute writes, or a different rendering substrate such as canvas. Not the animation, which is free once it is on the compositor, and not the reference box, which was never doing what I thought.

What I would take from this

Compositor-only is the right instinct, and it paid off: the rescale belongs on the compositor, and putting it there, on an element that could take it, dropped main-thread work from about 107 ms to 40 ms over the trace. Two qualifications matter as much as the headline. First, "animate transform and opacity" is necessary, not sufficient: the element has to be one the compositor will promote, and an SVG child is not, so confirm it with the compositeFailed flag rather than trusting the Animations lane. Second, the costs I was most sure about either reorder into nothing or never fire, and the one that dominated is the plain one I had stopped looking at: SVG mutation and style recalculation, roughly a third of main-thread time, untouched by anything I did to the animation.

A plausible mechanism and a measured cost are different things. Only the trace tells you which is which.

Notes

Under prefers-reduced-motion: reduce the animation runs with duration: 0, snapping to the final state: the motion is a visual aid, not load-bearing. A rescale that arrives before the last one finishes cancels the in-flight animation and starts fresh, and the animation is cancelled on unmount, which keeps it correct under React's double-mount in development.

The MDN Web Animations API reference covers the Element.animate handoff used here.