Measurements, with their limits #
Different measurements answer different questions. Start with browser memory, then inspect paint timing or server throughput. These results are from the uniform official campaign and are not a current framework ranking or an overall performance score. This page presents all 15 configurations in the campaign.
The server snapshot contains one 20-second measured round per response mode. Browser metrics describe 10 isolated runs per configuration.
Lower uses less JS memory Post-readiness JavaScript heap after explicit Chromium garbage collection. This is not total browser memory.
Official uniform campaign. Browser metrics: 10 isolated runs. Server metrics: 1 × 20-second measured round.
Ordering is descriptive, not evidence of a statistically established winner.
Chromium 156.0.8078.4 · 1,440×900 viewport · 10 randomized cold-cache navigations · fresh foreground process/context/page per sample · native occlusion throttling disabled · no CPU or network throttling Both SSR response modes use one measured round. Browser measurements use progressive responses; renderer-private sample availability is disclosed in the notes. All five metrics are present without JavaScript. The table follows the plot's order.
At narrow widths, scroll the table horizontally. Expand a case for its selected-metric notes. 10 isolated runs · MAD <0.01 MiB · p95 2.14 MiB Uniform official campaign row. The campaign records the benchmark source revision and exact campaign configuration. 10 isolated runs · MAD <0.01 MiB · p95 2.14 MiB Uniform official campaign row. The campaign records the benchmark source revision and exact campaign configuration. 10 isolated runs · MAD <0.01 MiB · p95 2.14 MiB Uniform official campaign row. The campaign records the benchmark source revision and exact campaign configuration. 10 isolated runs · MAD <0.01 MiB · p95 2.37 MiB Uniform official campaign row. The campaign records the benchmark source revision and exact campaign configuration. 10 isolated runs · MAD <0.01 MiB · p95 2.41 MiB Uniform official campaign row. The campaign records the benchmark source revision and exact campaign configuration. 10 isolated runs · MAD <0.01 MiB · p95 2.48 MiB Uniform official campaign row. The campaign records the benchmark source revision and exact campaign configuration. 10 isolated runs · MAD <0.01 MiB · p95 2.71 MiB Uniform official campaign row. The campaign records the benchmark source revision and exact campaign configuration. 10 isolated runs · MAD <0.01 MiB · p95 2.87 MiB Uniform official campaign row. The campaign records the benchmark source revision and exact campaign configuration. 10 isolated runs · MAD <0.01 MiB · p95 2.97 MiB Uniform official campaign row. The campaign records the benchmark source revision and exact campaign configuration. 10 isolated runs · MAD <0.01 MiB · p95 3.22 MiB Uniform official campaign row. The campaign records the benchmark source revision and exact campaign configuration. 10 isolated runs · MAD <0.01 MiB · p95 3.51 MiB Uniform official campaign row. The campaign records the benchmark source revision and exact campaign configuration. 10 isolated runs · MAD <0.01 MiB · p95 3.75 MiB Uniform official campaign row. The campaign records the benchmark source revision and exact campaign configuration. 10 isolated runs · MAD <0.01 MiB · p95 4.7 MiB Uniform official campaign row. The campaign records the benchmark source revision and exact campaign configuration. 10 isolated runs · MAD <0.01 MiB · p95 4.89 MiB Uniform official campaign row. The campaign records the benchmark source revision and exact campaign configuration. 10 isolated runs · MAD <0.01 MiB · p95 4.95 MiB Uniform official campaign row. The campaign records the benchmark source revision and exact campaign configuration. MAD and p95 in the supplied notes are descriptive. In particular, server MAD of zero from one round cannot establish variability or confidence. Download the displayed data (JSON)Five metrics, all 15 cases, and the campaign limitations. Not a complete reproducibility package.JavaScript heap MiB
Recorded setup for JavaScript heap
Data table and measurement notes 15 cases · all 5 metrics
Case and recorded notes JS heap
MiB · lowerRenderer private
MiB · lowerLCP
ms · lowerComplete
req/s · higherProgressive
req/s · higher
WebUI / Light DOM / Bun.serve
JavaScript heap notes
2.14 38.97 52 685.65 532
WebUI / Light DOM / Node node:http
JavaScript heap notes
2.14 43 52 556.5 488.95
WebUI / Light DOM / Rust / Actix
JavaScript heap notes
2.14 42.4 52 1,741.15 1,569.3
Preact
JavaScript heap notes
2.37 43.67 64 421.7 430.65
Astro + Preact
JavaScript heap notes
2.4 44.35 88 31.45 64.25
WebUI / Shadow DOM / Rust / Actix
JavaScript heap notes
2.47 49.28 72 1,396.8 1,185.75
Vue
JavaScript heap notes
2.71 44.34 68 282.05 124.8
Lit
JavaScript heap notes
2.87 57.01 60 82.95 7.95
React
JavaScript heap notes
2.96 48.19 68 490.55 286.3
React + TanStack Router
JavaScript heap notes
3.19 48.71 68 394.7 330.95
Nuxt
JavaScript heap notes
3.5 47.77 76 80.55 80.7
Next.js
JavaScript heap notes
3.75 48.18 72 151.2 154.4
Solid
JavaScript heap notes
4.7 51.13 108 328.2 247.75
SvelteKit
JavaScript heap notes
4.89 50.9 72 279.9 267.65
WebUI / FAST V3 / Rust / Actix
JavaScript heap notes
4.94 52.62 72 1,049.9 681.5
Benchmark notes
Official campaign results for a 100-todo app, not a current framework ranking. The featured WebUI configuration uses Light DOM with Rust and Actix.
- Complete responses. Fully collected HTML responses at 64 connections; response sizes differ. 1 measured round (20 s); variability is not established.
- Streaming responses. The progressive category uses 64 connections and each configuration's existing response behavior, including buffered routes. A dedicated WebUI resumable async data-boundary workload was not measured. 1 measured round (20 s); variability is not established.
- JavaScript heap after GC. Heap after readiness and explicit Chromium garbage collection, not total browser memory. 10 isolated Chromium desktop runs.
- Renderer private bytes. Private bytes of the isolated Chromium renderer after readiness, not server RSS. Some samples were unavailable; see the full data for available sample counts. 10 isolated Chromium desktop runs.
The campaign covers all 15 configurations from one clean source revision. The download is a sanitized extract, not a complete raw-run archive.
What this snapshot describes #
The recorded server workload uses 100 todos, 13 component types, 32 warm structural variants, and current UTC state materialized per request. It records 64 connections from two load workers against one server process/worker pinned to one CPU, with one 20-second measured round. Responses retain their natural byte sizes.
The browser setup identifies Chromium 156.0.8078.4, a 1,440 × 900 viewport, 10 randomized cold-cache navigations, and a fresh foreground process/context/page per sample. Native occlusion throttling was disabled; there was no CPU or network throttling. These are lab measurements, not field Core Web Vitals.
- JavaScript heap is recorded after readiness and explicit garbage collection. It is only part of browser memory.
- Renderer private bytes describe the isolated Chromium renderer process, not server RSS. Both memory metrics display MiB, where 1 MiB is 1,048,576 bytes; the download retains the original byte values. Some renderer-private samples are unavailable; the per-case notes disclose the sample counts.
- LCP is pre-interaction largest contentful paint from navigation start, in milliseconds. It does not describe interaction responsiveness.
- Complete and progressive throughput are requests per second under different response modes. The progressive category preserves each case's existing behavior, including buffered synchronous routes. A dedicated WebUI resumable async data-boundary workload was not measured.
Some server notes report still-rising 128-connection saturation probes. The displayed measurements remain the 64-connection results, not demonstrated maximum throughput. CPU/request and server RSS are different measurements; they are not combined with these five metrics or presented as an overall score.
What is missing #
The benchmark source records the complete and progressive SSR reports and the progressive browser report. The displayed campaign uses released WebUI 3.0.4 and one clean source revision across all 15 cases; it is not the earlier selective refresh.
The sanitized extract does not embed the complete raw-run archive or every framework binary artifact. Campaign source revision, fixture digest, WebUI version, response modes, sampling counts, and methodology are recorded in the benchmark evidence contract.
One server round cannot estimate run-to-run variability. A MAD of zero in that record is not a confidence claim. Browser MAD and p95 notes remain descriptive; without repeated independent server rounds, small differences must not be promoted as statistically established wins.
Inspect the data, then measure your application #
Download the displayed data as JSON. This generated, sanitized extract includes the 15 displayed cases, the five metrics, recorded notes, sampling information, and the limitations on this page. It omits bulk server telemetry and unsupported winner summaries. It makes the display inspectable; it is not a complete reproducibility package.
Use these results to frame questions, not to choose a framework from a single number. Response size, memory, startup, interaction, and sustained load each need measurement in your own environment. The performance guide explains where WebUI moves work and how to evaluate those tradeoffs.