Next.js 14.2 enthält Verbesserungen für Entwicklung, Produktion und Caching. Unter anderem neue Konfigurationsoptionen, 99% bestandene Turbopack-Tests und mehr.
Next.js 14.2 bringt Verbesserungen für Entwicklung, Produktion und Caching.
In den letzten Monaten haben wir an der Verbesserung der lokalen Entwicklungsleistung mit Turbopack gearbeitet. In Version 14.2 ist der Turbopack Release Candidate nun für die lokale Entwicklung verfügbar:
Wir haben Lightning CSS, einen schnellen CSS-Bundler und Minifier, geschrieben in Rust, integriert.
Wir haben Turbopack intensiv mit Vercels Anwendungen getestet. Zum Beispiel bei vercel.com, einer großen Next.js-App, haben wir folgendes festgestellt:
Bis zu 76,7% schnellere lokale Serverstartzeit.
Bis zu 96,3% schnellere Code-Updates mit Fast Refresh.
Bis zu 45,8% schnellere initiale Route-Kompilierung ohne Caching (Turbopack hat noch kein Disk-Caching).
Turbopack bleibt optional und Sie können es mit folgendem Befehl ausprobieren:
Terminal
next dev --turbo
Wir konzentrieren uns nun auf die Verbesserung der Speichernutzung, die Implementierung von persistentem Caching und next build --turbo.
Speichernutzung - Wir haben Low-Level-Tools zur Untersuchung der Speichernutzung entwickelt. Sie können jetzt Trace-Dateien generieren, die sowohl Leistungsmetriken als auch allgemeine Speichernutzungsinformationen enthalten. Diese Traces ermöglichen es uns, Leistung und Speichernutzung zu untersuchen, ohne Zugriff auf Ihren Quellcode zu benötigen.
Persistentes Caching - Wir untersuchen auch die besten Architekturoptionen und erwarten, in einer zukünftigen Version mehr Details zu teilen.
next build - Während Turbopack für Builds noch nicht verfügbar ist, bestehen bereits 74,7% der Tests. Sie können den Fortschritt unter areweturboyet.com/build verfolgen.
Zusätzlich zu den Verbesserungen beim Bundling mit Turbopack haben wir daran gearbeitet, die allgemeine Build- und Produktionsleistung für alle Next.js-Anwendungen (sowohl Pages als auch App Router) zu verbessern.
Wir haben eine Optimierung für die Grenze zwischen Server- und Client-Komponenten identifiziert, die das Tree-Shaking ungenutzter Exporte ermöglicht. Zum Beispiel wird beim Import einer einzelnen Icon-Komponente aus einer Datei mit "use client" nicht mehr das gesamte Paket mit anderen Icons eingebunden. Dies kann die Größe des produzierten JavaScript-Bundles erheblich reduzieren.
Tests dieser Optimierung mit einer beliebten Bibliothek wie react-aria-components reduzierten die endgültige Bundle-Größe um -51,3%.
Hinweis: Diese Optimierung funktioniert derzeit nicht mit Barrel-Dateien. In der Zwischenzeit können Sie die optimizePackageImports-Konfigurationsoption verwenden:
Für extrem große Next.js-Anwendungen haben wir Out-of-Memory-Abstürze (OOMs) während Produktionsbuilds beobachtet. Nach der Untersuchung von Benutzerberichten und Reproduktionen haben wir festgestellt, dass das Hauptproblem übermäßiges Bundling und Minification war (Next.js erstellte weniger, größere JavaScript-Dateien mit Duplikationen). Wir haben die Bundling-Logik überarbeitet und den Compiler für diese Fälle optimiert.
Unsere ersten Tests zeigen, dass bei einer minimalen Next.js-App der Speicherverbrauch und die Cache-Dateigröße im Durchschnitt von 2,2 GB auf unter 190 MB gesunken sind.
Um das Debuggen der Speicherleistung zu erleichtern, haben wir ein --experimental-debug-memory-usage-Flag für next build eingeführt. Mehr dazu in unserer Dokumentation.
Wir haben aktualisiert, wie CSS während Next.js-Produktionsbuilds optimiert wird, indem wir CSS in Chunks aufteilen, um Konflikte zwischen Stilen beim Navigieren zwischen Seiten zu vermeiden.
Die Reihenfolge und Zusammenführung von CSS-Chunks wird jetzt durch die Importreihenfolge definiert. Zum Beispiel wird base-button.module.css vor page.module.css geordnet:
base-button.tsx
import styles from './base-button.module.css';export function BaseButton() { return <button className={styles.primary} />;}
page.tsx
import { BaseButton } from './base-button';import styles from './page.module.css';export function Page() { return <BaseButton className={styles.primary} />;}
Um die korrekte CSS-Reihenfolge beizubehalten, empfehlen wir:
CSS-Module nur in einer einzigen JS/TS-Datei zu importieren.
Bei Verwendung globaler Klassennamen die globalen Stile in der gleichen JS/TS-Datei zu importieren.
Wir erwarten nicht, dass diese Änderung die meisten Anwendungen negativ beeinflusst. Falls Sie jedoch nach dem Upgrade unerwartete Stile sehen, überprüfen Sie bitte Ihre CSS-Importreihenfolge gemäß den Empfehlungen in unserer Dokumentation.
Caching ist ein entscheidender Bestandteil beim Erstellen schneller und zuverlässiger Webanwendungen. Bei Mutationen erwarten sowohl Benutzer als auch Entwickler, dass der Cache aktualisiert wird, um die neuesten Änderungen widerzuspiegeln. Wir haben untersucht, wie wir das Caching-Erlebnis im App Router von Next.js verbessern können.
Der Client-seitige Router-Cache ist eine Caching-Schicht, die durch das Zwischenspeichern besuchter und vorab geladener Routen auf dem Client ein schnelles Navigationserlebnis bieten soll.
Basierend auf Community-Feedback haben wir eine experimentelle staleTimes-Option hinzugefügt, um die Ungültigkeitsdauer des Client-seitigen Router-Caches konfigurierbar zu machen.
Standardmäßig werden vorab geladene Routen (mit der <Link>-Komponente ohne prefetch-Prop) für 30 Sekunden zwischengespeichert, und wenn das prefetch-Prop auf true gesetzt ist, für 5 Minuten. Sie können diese Standardwerte überschreiben, indem Sie benutzerdefinierte Revalidierungszeiten in next.config.js definieren:
staleTimes zielt darauf ab, die aktuelle Erfahrung von Benutzern zu verbessern, die mehr Kontrolle über Caching-Heuristiken wünschen, ist aber nicht als vollständige Lösung gedacht. In zukünftigen Versionen werden wir uns auf die Verbesserung der allgemeinen Caching-Semantik und die Bereitstellung flexiblerer Lösungen konzentrieren.
Mehr über staleTimes erfahren Sie in unserer Dokumentation.
Wir arbeiten kontinuierlich an der Weiterentwicklung von Parallelen Routen und Intercepting Routes, wobei wir nun die Integration mit dem Client-seitigen Router Cache verbessern.
Parallele und Intercepting Routes, die Server Actions mit revalidatePath oder revalidateTag aufrufen, werden den Cache neu validieren und die sichtbaren Slots aktualisieren, während die aktuelle Ansicht des Nutzers erhalten bleibt.
Ebenso aktualisiert der Aufruf von router.refresh nun korrekt die sichtbaren Slots, wobei die aktuelle Ansicht beibehalten wird.
In Version 14.1 haben wir begonnen, die Lesbarkeit von Fehlermeldungen und Stack Traces bei der Ausführung von next dev zu verbessern. Diese Arbeit wurde in 14.2 fortgesetzt und umfasst nun bessere Fehlermeldungen, Designverbesserungen für das Overlay sowohl im App Router als auch im Pages Router, Unterstützung für Light- und Dark-Mode sowie klarere dev- und build-Logs.
Ein häufiger Verwirrungsfaktor in unserer Community sind React Hydration-Fehler. Während wir Verbesserungen vorgenommen haben, um Nutzern die Ursache von Hydration-Mismatches zu verdeutlichen (siehe unten), arbeiten wir mit dem React-Team zusammen, um die zugrundeliegenden Fehlermeldungen zu verbessern und den Dateinamen anzuzeigen, in dem der Fehler aufgetreten ist.
Vorher:
Ein Beispiel für das Next.js-Fehler-Overlay vor Version 14.2.
Nachher:
Ein Beispiel für das Next.js-Fehler-Overlay nach Version 14.2.
Im Februar kündigte das React-Team die bevorstehende Veröffentlichung von React 19 an. Um uns auf React 19 vorzubereiten, arbeiten wir daran, die neuesten Funktionen und Verbesserungen in Next.js zu integrieren, und planen die Veröffentlichung einer Major-Version, um diese Änderungen zu koordinieren.
Neue Funktionen wie Actions und die damit verbundenen Hooks, die in Next.js bereits über den React Canary Channel verfügbar waren, werden nun für alle React-Anwendungen (einschließlich rein client-seitiger Anwendungen) zur Verfügung stehen. Wir freuen uns auf eine breitere Nutzung dieser Funktionen im React-Ökosystem.
[Dokumentation] Neue Dokumentation zur Video-Optimierung (PR).
[Dokumentation] Neue Dokumentation zu instrumentation.ts (PR)
[Funktion] Neue overrideSrc-Prop für next/image (PR).
[Funktion] Neues revalidateReason-Argument für getStaticProps (PR).
[Verbesserung] Überarbeitete Streaming-Logik, die die Zeit zum Streamen von Seiten in der Produktion reduziert (PR).
[Verbesserung] Unterstützung für verschachtelte Server Actions (PR).
[Verbesserung] Unterstützung für Lokalisierung in generierten Sitemaps (PR).
[Verbesserung] Visuelle Verbesserungen der dev- und build-Logs (PR)
[Verbesserung] Skew Protection ist auf Vercel stabil (Dokumentation).
[Verbesserung]useSelectedLayoutSegment ist nun mit dem Pages Router kompatibel (PR).
[Verbesserung] Warnungen zu metadataBase werden übersprungen, wenn absolute URLs nicht aufgelöst werden müssen (PR).
[Verbesserung] Behebung des Problems, dass Server Actions ohne aktiviertes JavaScript nicht übermittelt werden, wenn sie auf Vercel deployed sind (PR)
[Verbesserung] Behebung des Fehlers, dass eine Server Action nicht im Actions-Manifest gefunden wird, wenn sie nach dem Verlassen der referenzierenden Seite ausgelöst wird oder in einem inaktiven parallelen Routensegment verwendet wird (PR)
[Verbesserung] Behebung von CSS-Importen in Komponenten, die von next/dynamic geladen werden (PR).
[Verbesserung] Warnung, wenn einer animierten Bildkomponente die unoptimized-Prop fehlt (PR).
[Verbesserung] Fehlermeldung, wenn images.loaderFile keine Standardfunktion exportiert (PR)
Next.js hat mittlerweile über 1 Million monatlich aktive Entwickler. Wir sind dankbar für die Unterstützung und Beiträge der Community. Nehmen Sie an der Diskussion teil auf GitHub Discussions, Reddit und Discord.
Next.js ist das Ergebnis der gemeinsamen Arbeit von über 3.000 einzelnen Entwicklern, Industriepartnern wie Google und Meta sowie unserem Kernteam bei Vercel. Diese Version wurde ermöglicht durch:
