# PRNext 0.1.18 versus Next.js: CPU, RAM und Schlaf

PRNext 0.1.18-alpha ist verfügbar. Begleitend zu dieser Veröffentlichung veröffentlichen wir Messungen, die am 29 im Oktober mit dem Entwicklungskandidaten durchgeführt wurden. Auf einem kleinen VPS sind CPU-Zeit und Speicher genauso wichtig wie die Anfragegeschwindigkeit. Wir haben diesen Code mit Next.js auf zwei Linux-Maschinen verglichen und dann deren Ressourcen eingeschränkt, um zu sehen, wie sich das Ergebnis mit der Arbeitslast ändert.

Der PRNext-Kandidat liefert 57% mehr Durchsatz auf unserer 100-row SSR-Seite mit einem Budget von zwei CPU. Auf dem kleinen VPS verbraucht dieselbe Seite etwa 37% weniger CPU pro Antwort, aber mehr RAM. Zusammengenommen erklären diese Ergebnisse den Zweck dieses Vergleichs: Finden Sie heraus, wo PRNext hilft, was es kostet und wo Next.js besser abschneidet.

## Die Ergebnisse auf einen Blick

Mit zwei CPUs und 1 GiB erreicht der Kandidat 224.70 Antworten pro Sekunde im Vergleich zu 142.97 auf der Seite 100-row SSR, also etwa 57% mehr Durchsatz. Auf der 1,000-row-Seite mit demselben Budget führt Next.js. Auch die gemessene Flüssigkeitszufuhr ist mit Next.js auf beiden VPS-Geräten schneller.

Auf dem kleinen VPS sinken die Kosten für normale SSR CPU um etwa 37%, aber PRNext verbraucht mehr Speicher. Der Schlaf des Arbeiters setzt RAM frei, im Gegenzug dafür, dass er langsamer aufwacht. Die folgenden Abschnitte enthalten Versionen, Messungen und die Einschränkungen jedes Szenarios.

[Erkunden Sie Messungen nach CPU-Budget, Speicher und Szenario](/de/benchmarks)

## Die genaue Version hinter den Zahlen

Die Messungen vom Oktober 29, 2026 verwenden den Entwicklungskandidaten 0.1.18-alpha beim Commit 2856155.. Sein Manifest trug immer noch die interne Version 0.1.17-alpha, aber sein Code und seine Optimierungen unterscheiden sich vom Paket npm 0.1.17-alpha. Die genauen gemessenen Quell- und Artefakt-Hashes sind am Ende dieses Artikels verlinkt.

Die Referenz ist Next.js 16.4.3, unter Verwendung derselben React 19.3.1-Familie und Anwendungsquelle. Der kleine VPS läuft Node.js 22.23.4; der große läuft Node.js 24.22.1. Innerhalb jeder Maschine verwendet jede Engine genau die gleiche ausführbare Node-Datei. Unterschiede zwischen Maschinen können nicht allein auf die Hardware zurückgeführt werden, da sich auch Knoten ändern.

PRNext führt das Balanced-Profil und seinen Standard-Web-Renderer aus. Zu den zugehörigen Daten gehören die vollständigen Linux-Binär- und Kandidatenpaket-Hashes, Ergebnisse vor den Korrekturen und Durchsatzbereiche. Die am 30 im Oktober veröffentlichte Version npm 0.1.18-alpha stammt aus dem Commit 05a9ccd und enthält zusätzliche Build- und Entwicklungskorrekturen. Diese Kampagne misst daher weder das Paket npm 0.1.17-alpha noch die endgültigen 0.1.18-alpha-Archive. Die Zahlen beschreiben den identifizierten Kandidaten, ohne späteren Änderungen einen neuen Maßstab zuzuweisen.

## Was wir gemessen haben

