PRNext 0.1.18 versus Next.js: CPU, RAM and sleep

#The exact version behind the numbers

The measurements from October 29, 2026 use the 0.1.18-alpha development candidate at commit 2856155. Its manifest still carried the internal version 0.1.17-alpha, but its code and optimizations differ from the npm 0.1.17-alpha package. The exact measured source and artifact hashes are linked at the end of this article.

The reference is Next.js 16.4.3, using the same React 19.3.1 family and application source. The small VPS runs Node.js 22.23.4; the large one runs Node.js 24.22.1. Within each machine, every engine uses the exact same Node executable. Cross-machine differences cannot be attributed to hardware alone because Node changes too.

PRNext runs the Balanced profile and its default Web renderer. The associated data includes the full Linux binary and candidate package hashes, results before the fixes and throughput ranges. The npm 0.1.18-alpha release published on October 30 comes from commit 05a9ccd, with additional build and development fixes. This campaign therefore measures neither the npm 0.1.17-alpha package nor the final 0.1.18-alpha archives. The numbers describe the identified candidate without assigning a new benchmark to subsequent changes.

#What we measured

The first VPS has one vCPU and about 1.9 GiB of RAM. The second has eight vCPUs and about 23 GiB. Target processes receive cgroup v2 CPU and memory limits with no swap. The small machine is limited to 70% of one CPU and 700 MiB; the large machine is tested at one CPU and 384 MiB, two CPUs and 1 GiB, then four CPUs and 2 GiB.

The main matrix contains 96 windows: four budgets, four scenarios, three variants and two alternating passes. The variants are PRNext before the fixes, the measured PRNext candidate and Next.js. Each window has five seconds of warm-up followed by fifteen measured seconds, using sixteen connections and gzip. The tables compare the candidate with Next.js and report the median of the two windows for each metric.

The scenarios are a dynamic 100-row SSR page, a 1,000-row page, a sixteen-entry JSON API and a page with a 40 ms Suspense delay. Fresh identifiers and cookies check response correctness and isolation. Throughput counts only successful, validated responses. This is not a comparison of static pages served from a CDN.

The p95 is the duration within which 95% of requests finish in a window. CPU is milliseconds of CPU work per successful response, not latency. RAM is median proportional set size, or PSS, across the target process tree, including the native engine and Node workers. A response can take 100 ms while using only a few milliseconds of CPU.

The load generator has separate limits, but shares the small VPS’s single physical CPU. Fast API scenarios can reach its ceiling, particularly on the small machine and in the four-CPU scenario. Existing services remain active: quotas do not eliminate contention on these VPSs. Two short passes do not provide a confidence interval. Small differences should not become marketing promises.

#Small VPS: less CPU, without a general RAM win

At 0.7 CPU and 700 MiB, PRNext serves 81.33 SSR responses per second against Next.js’s 51. Its p95 is 264.25 ms against 420.90 ms. CPU cost falls from 13.39 to 8.46 ms per response, about 37% less. Memory, however, is 113.88 MiB against 101.38 MiB: PRNext uses about 12% more on this page.

Streaming reaches 138.13 requests per second against 80.03, with about 42% less CPU per response. The heavy page is much closer, at 11.33 against 10.33 requests per second. The API favors PRNext in this campaign, but the generator’s competition for the same physical CPU remains a limitation.

PRNext uses more PSS than Next.js in all four scenarios on this machine. The observed advantage is primarily CPU efficiency on ordinary SSR and streaming. A blanket claim of lower RAM would misrepresent these results.

#One CPU and 384 MiB: a different constraint and tradeoff

On the large VPS limited to one CPU and 384 MiB, the SSR page reaches 99.77 requests per second against 59.90. CPU cost is about 41% lower and PSS about 13% lower. Streaming reaches 220.90 against 86.27 requests per second, using 4.51 against 11.47 ms of CPU per response.

The candidate’s tighter memory policy also reduces RAM relative to our earlier PRNext code, but the API loses about 13% of throughput against that earlier code. PRNext still leads Next.js in this measurement; that does not erase the internal regression. The balance between garbage collection and throughput needs more work.

#Two CPUs: a clear SSR gain and a heavy-rendering limit

With two CPUs and 1 GiB, the 100-row SSR page reaches 224.70 requests per second in PRNext against 142.97 in Next.js. That is 57% more throughput, about 26% less CPU per response and 32% less PSS. The p95 is 89.80 ms against 154.60 ms.

The 1,000-row page reverses the result: Next.js reaches 27.63 requests per second against PRNext’s 24, with a p95 of 622.20 ms against 740.80 ms. PRNext uses less RAM but about 29% more CPU per response. Heavy React rendering remains a concrete improvement target.

Streaming retains about 56% more throughput and about 30% less CPU per response. These results apply to this dynamic application, profile and budget, not every React project.

#Four CPUs: topology matters too

At four CPUs and 2 GiB, PRNext uses two workers. Next.js uses two processes behind a private Node proxy, whose CPU and RAM are included. The other three budgets use direct servers. This topology difference is part of the result.

