# PRNext 0.1.21: weniger Arbeit für Flight und Builds PRNext 0.1.21-alpha ist auf npm verfügbar. Diese Version reduziert vermeidbare Arbeit, ohne das Rendering einer Anwendung zu verändern. Render-Prozesse können das Framework vor ihrer ersten dynamischen Anfrage vorbereiten. Builds verwenden kleine geprüfte Zusammenfassungen erneut, und primitive Cache-Ergebnisse erhalten ein kompaktes privates Format. Komplexe React-Werte behalten die offizielle Flight-Decodierung. Die Version stärkt außerdem die Grenzen zwischen öffentlicher Anfrage, direkt verbundenem Proxy und lokalen Steuerdiensten. Sie baut auf 0.1.20 auf, ohne einen benutzerübergreifenden Antwortcache einzuführen. Autorisierung, Lebensdauer der Daten und Bereitstellungsverfahren bleiben Aufgabe der Anwendung. ## Jeden Render-Prozess vor der ersten dynamischen Antwort vorbereiten Die explizite Option --prewarm bereitet alle Render-Prozesse vor und führt diese Framework-Vorbereitung auch bei Ersatzprozessen und nach dem Aufwachen aus dem Leerlauf aus. Innerhalb des anfänglichen Budgets von 15 Sekunden laufen höchstens zwei Vorbereitungen gleichzeitig. Ein kleines internes RSC- und HTML-Modell durchläuft den offiziellen Renderer, ohne Anwendungsrouten zu importieren oder Kontodaten zu lesen. Die anfängliche Bereitschaft wartet darauf. Anwendungsimporte, Datenbankverbindungen und Anfragedaten können den ersten echten Render weiterhin verlängern. Scheitert die Vorbereitung eines späteren Ersatzprozesses, wird dies diagnostiziert; normale Anfragen können das Framework weiterhin bei Bedarf laden. Dieser verzögerte Start bleibt der Standard. Fehlgeschlagene Anfragen werden nicht wiederholt. Messen Sie Start und erste dynamische Antwort gemeinsam, statt eine erreichbare statische Datei als Beweis für einen vorbereiteten React-Renderer zu betrachten. ```sh npx --no-install prnext start --workers 2 --prewarm ``` ## Weniger Speicherzuweisungen rund um dieselbe Flight-Antwort Flight-Nachrichtenhüllen und Transferlisten werden nur innerhalb ihrer eigenen Antwort wiederverwendet. Nach dem Transfer werden Buffer-Referenzen freigegeben. Große Inline-Bootstrap-Skripte werden direkt in begrenzte Buffer codiert. Weitere Strukturen entstehen erst bei Bedarf, und gewöhnliche vollständige HTML-Fragmente nehmen einen direkten Verarbeitungspfad. Codierter Inhalt, Base64 und CSP-Nonce behalten ihre Bedeutung. Abbruch, Lesekredite, defensive Kopien für extern verwaltete Daten und die Trennung von Antworten bleiben erhalten. Attribute in Anführungszeichen und mehrdeutiges HTML verwenden weiterhin den Parser. Weniger Transportarbeit erlaubt keine Wiederverwendung privater Antworten für andere Anfragen. ## Flight-Größe und Fortschritt des Renderers beobachten Die optional aktivierte Inspektion gruppiert Flight-Bytes, Chunks und Ergebnisse nach Routenmuster und Render-Phase. Abgeschlossene, abgebrochene, fehlgeschlagene und abgelaufene Messungen werden getrennt. Beobachtete Meilensteine zeigen, wann Modell und Shell bereit sind. RSC und SSR können denselben Inhalt erfassen; ihre Größen und Anfragezahlen dürfen deshalb nicht addiert werden. Die Zeiten enthalten Anwendungsarbeit und asynchrone Wartezeiten, nicht nur Encoder- oder Decoder-CPU. Fehlende Messungen bleiben fehlend. Diagnosewerte enthalten keine Antwortkörper, Cookies, Autorisierungswerte oder rohen Suchparameter. Optionale GC-, Heap- und Event-Loop-Daten ergänzen die Sicht. Bei deaktivierter Diagnose wird kein GC-Beobachter angelegt. V8-Standardprofile und explizite Betreiberoptionen bleiben unverändert. ```sh npx --no-install prnext start . --inspect npx --no-install prnext inspect --json ``` ## Build-Metadaten wiederverwenden und Prüfungen beibehalten Wiederholte Builds können begrenzte, typisierte Oxc-Zusammenfassungen mit den später benötigten Direktiven und Exporten wiederverwenden. Diese unveränderlichen Zusammenfassungen enthalten weder Quelltext noch AST oder Anwendungs-Closures. Identitäts- und Generationsprüfungen bestimmen weiterhin, ob ein Eintrag zur aktuellen Eingabe gehört. Fehlende oder ungültige Einträge führen zum normalen Arbeitsweg zurück. Auch die Erkennung nativer Abhängigkeiten verwendet begrenzte Nachweise erneut, wenn ein Graph nachweislich keinen nativen Code enthält. Unbekannte Effekte, eigene Hooks und veränderte Eingaben behalten ihre Prüfungen. Ein undurchsichtiger Graph wird nicht blind als Snapshot wiederverwendet. Referenzanwendungen und Werkzeuge erhalten außerdem ausgewählte Updates, darunter die Referenzstände Next 16.4.4, Better Auth 1.7.15 und Redis-Client 6.3.1. ## Dateiarbeit begrenzen und Build-Phasen sichtbar machen Kopien für Standalone-Traces und Framework-Runtime verwenden begrenzte Parallelität, deterministische Alias-Verarbeitung und Zulassungsbudgets. Änderungen an Quelldateien während des Kopierens bleiben erkennbar. Bei Fehlern werden bereits gestartete Schreibvorgänge abgeschlossen, bevor die temporäre Staging-Ausgabe verworfen wird. Der letzte veröffentlichte Build bleibt erhalten. Pages-Server-Chunks und Source Maps werden vor ihrem ersten Schreiben im Speicher umgeschrieben. build --timings zeigt React-Build-Phasen, um langsame Compiler-Schritte von Dateiarbeit zu unterscheiden. Die Gesamtzeit enthält nicht den Start der CLI-Module. Verschachtelte Phasen überschneiden sich; ihre Zeiten dürfen nicht einfach addiert werden. Berichte bleiben außerhalb der Deployment-Manifeste und Browser-Assets. ```sh npx --no-install prnext build --timings ``` ## React behält die Kontrolle über Cache-Werte und PPR-Fortsetzungen Ein Cache-Callback wird weiterhin einmal im offiziellen React-Renderer ausgeführt, einschließlich seines React.cache-Kontexts. Geeignete primitive Ergebnisse verwenden ein kompaktes versioniertes Privatformat. Objekte, React-Knoten, Funktionen und temporäre Referenzen behalten den kanonischen Flight-Pfad, bei gewöhnlichen komplexen Ergebnissen mit den ursprünglichen Bytes. Strings mit BOM, ungültigem UTF-16 oder Werten nahe dem Render-Limit bleiben ebenfalls beim offiziellen Flight-Verhalten. Private Anfragebereiche, Tags, TTLs und neu decodierte Objekte bleiben erhalten. Es ändert sich der Ergebnis-Codec, nicht die Trennung zwischen Konten. Bei nativem PPR dürfen begrenzte unveränderliche Parsing- und Präfixdaten erst nach erneuter Prüfung der aktuellen Artefaktbytes und ihres SHA wiederverwendet werden. Veränderliche Fortsetzungen werden pro Anfrage geklont. Verschachtelte oder nicht direkte Fortsetzungen behalten bei Bedarf die vorhandene Normalisierung. RSC-Einträge verwenden zudem einen neuen Schlüsselraum. Nach dem Update werden alte Ergebnisse nicht wiederverwendet: Die ersten Aufrufe füllen geeignete Caches neu. Berücksichtigen Sie diese Kosten bei der Beobachtung des Aufwärmens. ## Verlassene Entwicklungsanfragen aus der Warteschlange entfernen Eine abgebrochene oder abgelaufene Entwicklungsanfrage hält ihren noch wartenden Kompilierungsbedarf nicht mehr aktiv. Eine gemeinsam benötigte Kompilierung, auf die ein anderer Aufrufer noch wartet, behält ihren eigenen Lebenszyklus. So entfällt Arbeit für getrennte Verbindungen, ohne einen nützlichen Build für einen anderen Tab abzubrechen. Entwicklungs-RPC-Benachrichtigungen bleiben nach ihrer ersten akzeptierten Veröffentlichung maßgeblich. Ein verspäteter Datei-Snapshot kann keine Diagnose wiederherstellen, die RPC bereits gelöscht hat. Reine Dateibenachrichtigungen bleiben verfügbar, bis RPC eingerichtet ist, ohne alte Generationen zu vermischen. In der Entwicklung stimmen aufeinanderfolgende Navigationen und Fast Refresh auch ihre Flight-Streams aufeinander ab. Eine noch laufende Antwort kann der nächsten Route weichen, ohne einen älteren Komponentenbaum wiederherzustellen und dabei den Zustand des gemeinsamen Layouts zu verlieren. Die Änderung gilt für Navigations-GETs in der Entwicklung und wiederholt keine Mutationen. Produktionsantworten und Server Actions behalten ihre strikte Dekodierung. Ist navigationCache.authCookies für die Sitzungscookies konfiguriert, hat die erneute Autorisierung Vorrang: Entwürfe eines Benutzers werden nicht für einen anderen wiederverwendet. Eine Server Action kann auch die Ansicht ersetzen, während ein bereits angewendetes Update bestätigt wird. Fast Refresh unterscheidet diesen Ansichtswechsel nun vom Abbruch des Updates. Echte Fehler, Abbrüche und Netzwerkfristen bleiben Fehlerfälle, ohne die Action erneut zu senden. Diese Entwicklungsintegration bleibt an die mit PRNext geprüfte React-Version gebunden. Sie nutzt eine experimentelle Option des Flight-Clients, ohne dieses Verhalten in der Produktion zu aktivieren. ## Node 26 mit denselben Anwendungsartefakten qualifizieren Die Linux-CI ergänzt Node-26-Prüfungen für Runtime und HTTP, Chromium, den SaaS-Verbraucher und Paketinstallationen mit Hoisting und verschachtelten Verzeichnissen. Die zusätzliche Browser-Abdeckung betrifft Chromium. Sie ersetzt weder die Hauptmatrix für Linux, macOS und Windows noch die Auswahl der Node-Runtime einer Bereitstellung. Funktionale Abdeckung liefert keinen Durchsatzwert für Node 26. Vergleichen Sie einen Runtime-Wechsel mit denselben Artefakten und Abhängigkeiten und prüfen Sie die eigenen Anwendungsabläufe. Dieser Kampagne unter Node 22.23.4 wird kein zahlenmäßiger Node-26-Gewinn zugeschrieben. ## Jedes Messergebnis im richtigen Umfang lesen Der kontrollierte Vergleich des veröffentlichten 0.1.20-Quellstands mit Kandidat 7c15132a läuft unter Linux x64 und Node 22.23.4. Er umfasst zwölf Paare je Route und insgesamt 72 Messfenster mit zwei Workern, sichtbaren Grenzen von zwei CPUs und 5 GiB sowie Bindung an diese beiden CPUs. Jedes Fenster dauert nach zwei Sekunden Aufwärmen fünfzehn Sekunden, mit acht SSR-, zwei JSON-API- und acht Streaming-Verbindungen. Innerhalb der Messfenster wurden 774.665 gültige Antworten abgeschlossen, einschließlich Auslaufphase 775.089. Die 424 Abschlüsse während der Auslaufphase zählen nicht zum Durchsatz. Die Fehlerzähler für HTTP, Transport und Validierung stehen auf null. Das Aufwärmen wird getrennt gezählt: 51.123 Abschlüsse innerhalb seiner Fenster und 51.552 einschließlich Auslaufphase. Die Mediane der gepaarten Kandidat/Basis-Durchsatzverhältnisse betragen 0,9944 für SSR, 0,9941 für die JSON-API und 0,9978 für Streaming. Die zugehörigen p95-Verhältnisse sind 1,0361, 1,0056 und 1,0028. Alle berichteten gepaarten Intervalle enthalten 1. Die vorab festgelegten Budgets von höchstens 10% Durchsatzverlust und 15% p95-Anstieg werden eingehalten. Diese Ergebnisse nahe der Basis belegen keine allgemeine Beschleunigung. Das JavaScript-Basisarchiv stimmt exakt mit dem veröffentlichten 0.1.20 überein, das Kandidatenarchiv mit der Linux-Qualifikation dieses Quellstands. Beide nativen Programme wurden jedoch separat neu gebaut und entsprechen weder den exakten Bytes des historischen öffentlichen Native-Archivs noch denen der qualifizierten Native-Release. Das Ergebnis vergleicht diese den Quellen zugeordneten Zusammenstellungen, ohne JavaScript-Änderungen zu isolieren. Kernel- und Prozessbeobachtungen sind für alle 72 Stichproben geprüft. Der Speicher bleibt stichprobenartig erfasst; in Namespaces verborgene übergeordnete Grenzen und Konkurrenzlast auf dem Runner liegen außerhalb dieser Prüfung. Andere Build- und transitive Abhängigkeiten sind nicht vollständig bytegenau zertifiziert. Diese drei synthetischen Lasten belegen weder eine globale CPU- oder RAM-Reduktion noch Produktionskapazität oder ein SLA. ## Öffentliche Origin und lokale Steuerung klar abgrenzen Die gespeicherte Richtlinie für öffentliche Origin und vertrauenswürdige Proxys gilt nun an Entwicklungs-, persistenten und nativen Eingängen für mehrere Anwendungen, einschließlich HTTP- und WebSocket-Weiterleitung. PRNext prüft den tatsächlich verbundenen Peer, bevor weitergeleitete Authority- oder Protokollangaben akzeptiert werden. Eine konfigurierte kanonische Origin hat Vorrang. Das Vertrauen in einen Proxy bestätigt weiterhin keine vollständige Kette von Client-IP-Adressen. Bild-Fallback-URLs werden aus URL-Komponenten aufgebaut. Ihre endgültige normalisierte Origin wird vor einer Ausnahme für interne Abrufe geprüft. Compiler- und Supervisor-RPC authentifizieren beide Endpunkte und binden frische Nonces an die exakten Befehls- und Antwortbytes. Nachrichten und Fristen bleiben begrenzt. Wegen dieses Protokollwechsels muss der alte Supervisor vor dem Update beendet werden. ## Den alten Supervisor vor dem Austausch seiner CLI beenden Wenn Sie den persistenten Supervisor verwenden, prüfen und beenden Sie ihn mit der noch installierten alten CLI unter demselben PRNEXT_PM_HOME, bevor Sie Pakete austauschen. pdown betrifft den Supervisor und alle verwalteten Anwendungen in diesem Verzeichnis. Planen Sie deren Wartung gemeinsam. Ein Update der globalen CLI ersetzt nicht jede Anwendungs-Runtime. Bewahren Sie Quellen, Lockfile, Konfiguration, Build und eine kompatible Datenbanksicherung für den Rückweg auf. ```sh npx --no-install prnext pstatus --json npx --no-install prnext pdown npm install @thomas.f/prnext@0.1.21-alpha npx --no-install prnext check --production --json npx --no-install prnext build ``` Lassen Sie optionale native Abhängigkeiten aktiviert und stimmen Sie ihre Versionen mit dem Framework ab. React, React DOM und react-server-dom-webpack bleiben auf 19.3.1; unterstützt werden Node ^22.23.4, ^24.22.1 oder >=26.12.1. Bauen Sie jede aktivierte Anwendung mit ihrer neuen Runtime neu, bevor der gewünschte Supervisor wieder startet. Die neue CLI lehnt das inkompatible alte Protokoll ab, statt unbemerkt die Kontrolle zu übernehmen. PRNext bleibt eine Alpha mit teilweiser Next.js-Kompatibilität. Ein repräsentativer Anwendungspilot und eigene Zuverlässigkeitsziele müssen noch qualifiziert werden. Prüfen Sie Anmeldung, Kontowechsel, Navigation, Formulare, Streaming, Abhängigkeitsausfälle und Rollback mit Ihrem Produkt. Ein npm-Framework-Update deployt weder PRNext Host noch externe Dienste. Ein Code-Rollback macht keine Datenbankschreibvorgänge rückgängig. ## Technische Referenzen Die sieben Pakete der Version 0.1.21-alpha sind auf npm verfügbar. Der folgende Quellcode und der kontrollierte Vergleich erläutern die Änderungen, ihre Voraussetzungen und die Grenzen der Messungen. [PRNext 0.1.21-alpha auf npm](https://www.npmjs.com/package/@thomas.f/prnext/v/0.1.21-alpha) [Framework-Änderungen und Implementierung](https://github.com/Lorkydey/PRNext/pull/59) [Absicherung von Proxys, Bildern und lokalem RPC](https://github.com/Lorkydey/PRNext/pull/56) [Navigation, Fast Refresh und Upgrade-Hinweise](https://github.com/Lorkydey/PRNext/pull/60) [Zuverlässigkeit von Navigation und Fast Refresh](https://github.com/Lorkydey/PRNext/pull/61) [Quellstand des veröffentlichten Frameworks 7c15132a](https://github.com/Lorkydey/PRNext/commit/7c15132ade6da37c8a858873d405b33b4e566874) [Kontrollierter Vergleich mit 0.1.20](https://github.com/Lorkydey/PRNext/actions/runs/42340893273) Veröffentlicht: 2026-11-07 Geändert: 2026-11-07 Autor: PRNext --- Sprache: de Canonical: https://prnext.dev/de/blog/prnext-0-1-21-flight-cache-node26-builds Index: https://prnext.dev/llms.txt