Der erste VPS verfügt über eine vCPU und etwa 1.9 GiB von RAM. Der zweite hat acht vCPUs und etwa 23 GiB. Zielprozesse erhalten cgroup v2 CPU und Speicherlimits ohne Swap. Die kleine Maschine ist auf 70% von einem CPU und 700 MiB beschränkt; Die große Maschine wird mit einem CPU und 384 MiB, zwei CPUs und 1 GiB, dann vier CPUs und 2 GiB getestet.

Die Hauptmatrix enthält 96 Fenster: vier Budgets, vier Szenarien, drei Varianten und zwei Wechseldurchgänge. Die Varianten sind PRNext vor den Korrekturen, der gemessene PRNext-Kandidat und Next.js. Jedes Fenster hat fünf Sekunden Aufwärmzeit, gefolgt von fünfzehn gemessenen Sekunden, wobei sechzehn Verbindungen und gzip verwendet werden. Die Tabellen vergleichen den Kandidaten mit Next.js und geben den Median der beiden Fenster für jede Metrik an.

Die Szenarien sind eine dynamische Seite 100-row SSR, eine Seite 1,000-row, eine Seite mit sechzehn Einträgen JSON API und eine Seite mit einer Suspense-Verzögerung 40 ms. Neue Identifikatoren und Cookies überprüfen die Richtigkeit und Isolierung der Antworten. Der Durchsatz zählt nur erfolgreiche, validierte Antworten. Dies ist kein Vergleich statischer Seiten, die von einem CDN bereitgestellt werden.

Der p95 ist die Dauer, innerhalb derer 95% der Anfragen in einem Fenster abgeschlossen werden. CPU sind Millisekunden der CPU-Arbeit pro erfolgreicher Antwort, nicht die Latenz. RAM ist die mittlere proportionale Satzgröße (PSS) im gesamten Zielprozessbaum, einschließlich der nativen Engine und der Node-Worker. Eine Antwort kann 100 ms dauern, während CPU nur wenige Millisekunden beansprucht.

Der Lastgenerator verfügt über separate Grenzwerte, teilt sich jedoch den einzigen physischen CPU des kleinen VPS. Schnelle API-Szenarien können ihre Obergrenze erreichen, insbesondere auf der kleinen Maschine und im Vier-CPU-Szenario. Bestehende Dienste bleiben aktiv: Kontingente beseitigen nicht den Konflikt um diese VPS. Zwei kurze Durchgänge liefern kein Konfidenzintervall. Kleine Unterschiede sollten nicht zu Marketingversprechen werden.

## Kleiner VPS: weniger CPU, ohne allgemeinen RAM-Sieg

Bei 0.7, CPU und 700 MiB liefert PRNext 81.33 SSR Antworten pro Sekunde gegenüber Next.jss 51.. Sein p95 ist 264.25 ms gegenüber 420.90 ms. Die Kosten von CPU sinken von 13.39 auf 8.46 ms pro Antwort, etwa 37% weniger. Der Speicher beträgt jedoch 113.88 MiB gegenüber 101.38 MiB: PRNext verwendet auf dieser Seite etwa 12% mehr.

Streaming erreicht 138.13 Anfragen pro Sekunde gegenüber 80.03, mit etwa 42% weniger CPU pro Antwort. Die schwere Seite liegt mit 11.33 gegenüber 10.33 Anfragen pro Sekunde viel näher. Der API bevorzugt PRNext in dieser Kampagne, aber die Konkurrenz des Generators um den gleichen physischen CPU bleibt eine Einschränkung.

Mittelwerte von zwei Fenstern pro Szenario und Engine. Niedrigere CPU und RAM sind besser.

