SSR: an advantage across all four metrics
On the 100-row page, the PRNext candidate delivers about 57% more throughput with 26% less CPU per response and 32% less PSS than Next.js. Its p95 is also lower. This describes a synthetic page under load, not the speed of every user navigation.
Both servers are direct, with one PRNext worker and one Next.js process, Node 24.22.1 and a 1-GiB memory limit. The two-CPU quota runs on an 8-vCPU, 23-GiB host. This is therefore not a benchmark of a physical two-core machine.
At 1,000 rows, Next.js takes the lead
The PRNext candidate delivers around 13% fewer requests and uses 29% more CPU per response on heavy rendering. Memory remains lower. If this work dominates your application, the short-SSR advantage alone cannot justify a migration.
Streaming shows a throughput advantage for PRNext in this campaign. A short JSON API can be generator-limited, so keep the figures and their caveats together rather than building a ranking from a single test.
Choose around your route mix
Identify how much traffic renders large React trees, waits for external services, or returns JSON. Replay that mix with representative caching and validated content. A strong result on one route suggests a hypothesis; your application workload can confirm or reject it.
All four scenarios, including the tradeoffs
Quota 2 CPU · 1 GiB · Node 24.22.1 · 1 worker PRNext · 1 Next.js process · old-space 384 MiB
Higher throughput is better; lower latency, CPU and memory are better.
SSR · 100 rows| Metric | PRNext candidate | Next.js 16.4.3 |
|---|
| Validated throughputreq/s | 224.70 | 142.97 |
|---|
| p95 latencyms | 89.75 | 154.55 |
|---|
| CPU / responseCPU ms | 7.57 | 10.29 |
|---|
| PSS memoryMiB | 117.50 | 173.30 |
|---|
Heavy SSR · 1,000 rows| Metric | PRNext candidate | Next.js 16.4.3 |
|---|
| Validated throughputreq/s | 24.00 | 27.63 |
|---|
| p95 latencyms | 740.75 | 622.25 |
|---|
| CPU / responseCPU ms | 64.42 | 49.91 |
|---|
| PSS memoryMiB | 164.17 | 198.96 |
|---|
JSON API · 16 entries| Metric | PRNext candidate | Next.js 16.4.3 |
|---|
| Validated throughputreq/s | 2,078.33 | 1,001.40 |
|---|
| p95 latencyms | 14.00 | 28.25 |
|---|
| CPU / responseCPU ms | 0.83 | 1.22 |
|---|
| PSS memoryMiB | 144.80 | 203.93 |
|---|
Streaming · 40 ms Suspense| 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 |
|---|
Which budget matches your project?
How to read this benchmark
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.
Which code was measured?
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.
- Source commit
- 2856155dc32618d00ea7cbe05d771f589c9df536
- Native SHA-256
- e78bce35c1029500eec67d4aad5e3c08a5d9b74b3125aa3d10c854c5a286b843
- Package SHA-256
- 0099abf612f223625caf769f97608be1b4f6daf87a33c2bc92abe9517edbb095
What these results cannot predict
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.
Test your own application
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.