Bundle Size and Performance

Framework client bundles#

The October 25, 2026 run of Vinext's benchmark suite compares the same generated app and published Vinext 1.3.0 dependencies, changing only the browser renderer. It uses the frozen Redact framework release candidate, identified by its package hash in the report.

KB means 1,000 bytes. All six builds returned the same client sizes. Total output includes lazy routes, it is not one page's download. This is the Vinext comparison, not a measurement of adding Redact to Next.js.

Production build times were effectively equal. Development startup was 2.2% faster for App Router and 4.9% faster for the large Pages fixture in this local run. The suite does not time hydration, rendering, interaction responsiveness, or production SSR throughput. Both implementations use native React on the server. Workloads, versions, raw measurements, and uncertainty.

The framework integration stays within the existing runtime size limits: 27,921 bytes gzip for the full built runtime, against 28,183, and 23,304 for default Vite, against 23,335. All 38 size checks.

Earlier runtime measurements#

The remaining measurements describe the 0.1.0 release and its frozen pre-release timing snapshot, compared with React 19.3.0 on September 11, 2026. They are not measurements of every later release.

React and Redact make different runtime tradeoffs. These comparisons help you choose for your app, they don't rank the projects or imply that React's broader capabilities are unnecessary.

Bundle size#

Production ESM bundles retaining all exports from the React, JSX, DOM, and DOM-client entries:

These are runtime bundles, not whole applications. Redact is measured from the 0.1.0 release build. Real apps tree-shake differently, and the runtimes have different scheduling capabilities.

Standalone Redact entries, measured separately:

These entries overlap, so their sizes are not additive. nano removes behavior and is not a full-compatibility preset. The expanded API surface is larger than earlier Redact, not a size reduction over previous releases. Exact configurations, inputs, and historical comparisons.

Performance#

Production microbenchmarks on an Apple M5 Pro, Chrome 152, without CPU throttling: five fresh-browser blocks, five rounds each. Redact uses the built package with default Vite features. Synchronous flushes ensure updates complete before timing stops.

These timings use the frozen pre-release snapshot, before the final hydration-recovery cleanup was merged from 0.0.21. That cleanup passed the release tests; the timing experiments were not repeated.

Times are median averages per completed workload batch in milliseconds, not per component. Negative percentages mean less time. Percentages use paired measurements, not division of the rounded medians.

The largest ratio, Suspense retries, is about 0.15 ms of extra work per cycle here. A cycle covers 96 components, 192 reducer actions, hiding, retrying, revealing, and shared correctness checks. It does not mean interactions feel 2.25 times slower. Larger trees, repeated retries, and slower devices can make the difference matter.

Server rendering#

Separate Node 24 measurements use production source bundles, five fresh-process blocks, and the same checked output. They exclude package startup, network latency, and streaming waterfalls.

Interactions and memory#

Separate 2,400-row fixtures use normal scheduling for clicks and forced garbage collection for retained heap:

Handler-to-commit is not paint latency or field INP; retained heap is not allocation rate or proof of no leaks. Observed click durations were browser-rounded to 16 ms for both; one Redact event entry was absent, not zero.

An identical-React control measured 0.5% median absolute variation across browser workloads, with wider uncertainty in some cases. Small differences need caution. These results do not establish whole-app speedups, behavior under concurrent input, or mobile/Safari/Firefox performance. All intervals and measurements, independent audit.