| Szenario / Motor | Anforderung/s | p95 (ms) | CPU (ms/req) | RAM (MiB) |
| --- | --- | --- | --- | --- |
| SSR 100 / PRNext | 81.33 | 264.25 | 8.46 | 113.88 |
| SSR 100 / Next.js | 51.00 | 420.90 | 13.39 | 101.38 |
| SSR 1 000 / PRNext | 11.33 | 1,550.25 | 58.92 | 139.51 |
| SSR 1 000 / Next.js | 10.33 | 1,661.80 | 62.10 | 119.46 |
| API JSON / PRNext | 518.17 | 61.40 | 1.27 | 139.63 |
| API JSON / Next.js | 352.80 | 90.05 | 1.94 | 113.08 |
| 40 ms Streaming / PRNext | 138.13 | 182.65 | 4.98 | 135.32 |
| 40 ms Streaming / Next.js | 80.03 | 307.25 | 8.62 | 115.54 |

PRNext verwendet in allen vier Szenarien auf diesem Computer mehr PSS als Next.js. Der beobachtete Vorteil ist in erster Linie die CPU-Effizienz gegenüber gewöhnlichem SSR und Streaming. Eine pauschale Behauptung eines niedrigeren RAM würde diese Ergebnisse falsch darstellen.

## Ein CPU und 384 MiB: eine andere Einschränkung und ein anderer Kompromiss

Auf dem großen VPS, das auf einen CPU und 384 MiB beschränkt ist, erreicht die SSR-Seite 99.77-Anfragen pro Sekunde, während 59.90. die CPU-Kosten etwa 41% niedriger und PSS etwa 13% niedriger sind. Streaming erreicht 220.90 gegenüber 86.27 Anfragen pro Sekunde, wobei 4.51 gegenüber 11.47 ms von CPU pro Antwort verwendet werden.

Die strengere Speicherrichtlinie des Kandidaten reduziert auch RAM im Vergleich zu unserem früheren PRNext-Code, aber der API verliert etwa 13% an Durchsatz gegenüber diesem früheren Code. PRNext liegt in dieser Messung immer noch vor Next.js; Das löscht die interne Regression nicht aus. Das Gleichgewicht zwischen Speicherbereinigung und Durchsatz erfordert mehr Arbeit.

Mittelwerte von zwei Fenstern pro Szenario und Engine. Niedrigere CPU und RAM sind besser.

| Szenario / Motor | Anforderung/s | p95 (ms) | CPU (ms/req) | RAM (MiB) |
| --- | --- | --- | --- | --- |
| SSR 100 / PRNext | 99.77 | 227.20 | 9.90 | 109.85 |
| SSR 100 / Next.js | 59.90 | 365.35 | 16.78 | 126.50 |
| SSR 1 000 / PRNext | 13.60 | 1,329.65 | 72.82 | 139.97 |
| SSR 1 000 / Next.js | 10.00 | 1,932.90 | 95.47 | 158.74 |
| API JSON / PRNext | 849.63 | 38.75 | 1.18 | 128.40 |
| API JSON / Next.js | 409.13 | 76.85 | 2.45 | 163.78 |
| 40 ms Streaming / PRNext | 220.90 | 108.50 | 4.51 | 140.27 |
| 40 ms Streaming / Next.js | 86.27 | 299.30 | 11.47 | 167.14 |

## Zwei CPUs: ein klarer SSR-Gewinn und ein starkes Rendering-Limit

Mit zwei CPUs und 1 GiB erreicht die Seite 100-row SSR 224.70 Anfragen pro Sekunde in PRNext gegenüber 142.97 in Next.js. Das sind 57% mehr Durchsatz, etwa 26% weniger CPU pro Antwort und 32% weniger PSS. Der p95 ist 89.80 ms gegen 154.60 ms.

Die Seite 1,000-row kehrt das Ergebnis um: Next.js erreicht 27.63 Anfragen pro Sekunde gegenüber PRNexts 24, mit einem p95 von 622.20 ms gegenüber 740.80 ms. PRNext verbraucht weniger RAM, aber etwa 29% mehr CPU pro Antwort. Eine starke React-Wiedergabe bleibt ein konkretes Verbesserungsziel.

