← All benchmarks

BENCHMARKS · OCTOBER 29, 2026

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.

Measured: PRNext 0.1.18-alpha candidate, distinct from the final npm archive. Details and hashes below. Which code was measured?

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
MetricPRNext candidateNext.js 16.4.3
Validated throughputreq/s224.70142.97
p95 latencyms89.75154.55
CPU / responseCPU ms7.5710.29
PSS memoryMiB117.50173.30
Heavy SSR · 1,000 rows
MetricPRNext candidateNext.js 16.4.3
Validated throughputreq/s24.0027.63
p95 latencyms740.75622.25
CPU / responseCPU ms64.4249.91
PSS memoryMiB164.17198.96
JSON API · 16 entries
MetricPRNext candidateNext.js 16.4.3
Validated throughputreq/s2,078.331,001.40
p95 latencyms14.0028.25
CPU / responseCPU ms0.831.22
PSS memoryMiB144.80203.93
Streaming · 40 ms Suspense
MetricPRNext candidateNext.js 16.4.3
Validated throughputreq/s341.00218.67
p95 latencyms55.15105.00
CPU / responseCPU ms4.406.31
PSS memoryMiB154.70206.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.

Data and test protocol

Download the JSON data ↗Read the full comparison →Test application and measured routes ↗Corrected load generator ↗