# PRNext vs Next.js at 2 CPU · 1 GiB: SSR and heavy rendering

At a 2-CPU, 1-GiB budget, PRNext leads on SSR in this campaign while Next.js leads on heavy rendering. Results, conditions and limitations.

Rendering 100 rows and rendering 1,000 rows tell different stories. At identical resource limits, the route being served can change the runtime decision.

## 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.

## 2 CPU · 1 GiB

Quota 2 CPU · 1 GiB · Node 24.22.1 · 1 worker PRNext · 1 Next.js process · old-space 384 MiB

### SSR · 100 rows

| Metric | PRNext candidate | Next.js 16.4.3 |
| --- | --- | --- |
| Validated throughput (req/s) | 224.70 | 142.97 |
| p95 latency (ms) | 89.75 | 154.55 |
| CPU / response (CPU ms) | 7.57 | 10.29 |
| PSS memory (MiB) | 117.50 | 173.30 |

### Heavy SSR · 1,000 rows

| Metric | PRNext candidate | Next.js 16.4.3 |
| --- | --- | --- |
| Validated throughput (req/s) | 24.00 | 27.63 |
| p95 latency (ms) | 740.75 | 622.25 |
| CPU / response (CPU ms) | 64.42 | 49.91 |
| PSS memory (MiB) | 164.17 | 198.96 |

### JSON API · 16 entries

| Metric | PRNext candidate | Next.js 16.4.3 |
| --- | --- | --- |
| Validated throughput (req/s) | 2,078.33 | 1,001.40 |
| p95 latency (ms) | 14.00 | 28.25 |
| CPU / response (CPU ms) | 0.83 | 1.22 |
| PSS memory (MiB) | 144.80 | 203.93 |

### Streaming · 40 ms Suspense

| Metric | PRNext candidate | Next.js 16.4.3 |
| --- | --- | --- |
| Validated throughput (req/s) | 341.00 | 218.67 |
| p95 latency (ms) | 55.15 | 105.00 |
| CPU / response (CPU ms) | 4.40 | 6.31 |
| PSS memory (MiB) | 154.70 | 206.20 |

## Which budget matches your project?

[PRNext vs Next.js at 0.7 CPU · 700 MiB: the CPU/RAM tradeoff](/benchmarks/prnext-nextjs-0-7-cpu-700-mib)

## 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](/benchmarks/prnext-vs-next-2026-10-29.json)

[Read the full comparison](/blog/prnext-vs-nextjs-vps-benchmarks)

[Fixture](https://github.com/Lorkydey/PRNext/blob/2856155dc32618d00ea7cbe05d771f589c9df536/tests/performance/production-fixture.mjs)

[Corrected load generator](https://github.com/Lorkydey/PRNext/blob/fb59284854850ba0293fab30cc215bbd9aba6c72/tests/performance/production-load.mjs)

[All benchmarks](/benchmarks)

---

Language: en

Canonical: https://prnext.dev/benchmarks/prnext-nextjs-2-cpu-1-gib

Index: https://prnext.dev/llms.txt