Mittelwerte von zwei Fenstern pro Szenario und Engine. Niedrigere CPU und RAM sind besser.

| Szenario / Motor | Anforderung/s | p95 (ms) | CPU (ms/req) | RAM (MiB) |
| --- | --- | --- | --- | --- |
| SSR 100 / PRNext | 224.70 | 89.75 | 7.57 | 117.50 |
| SSR 100 / Next.js | 142.97 | 154.55 | 10.29 | 173.30 |
| SSR 1 000 / PRNext | 24.00 | 740.75 | 64.42 | 164.17 |
| SSR 1 000 / Next.js | 27.63 | 622.25 | 49.91 | 198.96 |
| API JSON / PRNext | 2,078.33 | 14.00 | 0.83 | 144.80 |
| API JSON / Next.js | 1,001.40 | 28.25 | 1.22 | 203.93 |
| 40 ms Streaming / PRNext | 341.00 | 55.15 | 4.40 | 154.70 |
| 40 ms Streaming / Next.js | 218.67 | 105.00 | 6.31 | 206.20 |

Beim Streaming bleibt etwa 56% mehr Durchsatz und etwa 30% weniger CPU pro Antwort erhalten. Diese Ergebnisse gelten für diese dynamische Anwendung, dieses Profil und dieses Budget, nicht für jedes React-Projekt.

## Vier CPUs: Auch die Topologie ist wichtig

Bei vier CPUs und 2 GiB verwendet PRNext zwei Worker. Next.js verwendet zwei Prozesse hinter einem privaten Node-Proxy, dessen CPU und RAM enthalten sind. Die anderen drei Budgets verwenden direkte Server. Dieser Topologieunterschied ist Teil des Ergebnisses.

PRNext erreicht 383.30 SSR Anfragen pro Sekunde gegen 247.13 für diese Next.js-Referenz. Sein PSS ist 206.60 MiB gegenüber 458.33 MiB. Dadurch wird keine universelle 55% RAM-Einsparung erreicht: Eine andere Topologie oder ein anderer Proxy könnte das Ergebnis ändern. Der API kann auch bis zur Generatordecke reichen.

Mittelwerte von zwei Fenstern pro Szenario und Engine. Niedrigere CPU und RAM sind besser.

| Szenario / Motor | Anforderung/s | p95 (ms) | CPU (ms/req) | RAM (MiB) |
| --- | --- | --- | --- | --- |
| SSR 100 / PRNext | 383.30 | 56.35 | 8.49 | 206.60 |
| SSR 100 / Next.js | 247.13 | 133.50 | 11.80 | 458.33 |
| SSR 1 000 / PRNext | 46.37 | 450.10 | 68.28 | 272.22 |
| SSR 1 000 / Next.js | 45.50 | 688.85 | 62.55 | 520.04 |
| API JSON / PRNext | 3,421.17 | 8.20 | 0.91 | 242.97 |
| API JSON / Next.js | 1,582.60 | 24.05 | 1.90 | 525.35 |
| 40 ms Streaming / PRNext | 356.90 | 48.45 | 5.09 | 262.35 |
| 40 ms Streaming / Next.js | 313.77 | 68.75 | 7.98 | 542.40 |

Der Kandidat verliert etwa 10% des SSR-Durchsatzes und etwa 6% auf der schweren Seite im Vergleich zu unserem früheren PRNext-Code bei diesem Budget. Mehr CPUs garantieren nicht, dass sich jeder Pfad verbessert. Die Skalierung über alle Arbeitskräfte hinweg und die Zuweisungen mit hohem Rendering erfordern noch Arbeit.

## Navigation: Unsere eigene Regression beheben

Bei der ersten Prüfung wurde eine ungewöhnlich langsame Rückkehr zu einer großen Seite festgestellt. Der differenzielle Flugtransport erzeugte zu viele kleine Fragmente. Der Kandidat begrenzt die Vergleichsarbeit, gruppiert verfügbare Daten und behält einen Fallback mit vollständiger Antwort bei, wenn sich ein Unterschied nicht lohnt. Ziel ist es, die Arbeit zu reduzieren, ohne auf zukünftige Streaming-Blöcke warten zu müssen.