PRNext reaches 383.30 SSR requests per second against 247.13 for this Next.js reference. Its PSS is 206.60 MiB against 458.33 MiB. That does not establish a universal 55% RAM saving: a different topology or proxy could change the result. The API can also reach the generator ceiling.

The candidate loses about 10% of SSR throughput and about 6% on the heavy page compared with our earlier PRNext code at this budget. More CPUs do not guarantee that every path improves. Scaling across workers and heavy-rendering allocations still need work.

#Navigation: fixing our own regression

The first audit found an unusually slow return to a large page. Differential Flight transport produced too many small fragments. The candidate bounds comparison work, groups available data and retains a full-response fallback when a difference is not worthwhile. The aim is to reduce work without waiting for future streaming chunks.

In Chromium 153, we repeated a large-page, small-page, return-to-large-page journey. Each journey checks 3,000 visible cells, counter state and document identity. On the small VPS, PRNext’s return drops from 1,475.6 to 307.2 ms; on the large one, from 932.1 to 228.6 ms.

The roughly fourfold to fivefold gain is against our earlier PRNext code, not Next.js. The candidate remains slightly behind Next.js on this journey on the small VPS and moves ahead on the large one. Eight contexts per variant run on a PC through a tunnel; these are not visitor-collected Core Web Vitals.

Hydration does not show the same improvement. Its median is 421.6 ms for PRNext against 349.8 ms for Next.js on the small VPS, and 399.2 against 299.1 ms on the large one. Transferring fewer bytes is not enough to make the client interactive sooner.

#Sleep mode: release RAM between visits

A low-traffic site does not spend its day saturating a processor. Idle memory can matter more than peak throughput. PRNext can retire its Node workers after an idle period while keeping the Rust server listening. The next rendering request recreates the workers it needs.

We tested this mechanism on the small VPS with a simple SSR page and an accelerated two-second idle threshold. Memory is observed after worker retirement, which took about two seconds; the keep-warm control waits about six seconds. This is one functional probe per setting, separate from load and endurance tests.

In this probe, PSS falls to about 10.5 MiB after worker retirement, against 106.8 MiB when kept warm. The cost appears in the wake request: about 1.13 seconds against 22.6 ms. The 10.5 MiB figure describes this simple application’s process tree in that state, not the whole VPS or every application.

Startup prewarming with --prewarm initializes the framework before accepting requests. It does not prevent subsequent idle retirement and does not call application pages or API handlers. To retain used render hosts, the explicit setting is --worker-idle-seconds 0. Prewarming alone therefore does not eliminate the cost of waking after sleep.

No equivalent Next.js sleep configuration was tested in this probe. It does not establish that external infrastructure cannot stop or restart Next.js.

#Indirect benefits for shared hosting

For several small projects visited at different times, releasing inactive workers’ memory can leave more space for active applications. Better CPU efficiency can also leave more useful work within the same quota. This can be relevant to small public sites, demos and intermittent internal tools.

This is an inference from the measurements, not a hosting-density benchmark. We have not established how many additional projects fit on a server or measured a bill or energy saving. The operating system, database, gateway, simultaneous bursts and wake-ups also consume resources.

The framework also has a local prnext host command that can put a whole application to sleep behind a gateway. This is separate from the worker retirement measured here. The gateway remains active; tracked requests and connections protect work in progress, and a later visit can wake the application. This campaign does not quantify its total cost.

Sleep discards state held only inside processes. Durable data belongs on disk or in an appropriate service; untracked background work must not depend on a process staying alive. The managed PRNext Host service is another layer again. This article does not measure its pricing or deployment performance.

#Observed stability and the limits of the test

Six ten-minute mixed-load runs cover the three variants on both VPSs. Each run is followed by thirty streaming cancellations and 46 quiet seconds. No content failures, load errors or out-of-memory kills of the tested servers were observed in these final campaigns.

An initial endurance attempt exposed memory retention in the load generator, not the tested server. After fixing the tool, all six final runs were repeated in full with the same corrected generator. The tool link points to commit fb59284, separate from the measured engine commit.

Memory still varies: on the constrained large VPS, PRNext moves from 119.0 to 130.4 MiB between the first and last minute. Its mixed throughput is about 12% below our earlier PRNext code on that configuration. Ten minutes establishes neither the absence of leaks nor stability over several weeks.

After cancellation and waiting, PRNext’s file descriptors fall back to 44. This is not enough to declare a leak or rule one out over longer periods. Browser verification adds 48 timed contexts and ten functional checks, including forced fallbacks. It does not demonstrate complete compatibility with all Next.js applications.

#What these results mean for PRNext

The strongest argument is CPU efficiency for ordinary SSR and streaming across several constrained budgets. Memory can also be favorable, but it is not on the physical small VPS in this campaign. Sleep offers another choice for intermittent projects: release RAM or preserve a warm response.

The next priorities are heavy-rendering allocations, hydration, throughput regressions under some budgets and scaling across workers. The few build measurements in this campaign also do not support a general claim of faster builds.

PRNext remains experimental and its Next.js compatibility is partial. To decide whether it fits your application, reproduce its expensive routes, traffic, quiet periods and wake-ups with an identified artifact. These results provide a verifiable starting point, not a universal ranking of frameworks.