logoNext.js Deutsch
DokumentationBlogLernen
Einführung/Aufbau Ihrer Anwendung/Deployment/Produktionsbereitmachung

Produktionsbereitmachung

Bevor Sie Ihre Next.js-Anwendung in die Produktion überführen, finden Sie hier einige Empfehlungen für das beste Nutzererlebnis.

Allgemeine Empfehlungen

Caching

Beispiele

Caching verbessert Antwortzeiten und reduziert Anfragen an externe Dienste. Next.js fügt automatisch Cache-Header zu unveränderlichen Assets unter /_next/static hinzu, einschließlich JavaScript, CSS, statischen Bildern und anderen Medien.

Cache-Control: public, max-age=31536000, immutable

In next.config.js gesetzte Cache-Control-Header werden in der Produktion überschrieben, um effektives Caching statischer Assets sicherzustellen. Falls Sie den Cache einer statisch generierten Seite neu validieren müssen, können Sie dies durch Setzen von revalidate in der getStaticProps-Funktion der Seite tun. Bei Verwendung von next/image können Sie minimumCacheTTL für den standardmäßigen Image Optimization-Loader konfigurieren.

Wichtig: Bei lokaler Ausführung mit next dev werden Ihre Header überschrieben, um lokales Caching zu verhindern.

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Sie können auch Cache-Header innerhalb von getServerSideProps und API-Routen für dynamische Antworten verwenden, z.B. mit stale-while-revalidate.

// Dieser Wert gilt für zehn Sekunden als frisch (s-maxage=10).
// Bei einer Wiederholungsanfrage innerhalb der nächsten 10 Sekunden wird der zuvor
// zwischengespeicherte Wert noch als frisch betrachtet. Bei einer Anfrage vor 59 Sekunden
// gilt der zwischengespeicherte Wert als veraltet, wird aber dennoch gerendert (stale-while-revalidate=59).
//
// Im Hintergrund wird eine Revalidierungsanfrage gestellt, um den Cache
// mit einem frischen Wert zu füllen. Beim Aktualisieren der Seite sehen Sie den neuen Wert.
export async function getServerSideProps({ req, res }) {
  res.setHeader(
    'Cache-Control',
    'public, s-maxage=10, stale-while-revalidate=59'
  )

  return {
    props: {},
  }
}

Standardmäßig werden Cache-Control-Header je nach Art der Datenabfrage unterschiedlich gesetzt:

  • Bei Seiten mit getServerSideProps oder getInitialProps wird der Standard-Cache-Control-Header von next start verwendet, um unbeabsichtigtes Caching nicht cachebarer Antworten zu verhindern. Für abweichendes Cache-Verhalten mit getServerSideProps verwenden Sie res.setHeader('Cache-Control', 'gewünschter_wert') innerhalb der Funktion wie oben gezeigt.
  • Bei Seiten mit getStaticProps wird ein Cache-Control-Header mit s-maxage=REVALIDATE_SECONDS, stale-while-revalidate gesetzt, oder falls revalidate nicht verwendet wird, s-maxage=31536000, stale-while-revalidate für maximal mögliche Cache-Dauer.

Hinweis: Ihr Deployment-Anbieter muss Caching für dynamische Antworten unterstützen. Bei Selbsthosting müssen Sie diese Logik selbst mittels Key/Value-Store wie Redis implementieren. Bei Vercel funktioniert Edge Caching ohne Konfiguration.

Reduzierung der JavaScript-Größe

Beispiele

Um die Menge an JavaScript im Browser zu reduzieren, können Sie folgende Tools nutzen, um den Inhalt jedes JavaScript-Bundles zu analysieren:

  • Import Cost – Zeigt die Größe importierter Pakete in VSCode an.
  • Package Phobia – Ermittelt die Kosten für neue Dev-Abhängigkeiten.
  • Bundle Phobia – Analysiert die Auswirkungen von Abhängigkeiten auf die Bundle-Größe.
  • Webpack Bundle Analyzer – Visualisiert die Größe von Webpack-Ausgabedateien mit interaktiver, zoomfähiger Baumdarstellung.
  • bundlejs – Online-Tool zur schnellen Bundelung und Minimierung mit Anzeige der komprimierten gzip/brotli Bundle-Größe.

Jede Datei in Ihrem pages/-Verzeichnis wird während next build automatisch in ein eigenes JavaScript-Bundle aufgeteilt. Sie können auch dynamische Imports für Lazy Loading von Komponenten und Bibliotheken nutzen, z.B. um Modal-Code erst beim Klick auf einen Button zu laden.

Logging

Beispiele

Da Next.js sowohl client- als auch serverseitig läuft, werden verschiedene Logging-Formen unterstützt:

  • console.log im Browser
  • stdout auf dem Server

Für strukturiertes Logging empfehlen wir Pino. Bei Vercel gibt es vorkonfigurierte Logging-Integrationen für Next.js.

Fehlerbehandlung

Beispiele

Bei unbehandelten Ausnahmen können Sie mit der 500-Seite das Nutzererlebnis steuern. Wir empfehlen, diese an Ihr Branding anzupassen statt das Next.js-Standarddesign zu nutzen.

Sie können Ausnahmen auch mit Tools wie Sentry protokollieren. Dieses Beispiel zeigt die Fehlererfassung client- und serverseitig mit dem Sentry-SDK für Next.js. Es gibt auch eine Sentry-Integration für Vercel.

Ladeperformance

Für bessere Ladeperformance müssen Sie zunächst messen, was und wie Sie messen wollen. Core Web Vitals ist ein guter Industriestandard, gemessen mit Ihrem Browser. Falls Sie mit den Metriken nicht vertraut sind, lesen Sie diesen Blogpost und bestimmen Sie relevante Metriken. Idealerweise messen Sie die Performance in folgenden Umgebungen:

  • Im Labor, auf Ihrem Rechner oder Simulator
  • Im Feld, mit echten Nutzerdaten
  • Lokal, mit Tests auf Ihrem Gerät
  • Remote, mit Cloud-basierten Tests

Nach Einrichtung der Messung können Sie die Performance iterativ mit folgenden Strategien verbessern:

  • Nutzen Sie Caching-Regionen nahe Ihrer Datenbank/API.
  • Verwenden Sie wie im Caching-Abschnitt beschrieben einen stale-while-revalidate-Wert, der Ihr Backend nicht überlastet.
  • Nutzen Sie Inkrementelle Statische Regeneration zur Reduzierung von Backend-Anfragen.
  • Entfernen Sie ungenutztes JavaScript. Dieser Blogpost erklärt die Auswirkungen auf Core Web Vitals und Strategien wie:
    • Importkosten-Anzeige im Code-Editor
    • Alternative, kleinere Pakete
    • Dynamisches Laden von Komponenten und Abhängigkeiten

Deployment

Erfahren Sie, wie Sie Ihre Next.js-Anwendung für die Produktion bereitstellen können, entweder verwaltet oder selbst gehostet.

Statische Exporte

Next.js ermöglicht den Start als statische Website oder Single-Page Application (SPA), mit der Option, später Funktionen zu nutzen, die einen Server erfordern.