In Chromium 153, haben wir eine Reise von großen Seiten, kleinen Seiten und zurück zu großen Seiten wiederholt. Bei jeder Fahrt werden 3,000 sichtbare Zellen, Zählerstand und Dokumentidentität überprüft. Beim kleinen VPS sinkt die Rendite von PRNext von 1,475.6 auf 307.2 ms; auf der großen, von 932.1 bis 228.6 ms.

Zurück zur großen Seite, Median von acht Kontexten pro Engine und VPS.

| VPS | PRNext vor (ms) | PRNext getestet (ms) | Next.js (ms) |
| --- | --- | --- | --- |
| Klein | 1,475.6 | 307.2 | 282.9 |
| Groß | 932.1 | 228.6 | 271.7 |

Der etwa vier- bis fünffache Gewinn bezieht sich auf unseren früheren PRNext-Code, nicht auf Next.js. Der Kandidat bleibt auf dieser Reise auf dem kleinen VPS leicht hinter Next.js zurück und kommt auf dem großen weiter. Acht Kontexte pro Variante laufen auf einem PC durch einen Tunnel; Hierbei handelt es sich nicht um von Besuchern erfasste Core Web Vitals.

Die Flüssigkeitszufuhr zeigt nicht die gleiche Verbesserung. Sein Median beträgt 421.6 ms für PRNext gegenüber 349.8 ms für Next.js beim kleinen VPS und 399.2 gegenüber 299.1 ms beim großen. Die Übertragung weniger Bytes reicht nicht aus, um den Client früher interaktiv zu machen.

## Schlafmodus: Lassen Sie RAM zwischen den Besuchen los

Eine Website mit geringem Datenverkehr verbringt nicht den ganzen Tag damit, einen Prozessor zu überlasten. Leerlaufspeicher kann wichtiger sein als der Spitzendurchsatz. PRNext kann seine Node-Worker nach einer Leerlaufzeit in den Ruhestand schicken, während der Rust-Server weiterhin überwacht. Die nächste Rendering-Anfrage erstellt die benötigten Worker neu.

Wir haben diesen Mechanismus auf dem kleinen VPS mit einer einfachen SSR-Seite und einem beschleunigten Zwei-Sekunden-Leerlaufschwellenwert getestet. Das Gedächtnis wird nach der Pensionierung des Arbeitnehmers beobachtet, was etwa zwei Sekunden dauerte; Die Warmhalteregelung wartet etwa sechs Sekunden. Dabei handelt es sich um eine Funktionssonde pro Einstellung, unabhängig von Belastungs- und Dauertests.

Wake-Sonde auf dem kleinen VPS. Eine Beobachtung pro Einstellung, dieselbe einfache SSR-Seite.

| PRNext-Einstellung | Leise RAM (MiB) | Wake-Anfrage (ms) |
| --- | --- | --- |
| Ruhestand eines untätigen Arbeitnehmers | 10.5 | 1,130.0 |
| Vorwärmen, dann Ruhezustand | 10.4 | 1,126.6 |
| Vorwärmen und warmhalten | 106.8 | 22.6 |

Bei dieser Untersuchung sinkt der PSS nach der Pensionierung des Arbeitnehmers auf etwa 10.5 MiB, im Vergleich zu 106.8 MiB, wenn er warm gehalten wird. Die Kosten erscheinen in der Wake-Anfrage: etwa 1.13 Sekunden gegenüber 22.6 ms. Die Abbildung 10.5 MiB beschreibt den Prozessbaum dieser einfachen Anwendung in diesem Zustand, nicht den gesamten VPS oder jede Anwendung.

