PRNext vs Next.js at 2 CPU · 1 GiB: SSR and heavy rendering
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 →BENCHMARKS · OCTOBER 29, 2026
PRNext vs Next.js at 0.7 CPU · 700 MiB: the CPU/RAM tradeoff
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.
Measured: PRNext 0.1.18-alpha candidate, distinct from the final npm archive. Details and hashes below. Which code was measured?
SSR: less CPU, more memory
On the 100-row page, the PRNext candidate uses about 37% less CPU per response and delivers 59% more validated requests than Next.js. Its median PSS is around 12% higher. This may suit a CPU-constrained application, but does not demonstrate a RAM saving.
This budget imposes a 0.7-CPU quota and a 700-MiB memory limit on a host with 1 vCPU and 1.9 GiB. The generator shares that physical CPU. Results describe this specific setup and its contention, rather than every small VPS on the market.
Streaming and heavy rendering: examine the actual cost
The streaming route includes a 40-ms Suspense wait. PRNext uses roughly 42% less CPU per response while memory remains higher. That wait is part of the scenario; the route does not represent every streaming application.
The 1,000-row page increases CPU cost substantially for both runtimes. PRNext retains a small throughput advantage at this budget, but two windows cannot establish that this gap is stable. For a fast API, also check the generator-limitation flag before drawing a conclusion.
Making a small-VPS decision
Measure your server with its dependencies and database, then reserve headroom for bursts. PSS measured under a 700-MiB limit does not mean a 700-MiB VPS is sufficient: the OS, other services and real workloads also need memory. Validate route compatibility before changing runtimes.
All four scenarios, including the tradeoffs
Quota 0.7 CPU · 700 MiB · Node 22.23.4 · 1 worker PRNext · 1 Next.js process · old-space 384 MiB
Higher throughput is better; lower latency, CPU and memory are better.
| Metric | PRNext candidate | Next.js 16.4.3 |
|---|---|---|
| Validated throughputreq/s | 81.33 | 51.00 |
| p95 latencyms | 264.25 | 420.90 |
| CPU / responseCPU ms | 8.46 | 13.39 |
| PSS memoryMiB | 113.88 | 101.38 |
| Metric | PRNext candidate | Next.js 16.4.3 |
|---|---|---|
| Validated throughputreq/s | 11.33 | 10.33 |
| p95 latencyms | 1,550.25 | 1,661.80 |
| CPU / responseCPU ms | 58.92 | 62.10 |
| PSS memoryMiB | 139.51 | 119.46 |
| Metric | PRNext candidate | Next.js 16.4.3 |
|---|---|---|
| Validated throughputreq/s | 518.17 | 352.80 |
| p95 latencyms | 61.40 | 90.05 |
| CPU / responseCPU ms | 1.27 | 1.94 |
| PSS memoryMiB | 139.63 | 113.08 |
The load generator may limit throughput in this scenario. A small gap is insufficient to distinguish the runtimes.
| Metric | PRNext candidate | Next.js 16.4.3 |
|---|---|---|
| Validated throughputreq/s | 138.13 | 80.03 |
| p95 latencyms | 182.65 | 307.25 |
| CPU / responseCPU ms | 4.98 | 8.62 |
| PSS memoryMiB | 135.32 | 115.54 |
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.