Benchmarks

One storefront, written in six frameworks and served on the same machine. On the product page FSR answers 77x as many requests as Next.js and beats Leptos, which is Rust from end to end.

The storefront arena

Every app serves the same 48 products, the same stylesheet and the same markup. Each page is checked for its status, its text and its product count before it is loaded. The figures are medians across repetitions, and green marks the best figure in a row and every figure within 5% of it. The tables here use 32 concurrent clients. Click a cell for the exact count. The full results have every client count from 1 to 256, CPU and memory for each page, every page’s size and the method.

SnapFire FSR 0.23.0, Next.js 16.4.4, SvelteKit 3.1.1, Nuxt 4.6.4, Leptos 0.8.23 and Dioxus 0.7.10. Apple M4 Pro, high power mode, measured 2026-11-03 to 2026-11-07.

Requests per second

Responses read in full per second with 32 concurrent clients, higher is better.

Latency

99th percentile in milliseconds, from sending a request to reading its body, with 32 concurrent clients. Lower is better.

The api row serves the catalog as JSON with no render, which is where Leptos and Dioxus catch up.

Compute pages

Requests per second with 32 concurrent clients, higher is better.

Each compute loader loops and allocates on every request: a sieve of Eratosthenes, an aggregation of generated orders sorted with a comparator and a word count over a built-up text. FSR runs the TypeScript loader without a JavaScript engine. On these pages that is slower than SvelteKit on V8 for primes and report. The native column is the same page with its loader calling the Rust that Leptos and Dioxus run, through #[native]. The view and the render are FSR’s either way.

Starting and memory

Lower is better.

FSR starts fastest. Under load it holds more memory than Leptos and Dioxus, though less than the three Node servers.

Production build

Wall time, lower is better. A warm build follows a change to one page.

Size

Lower is better. Page sizes are for the product page, gzipped.

The total to deploy includes Node for Next.js, SvelteKit and Nuxt, since it has to be installed beside them. Leptos and Dioxus hydrate by loading the whole app as WebAssembly. The other four hydrate with JavaScript alone.

The load client runs on the same machine as the servers and takes CPU from them. FSR, Leptos and Dioxus serve on every core. Next.js, SvelteKit and Nuxt each serve from one Node process. Running several behind a balancer is a deployment choice the arena does not make.

The renderer alone

Three storefront pages are rendered three ways with the same props, with no HTTP in the way. Every run asserts the output is byte-identical before it reports a number, so every renderer produced the same HTML.

Warm render

FSR has two columns because the allocator changes its speed by about 1.5x and you choose the allocator when you deploy. Neither the library nor the host picks one. QuickJS uses the same allocator as FSR. Its numbers barely change with the allocator, because most of its allocation happens inside the engine.

How it scales

This renders the same catalogue route at four list lengths, against React in V8 on the same props, with the output checked byte-identical at every length.

Both scale linearly across three orders of magnitude and FSR’s lead grows with list size, so the lead does not depend on one particular page. Each product costs 6.15 µs in FSR and 10.51 µs in V8. The single-item row is mostly fixed per-page overhead, which matters less as the list grows.

Under load

Several requesters render the catalogue as fast as they can for ten seconds and count the completed renders. React server rendering is synchronous work an event loop cannot interleave, so Node is shown both ways it can use more than one core: isolates inside one process and a process per requester.

Renders per second, higher is better:

What each request waits while the others compete, lower is better:

Worker-thread throughput peaks at four requesters and then drops, so compare FSR against the process column, where FSR is 1.37x faster. Node processes take more resources overall, with independent garbage collectors.

Cold start

The two rows measure different things, so don’t compare them with each other. FSR has neither cost. There is no JavaScript engine on the server and a render starts from a tree the build already compiled.

How to read this

These pages are markup-heavy. They loop over data and emit tags, which is most of what a server renderer actually does. It is also where an interpreter walking a lowered tree does less work than a JIT that must first build JavaScript objects to walk. A JIT wins on code doing real arithmetic, which the arena’s compute pages above measure.

Apple M4 Pro, high power mode. Criterion for the Rust and QuickJS rows; the V8 rows are Node v26.8.1, 2000 samples after 500 warmups. Measured 2026-09-07.