Durch die Startvorwärmung mit --prewarm wird das Framework initialisiert, bevor Anfragen angenommen werden. Es verhindert nicht die spätere Stilllegung im Leerlauf und ruft keine Anwendungsseiten oder API-Handler auf. Um verwendete Render-Hosts beizubehalten, lautet die explizite Einstellung --worker-idle-seconds 0.. Durch das Vorwärmen allein entfallen daher nicht die Kosten für das Aufwachen nach dem Ruhezustand.

In diesem Probe wurde keine entsprechende Next.js-Schlafkonfiguration getestet. Es stellt nicht sicher, dass die externe Infrastruktur Next.js nicht stoppen oder neu starten kann.

## Indirekte Vorteile für Shared Hosting

Bei mehreren kleinen Projekten, die zu unterschiedlichen Zeiten besucht werden, kann die Freigabe des Speichers inaktiver Mitarbeiter mehr Platz für aktive Anwendungen schaffen. Eine bessere CPU-Effizienz kann auch dazu führen, dass bei gleichem Kontingent mehr nützliche Arbeit geleistet wird. Dies kann für kleine öffentliche Websites, Demos und zeitweilige interne Tools relevant sein.

Dies ist eine Schlussfolgerung aus den Messungen und kein Benchmark für die Hosting-Dichte. Wir haben weder festgestellt, wie viele zusätzliche Projekte auf einen Server passen, noch haben wir eine Rechnung oder Energieeinsparung gemessen. Auch das Betriebssystem, die Datenbank, das Gateway sowie gleichzeitige Bursts und Wakeups verbrauchen Ressourcen.

Das Framework verfügt außerdem über einen lokalen Befehl prnext host, der eine ganze Anwendung hinter einem Gateway in den Ruhezustand versetzen kann. Dies ist unabhängig von der hier gemessenen Arbeitnehmerrente. Das Gateway bleibt aktiv; Verfolgte Anfragen und Verbindungen schützen laufende Arbeiten und ein späterer Besuch kann die Anwendung aktivieren. Die Gesamtkosten dieser Kampagne werden nicht quantifiziert.

Sleep verwirft den Zustand, der nur innerhalb von Prozessen gespeichert ist. Dauerhafte Daten gehören auf die Festplatte oder in einen entsprechenden Dienst; Nicht verfolgte Hintergrundarbeit darf nicht davon abhängen, dass ein Prozess am Leben bleibt. Der verwaltete PRNext Host-Dienst ist wiederum eine weitere Ebene. In diesem Artikel werden weder die Preise noch die Bereitstellungsleistung bewertet.

## Beobachtete Stabilität und die Grenzen des Tests

Sechs zehnminütige Mischlastläufe decken die drei Varianten auf beiden VPS ab. Auf jeden Lauf folgen dreißig Streaming-Abbrüche und 46 ruhige Sekunden. In diesen letzten Kampagnen wurden keine Inhaltsfehler, Ladefehler oder Abbrüche aufgrund von Speichermangel auf den getesteten Servern beobachtet.

Zehn Minuten Mischlast pro Motor und VPS. Der große VPS ist auf 1 CPU und 384 MiB beschränkt.

| VPS / Motor | Anforderung/s | Erste Minute RAM (MiB) | Last-Minute RAM (MiB) |
| --- | --- | --- | --- |
| Klein / PRNext | 255.6 | 125.3 | 131.3 |
| Klein / Next.js | 202.3 | 106.5 | 114.8 |
| Groß / PRNext | 348.5 | 119.0 | 130.4 |
| Groß / Next.js | 317.6 | 152.5 | 158.0 |

Bei einem ersten Ausdauerversuch wurde die Speicherretention im Lastgenerator aufgedeckt, nicht auf dem getesteten Server. Nach der Reparatur des Werkzeugs wurden alle sechs Endläufe vollständig mit demselben korrigierten Generator wiederholt. Der Tool-Link verweist auf den Commit fb59284, getrennt vom gemessenen Engine-Commit.

