# PRNext 0.1.22-alpha: deutlich mehr Leistung PRNext 0.1.22-alpha ist auf npm verfügbar. In unserem Entwicklungsbenchmark mit einer Tabelle mit tausend Zeilen steigt der mediane Flight-Durchsatz auf das 7,7-Fache und der SSR-Durchsatz auf das 3,97-Fache. Die dekodierte Flight-Nutzlast sinkt um 72,1 %. Verglichen wird dieselbe Tabelle mit deaktivierter und aktivierter Optimierung. Geeignete Präsentationskomponenten nutzen die Änderung automatisch. Eine zusätzliche „use presentation“-Direktive ist nicht erforderlich: PRNext überträgt eine wiederverwendbare Struktur und die angezeigten Werte. Berechnungen bleiben auf dem Server, das HTML bleibt vollständig. Aktualisieren Sie PRNext und bauen Sie Ihre Anwendung neu, um die Optimierung zu nutzen. ## Bis zu 7,7-facher Flight-Durchsatz in unserer Testtabelle Die Entwicklungsmessung zum Quellstand 270ae481 vergleicht dieselbe Tabelle mit deaktivierter und aktivierter Optimierung. Bei tausend Zeilen steigt der mediane SSR-Durchsatz von 48,611 auf 192,765 Anfragen pro Sekunde, also etwa um den Faktor 3,97. Flight steigt von 80,472 auf 619,413, etwa um den Faktor 7,70. Die p95-Werte sinken von 100,52 auf 28,78 ms und von 61,65 auf 8,806 ms. Das Tabellen-HTML ist identisch. Decodiertes Flight schrumpft von 266.672 auf 74.353 Byte, um 72,1 %. Mit gzip beträgt die Reduktion 36,1 %. Codiertes Browser-JavaScript wächst um 606 Byte und benötigt zwei zusätzliche Anfragen. Die lokale Messung verwendet Windows x64, Node 24.22.1, zwei Worker und vier Verbindungen auf einem gemeinsam genutzten PC mit 12 logischen Prozessoren und 32 GiB. Die Kampagne umfasst auch ein SSR-Szenario mit 100 Zeilen. Drei abwechselnde Paare mit einer Sekunde Aufwärmen und drei Messsekunden je Fenster ergeben 18 Fenster und 21.523 fehlerfrei validierte Antworten. Beide Varianten verwenden dieselbe neu gebaute native 0.1.21-Binärdatei. Gemessen wurde Entwicklungsquellcode, weder finale npm-Archive noch ein Vergleich mit Next.js. Der Speicherbedarf variiert; der Browsergewinn bleibt unklar. SQL, Geschäftslogik und DOM werden nicht siebenmal schneller. ## Die Struktur einmal übertragen Flight überträgt die Ausgabe von React Server Components zum Browser. Bei vielen gleich aufgebauten Zeilen kann die Beschreibung jedes Elements mehr kosten als die sichtbaren Daten. PRNext erkennt bestimmte synchrone, reine Komponenten, kompiliert deren statisches Markup und verwendet eine offizielle React-Client-Referenz mit kompakten Anzeigeplätzen. Flight-Protokoll und Decoder bleiben die der unterstützten React-Version. Der Browser lädt ein kleines Darstellungsmodul. JavaScript muss daher weiterhin übertragen und ausgeführt werden. Der Server rendert bereits vorher vollständiges HTML. Kleine Listen oder ungeeignete Werte können die gewöhnliche Darstellung verwenden, ohne allein wegen des Formatwechsels ihren DOM-Wurzelknoten zu ersetzen. Datentabellen, Verzeichnisse und lange Listen reiner Anzeigekarten können viel gleiches Markup enthalten. Wenn PRNext diese Struktur von den angezeigten Werten trennt, sinkt der Aufwand zur Beschreibung der Oberfläche in Flight. Berechnungen und Berechtigungsprüfungen Ihrer Anwendung laufen weiterhin auf dem Server. Der Gewinn hängt davon ab, wie viel geeignete Präsentation übertragen werden muss. ## Private Berechnungen bleiben auf dem Server Bei der kompakten Darstellung gilt: Ein Ausdruck wie row.revenue-row.privateCost wird auf dem Server ausgewertet. Der Browser erhält das angezeigte Ergebnis, nicht beide Operanden oder den ursprünglichen Ausdruck. Dasselbe gilt für Bedingungen zur Textauswahl. Ungenutzte Felder werden nicht automatisch zu Browser-Props. Die Transformation führt keinen gemeinsamen Seiten-Cache zwischen Konten ein und ersetzt keine Berechtigungsprüfung. Anwendungen müssen angezeigte Daten weiterhin autorisieren. Imports, Hooks, Seiteneffekte, eigene Komponenten, interaktive Steuerelemente, rohes HTML und ungeprüfte Attribute behalten den gewohnten Pfad. ## Ein bewusst klarer Geltungsbereich Die automatische Kompilierung gilt für produktive Node-Builds mit App Router. Entwicklung, Pages, Edge und reine HTML-Ausgabe bleiben unverändert. Eigene webpack- oder JSX-Pipelines verwenden weiterhin gewöhnliches Rendering, wenn ihre Kompatibilität nicht nachgewiesen werden kann, auch bei Plugin-Hooks. Entfernen Sie kein benötigtes Plugin, um mehr Komponenten zu erfassen. Die Datei .prnext/presentation-report.json erklärt Compilerentscheidungen, keine tatsächliche kompakte Quote pro Anfrage. Die Qualifizierung trennt eine geeignete kompakte Last von einer authentifizierten PostgreSQL-SaaS-Anwendung mit Übersetzungspipeline und erhält deren Fallback. Eine zwanzigminütige Diagnose bleibt vom zweistündigen Dauertest getrennt. ## Aktualisieren und die Anwendung prüfen Bewahren Sie bisherigen Quellcode, Lockfile, Konfiguration und Deployment für ein Rollback auf. Installieren Sie die Version, bauen Sie die Anwendung neu und starten Sie deren Worker mit übereinstimmenden Framework- und nativen Paketversionen neu. Dateien unter einem laufenden Prozess zu ersetzen aktualisiert den geladenen Code nicht. Zum Vergleich setzen Sie presentationComponents: false in prnext.config.mjs und bauen beide Varianten neu. Prüfen Sie Hydration, Navigation, Kontowechsel, Formulare, Stream-Abbrüche und einen während Deployment und Rollback geöffneten Tab. Veraltete Mutationen müssen ohne automatische Wiederholung abgelehnt werden. PRNext bleibt eine Alpha mit teilweiser Next.js-Kompatibilität: Entscheidend ist das Ergebnis Ihrer Anwendung. ```sh npm install @thomas.f/prnext@0.1.22-alpha npx --no-install prnext check --production --json npx --no-install prnext build ``` [Implementierung und Geltungsbereich](https://github.com/Lorkydey/PRNext/pull/64) [Upgrade-Anleitung](https://github.com/Lorkydey/PRNext/blob/main/docs/UPGRADING-0.1.22.md) Veröffentlicht: 2026-11-08 Geändert: 2026-11-08 Autor: PRNext --- Sprache: de Canonical: https://prnext.dev/de/blog/prnext-0-1-22-automatische-flight-praesentation Index: https://prnext.dev/llms.txt