perf: Re-renders take ~2× the CPU of React 19.3 in two production TanStack Start sites (0.2.0)

Ouverte
  • Quelque chose ne va pas ?
#75 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@tannerlinsley y travaille déjà.

Depuis le 2/11/2026.

  • #133 par @tannerlinsley — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
react, typescript
Domaine
frontend, performance

Piste de recherche

Start by examining the reported hot paths in dom/commit.js, dom/reconcile.js, and dom/dispatcher.js, especially rememberFiber, renderHost, and commitPlacements; compare their work during repeated billing tab updates with React's behavior. Use the attached click traces and CPU profiles, or reproduce with the public pricing pages, to identify the extra render and commit bookkeeping. Done means large tree updates no longer show roughly double the CPU cost while preserving the reported identical DOM mutations.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

We evaluated Redact 0.2.0 on our two marketing sites, webcatalog.io and lexibird.com. Both run TanStack Start on Cloudflare Workers.

Adopting it was a drop-in change: builds, SSR, hydration and client-side navigation all worked. The size saving matched the announcement, and hydration blocked the main thread less than React's. But updates after load cost about 2× more CPU than React 19.3.1, and clicks that re-render a large part of the page became about twice as slow. Numbers, method, and CPU profiles and DevTools traces below.

Setup

  • @tanstack/redact 0.2.0: redact() placed first in the plugins list with default options (full preset). No other changes.
  • @tanstack/react-start 1.169.3, @tanstack/react-router 1.170.45, react/react-dom 19.3.1
  • vite 8.3.5 (Rolldown), @vitejs/plugin-react 6.1.2 with the React Compiler (babel-plugin-react-compiler 1.0.0)
  • @cloudflare/vite-plugin 1.64.0 (plain plugin, not @tanstack/redact/cloudflare)
  • UI: Tailwind 4 with @base-ui/react 1.9.0 (Tabs, Accordion)
  • Production builds served by vite preview (workerd), behind a local brotli proxy so transfer sizes match production. Headless Chromium on Linux x64 (a shared cloud container), with 4× CPU throttling applied via CDP (Emulation.setCPUThrottlingRate).

Bundle size: as advertised

The JS+CSS each page loads, from the TanStack Start route manifest plus its static imports:

Page React (gzip) Redact (gzip) Saved
webcatalog.io home 444.6 KB 397.3 KB −47.3 KB
webcatalog.io pricing 417.2 KB 370.3 KB −46.9 KB
lexibird.com home 352.1 KB 305.2 KB −46.9 KB
lexibird.com pricing 361.3 KB 314.2 KB −47.1 KB

That's about 44 KB less transferred with brotli on every page, in line with the 47.0 KB in the Start row of the announcement.

Interaction latency: ~2× slower

Each pricing page has a billing-cycle Tabs that re-renders all of the page's pricing cards, plus a FAQ Accordion. We toggled the tab 9 times and opened 4 FAQ items per load, in a 412×915 viewport. Each interaction's duration is the max Event Timing duration for its interactionId, the same input INP uses. There were 6 loads per runtime, alternating React and Redact builds.

Interaction React 19.3.1 median (range) Redact 0.2.0 median (range)
lexibird.com/en/pricing: billing tab 104 ms (72–200) 200 ms (144–368)
webcatalog.io/en/pricing: billing tab 116 ms (72–216) 252 ms (184–400)
webcatalog.io/en/pricing: FAQ accordion 220 ms (worst 952) 428 ms (worst 1536)
lexibird.com/en/pricing: FAQ accordion 68 ms (worst 360) 76 ms (worst 352)

The small Lexibird FAQ update is unchanged, so the cost seems to scale with how much of the tree re-renders.

This doesn't look like the missing time slicing that the compatibility notes describe. React renders discrete click updates synchronously (SyncLane) too, so neither runtime yields during these updates.

Profiles: where the time goes

We recorded a V8 CPU profile (100 µs sampling) and, in a separate pass, a DevTools trace of 10 billing-tab clicks and of the page load. That's 3 rounds per site and runtime, with 4× CPU throttling. "Runtime CPU" is sampled self time in react-dom/react/scheduler or in @tanstack/redact, attributed through our build's source maps.

10 billing-tab clicks:

Page Runtime CPU, React Runtime CPU, Redact Median click task, React → Redact
lexibird.com/en/pricing 422 / 554 / 872 ms 1459 / 1548 / 1644 ms 143 → 268 ms
webcatalog.io/en/pricing 948 / 951 / 983 ms 1754 / 1986 / 2061 ms 158 → 308 ms

The top Redact frames during clicks (webcatalog.io, round 1, self time) were:

  • rememberFiber (dom/commit.js:143), 158 ms
  • renderHost (dom/reconcile.js:793), 113 ms
  • commitPlacements (dom/reconcile.js:1044), 102 ms
  • useEffectImpl (dom/dispatcher.js:134), 74 ms
  • the anonymous function at dom/commit.js:146, 71 ms
  • renderFunction (dom/reconcile.js:429), 62 ms
  • renderWithHooks (dom/dispatcher.js:76), 60 ms
  • reconcile (dom/reconcile.js:907), 55 ms
  • readContext (dom/reconcile.js:774), 51 ms

commitPlacements is not doing extra DOM work. We counted mutations per billing-tab click with a MutationObserver, and the DOM changes are identical under both runtimes: 12 attribute changes, plus 2 text changes on webcatalog.io and 4 on lexibird.com, with no nodes re-inserted. So the extra time goes into render and commit bookkeeping, not DOM writes.

Page load (navigation until network idle + 1.5 s): load came out better. Main-thread blocking time (the sum over 50 ms of each long task, from the trace) was:

Page React Redact
lexibird.com/en/pricing 1181–1458 ms 418–595 ms
webcatalog.io/en/pricing 973–1468 ms 456–719 ms

The longest task dropped from 377–500 ms to about 220 ms. Total sampled runtime CPU during load was higher under Redact (1.7–2.2 s against 0.45–0.51 s on webcatalog.io), but it was spread over shorter tasks. The Redact load profiles also reach a stack depth of about 378 frames, against 90–170 for React, through walkRetained (dom/walk.js:1), adoptHostDom and hydrateProps (hydration/full.js). That depth may inflate the sampling profiler's numbers, so we'd trust the trace's blocking times more than the CPU totals here.

One oddity: under Redact, a trivial scroll listener in our header showed 60–110 ms of self time during load, on every webcatalog.io round. It runs once on mount and calls setIsScrolled(window.scrollY > 0) from a useEffect. Under React it never appears among the top functions. It might be a synchronous re-render triggered by setState inside a passive effect during hydration being attributed to the caller, but we haven't confirmed that.

Lighthouse, for completeness

Mobile, default simulated throttling, third parties blocked; medians of 7 runs. The simulated TBT got worse under Redact, which contradicts the real-throttling traces above, so we'd discount it:

Page Score LCP TBT (simulated) CLS
lexibird.com/en 75 → 71 4.83 → 4.62 s 290 → 413 ms 0.001 → 0.001
lexibird.com/en/pricing 82 → 68 3.06 → 3.10 s 467 → 1549 ms 0 → 0
lexibird.com/en/solutions/ai-translation 80 → 70 4.69 → 3.30 s 127 → 1002 ms 0.001 → 0.001
webcatalog.io/en/pricing 79 → 67 3.72 → 3.69 s 407 → 1073 ms 0 → 0
webcatalog.io/en/about 72 → 83 4.39 → 3.65 s 560 → 330 ms 0 → 0
webcatalog.io/en/legal/privacy-policy 85 → 77 3.69 → 3.40 s 386 → 727 ms 0 → 0

Attached

redact-traces.zip contains round 1 for both sites and both runtimes:

  • *-load.trace.json and *-clicks.trace.json: DevTools traces you can load in Chrome's Performance panel.
  • *.cpuprofile: V8 CPU profiles from a separate pass, so the tracer doesn't skew them.

The scripts are minified and we haven't attached our source maps; the function names above are mapped to Redact's sources (dist/). Both pricing pages are public (/en/pricing on each site) if you'd like to reproduce with your own builds.

Not verified

  • Whether the React Compiler matters. It's on in both builds and may interact with Redact differently, for example through react/compiler-runtime → @tanstack/redact/compiler-runtime.
  • Real devices. All numbers come from one shared Linux container with CPU throttling; we didn't measure on phones.
Langage dominant
TypeScript
Étoiles
537
Forks
22
Merge moyen
10 h 27 min
PR mergées (30 j)
40

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de TanStack/redact

Toutes les issues de TanStack/redact

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.