Der Speicher variiert immer noch: Auf dem eingeschränkten großen VPS bewegt sich PRNext zwischen der ersten und letzten Minute von 119.0 auf 130.4 MiB. Sein gemischter Durchsatz liegt etwa 12% unter unserem früheren PRNext-Code für diese Konfiguration. Zehn Minuten beweisen weder die Abwesenheit von Lecks noch die Stabilität über mehrere Wochen.

Nach dem Abbruch und Warten fallen die Dateideskriptoren von PRNext auf 44. zurück. Dies reicht nicht aus, um ein Leck zu deklarieren oder über längere Zeiträume auszuschließen. Die Browserüberprüfung fügt 48 zeitgesteuerte Kontexte und zehn Funktionsprüfungen hinzu, einschließlich erzwungener Fallbacks. Es wird keine vollständige Kompatibilität mit allen Next.js-Anwendungen nachgewiesen.

## Was diese Ergebnisse für PRNext bedeuten

Das stärkste Argument ist die CPU-Effizienz für gewöhnliches SSR und das Streaming über mehrere begrenzte Budgets hinweg. Der Speicher kann ebenfalls günstig sein, allerdings handelt es sich bei dieser Kampagne nicht um den physischen kleinen VPS. Sleep bietet eine weitere Option für intermittierende Projekte: Lassen Sie RAM los oder behalten Sie eine warme Reaktion bei.

Die nächsten Prioritäten sind Zuteilungen mit hoher Belastung, Hydratation, Durchsatzregressionen bei einigen Budgets und Skalierung auf alle Arbeitskräfte. Die wenigen Build-Messungen in dieser Kampagne stützen auch nicht die allgemeine Behauptung schnellerer Builds.

PRNext bleibt experimentell und seine Next.js-Kompatibilität ist teilweise. Um zu entscheiden, ob es zu Ihrer Anwendung passt, reproduzieren Sie die teuren Routen, den Verkehr, die Ruhezeiten und die Weckzeiten mit einem identifizierten Artefakt. Diese Ergebnisse stellen einen überprüfbaren Ausgangspunkt dar und stellen kein universelles Ranking von Frameworks dar.

[So vergleichen Sie die Leistung von React SSR](/de/blog/benchmark-react-ssr)

[Wie viel RAM benötigt Next.js auf einem VPS?](/de/blog/nextjs-ram-vps-sizing)

[PRNext und Next.js: Kompatibilitäts- und Migrationsleitfaden](/de/blog/prnext-nextjs-compatibility-migration)

## Sources

[PRNext 0.1.18-alpha: published release / version publiée](https://github.com/Lorkydey/PRNext/releases/tag/v0.1.18-alpha)

[Benchmark data / Données du benchmark (JSON)](/benchmarks/prnext-vs-next-2026-10-29.json)

[PRNext: measured source / code mesuré (2856155)](https://github.com/Lorkydey/PRNext/tree/2856155dc32618d00ea7cbe05d771f589c9df536)

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

[Corrected load generator / générateur corrigé (fb59284)](https://github.com/Lorkydey/PRNext/blob/fb59284854850ba0293fab30cc215bbd9aba6c72/tests/performance/production-load.mjs)

[PRNext: rendering, prewarming and worker retirement](https://github.com/Lorkydey/PRNext/blob/2856155dc32618d00ea7cbe05d771f589c9df536/packages/prnext/docs/ai/deployment.md)

[PRNext: local application gateway](https://github.com/Lorkydey/PRNext/blob/2856155dc32618d00ea7cbe05d771f589c9df536/crates/prnext/src/hosting.rs)

Veröffentlicht: 2026-10-30

Geändert: 2026-10-30

Autor: PRNext

---

Sprache: de

Canonical: https://prnext.dev/de/blog/prnext-vs-nextjs-vps-benchmarks

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