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

Offen
  • Stimmt etwas nicht?
#75 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
react, typescript
Bereich
frontend, performance

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.
Vorherrschende Sprache
TypeScript
Sterne
537
Forks
22
Ø Merge
1 Std. 57 Min.
Gemergte PRs (30 T.)
20

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus TanStack/redact

Alle Issues in TanStack/redact

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.