BENCHMARKS · OCTOBER 29, 2026
Choose a runtime around the routes your application actually serves. Explore four resource budgets and four scenarios, then examine what each result can support.
Measured: PRNext 0.1.18-alpha candidate, distinct from the final npm archive. Details and hashes below. Which code was measured?
Quota 2 CPU · 1 GiB · Node 24.22.1 · 1 worker PRNext · 1 Next.js process · old-space 384 MiB
These are resource quotas, not dedicated server specifications.
| Metric | PRNext candidate | Next.js 16.4.3 |
|---|---|---|
| Validated throughputreq/s | 341.00 | 218.67 |
| p95 latencyms | 55.15 | 105.00 |
| CPU / responseCPU ms | 4.40 | 6.31 |
| PSS memoryMiB | 154.70 | 206.20 |
Higher throughput is better; lower latency, CPU and memory are better.
When CPU is constrained, reducing its cost per response can help. On a small server, a few extra MiB also matter. This case shows why both measurements belong side by side.
Read the results and tradeoffs →Rendering 100 rows and rendering 1,000 rows tell different stories. At identical resource limits, the route being served can change the runtime decision.
Read the results and tradeoffs →The 2026-10-29 campaign uses React 19.3.1, the PRNext Balanced profile and gzip. Each variant gets 5 seconds of warmup, followed by 15 seconds of measurement with 16 connections. Values are medians of two alternating windows per variant, route and budget.
Throughput counts successful, validated responses. CPU means CPU time per successful response. RAM is median process-tree PSS in MiB, not RSS or total VPS memory. Reported latency is the median of the two window p95 values, rather than a p95 recomputed over all requests.
PRNext is a development candidate for 0.1.18-alpha, with a manifest reporting 0.1.17-alpha. Next.js is version 16.4.3. The final 0.1.18-alpha release was not measured by this campaign: these figures do not measure its npm archive.
Two short repetitions on a synthetic application provide no confidence interval. The small VPS shares its CPU with the load generator, and fast API routes may be generator-limited. Hardware and Node versions differ between hosts, so comparisons across budgets cannot isolate the hardware effect.
These measurements do not establish concurrent product users, how many projects fit on a VPS, or savings on a bill. Databases, external calls, caches, browser work and application wake-ups change the outcome. Sleep and endurance observations remain in the full comparison.
Start with your busiest and most expensive routes. Validate response content and errors before comparing speed. Keep quotas, dependencies, caching settings and load identical for both runtimes. Repeat longer windows before making a decision.