BackZurück zum Blog

Next.js 9.3

Next.js 9.3 bringt Verbesserungen für die Static-Site-Generierung, native Unterstützung für SCSS, reduzierte Bundle-Größen, statische 404-Seiten und mehr!

Wir freuen uns, heute Next.js 9.3 vorzustellen, mit folgenden Neuerungen:

Alle diese Verbesserungen sind abwärtskompatibel und brechen nichts existierendes. Für das Update genügt:

Terminal
npm i next@latest react@latest react-dom@latest

Next-gen Static Site Generation (SSG) Support

Beim Erstellen von Websites oder Webanwendungen stehen grundsätzlich zwei Strategien zur Auswahl: Statische Generierung (SSG) oder Server-seitiges Rendering (SSR).

Next.js ist das erste hybride Framework, das Ihnen erlaubt, die beste Technik pro Seite auszuwählen.

Next.js 9.0 führte das Konzept der Automatischen statischen Optimierung ein. Wenn eine Seite keine blockierenden Datenabrufanforderungen wie getInitialProps hat, wird sie automatisch zur Build-Zeit in HTML gerendert.

Es gibt jedoch mehr Fälle, in denen Sie eine Seite zur Build-Zeit in statisches HTML rendern möchten, selbst mit blockierenden Datenabrufanforderungen. Ein Beispiel hierfür sind Marketingseiten, die von einem (Headless-)Content-Management-System (CMS) betrieben werden, oder der Blog-Bereich einer Website.

Wir haben mit intensiven Nutzern von SSG und next export wie HashiCorp zusammengearbeitet und ausführlich mit der Community im meistkommentierten RFC der Next.js-Geschichte die richtigen Einschränkungen diskutiert, um eine neue einheitliche Methode für Datenabruf und statische Generierung zu schaffen.

Heute freuen wir uns sehr, zwei neue Datenabrufmethoden anzukündigen: getStaticProps und getServerSideProps. Zudem bieten wir eine Möglichkeit, Parameter für die statische Generierung dynamischer Routen bereitzustellen: getStaticPaths.

Diese neuen Methoden haben viele Vorteile gegenüber dem getInitialProps-Modell, da klar zwischen SSG und SSR unterschieden wird.

  • getStaticProps (Statische Generierung): Datenabruf zur Build-Zeit.

  • getStaticPaths (Statische Generierung): Angabe dynamischer Routen für das Prerendering basierend auf Daten.

  • getServerSideProps (Server-seitiges Rendering): Datenabruf bei jeder Anfrage.

  • Diese Verbesserungen sind API-Erweiterungen. Alle neuen Funktionen sind vollständig abwärtskompatibel und können schrittweise übernommen werden. Es werden keine Verwerfungen eingeführt, und getInitialProps wird weiterhin wie bisher funktionieren. Wir empfehlen jedoch die Verwendung dieser neuen Methoden für neue Seiten und Projekte.

getStaticProps

Wenn Sie eine async-Funktion namens getStaticProps von einer Seite exportieren, wird Next.js diese Seite zur Build-Zeit vorrendern. Dies ist besonders nützlich, wenn Sie bestimmte statische Seiten aus einem CMS rendern möchten.

getStaticProps läuft immer im Node.js-Kontext, und der Code wird automatisch aus den Browser-Bundles entfernt (Tree-Shaking), wodurch weniger Code an den Browser gesendet wird. So müssen Sie sich keine Gedanken über die Ausführung des Datenabruf-Codes in beiden Umgebungen (Node.js und Browser) machen, die einige Inkonsistenzen aufweisen.

Dies ermöglicht die Verwendung jeder asynchronen oder sogar synchronen Datenabruftechnik, einschließlich fetch, REST, GraphQL oder sogar direktem Datenbankzugriff.

pages/posts/[id].js
export async function getStaticProps(context) {
  return {
    props: {}, // wird als Props an die Seitenkomponente übergeben
  };
}

Der context-Parameter ist ein Objekt mit folgenden Schlüsseln:

  • params: Enthält die Routenparameter für Seiten mit dynamischen Routen. Beispiel: Wenn der Seitenname [id].js lautet, sieht params wie { id: ... } aus. Weitere Informationen finden Sie in der Dokumentation zu dynamischem Routing. Dies sollte zusammen mit getStaticPaths verwendet werden, das wir später erklären werden.

Hier ein Beispiel, das getStaticProps verwendet, um eine Liste von Blogposts aus einem CMS abzurufen:

pages/blog.js
// Sie können jede Datenabrufbibliothek verwenden
import fetch from 'node-fetch';
 
// posts wird zur Build-Zeit durch getStaticProps() befüllt
function Blog({ posts }) {
  return (
    <ul>
      {posts.map((post) => (
        <li>{post.title}</li>
      ))}
    </ul>
  );
}
 
// Diese Funktion wird zur Build-Zeit in der Node.js-Umgebung aufgerufen.
// Sie wird nicht clientseitig aufgerufen, sodass Sie sogar
// direkte Datenbankabfragen durchführen können. Siehe Abschnitt "Technische Details".
export async function getStaticProps() {
  // Rufen Sie einen externen API-Endpunkt ab, um Posts zu erhalten.
  const res = await fetch('https://.../posts');
  const posts = await res.json();
 
  // Durch die Rückgabe von { props: posts } erhält die Blog-Komponente
  // `posts` als Prop zur Build-Zeit
  return {
    props: {
      posts,
    },
  };
}
 
export default Blog;

Wann sollte ich getStaticProps verwenden?

Sie sollten getStaticProps verwenden, wenn:

  • Die zum Rendern der Seite erforderlichen Daten zur Build-Zeit vor einer Benutzeranfrage verfügbar sind.
  • Die Daten aus einem Headless-CMS stammen.
  • Die Daten öffentlich zwischengespeichert werden können (nicht benutzerspezifisch).
  • Die Seite für SEO-Zwecke vorgerendert werden muss und sehr schnell sein soll — getStaticProps generiert HTML- und JSON-Dateien, die beide von einem CDN für bessere Performance zwischengespeichert werden können.

Weitere Informationen zu getStaticProps finden Sie in der Datenabruf-Dokumentation.

getStaticPaths

Wenn eine Seite dynamische Routen verwendet und getStaticProps nutzt, muss sie eine Liste der Pfade definieren, die zur Build-Zeit in HTML gerendert werden sollen.

Wenn Sie eine async-Funktion namens getStaticPaths von einer Seite mit dynamischen Routen exportieren, wird Next.js alle von getStaticPaths angegebenen Pfade statisch vorrendern.

pages/posts/[id].js
export async function getStaticPaths() {
  return {
    paths: [
      { params: { ... } } // Siehe Abschnitt "paths" unten
    ],
    fallback: true or false // Siehe Abschnitt "fallback" unten
  };
}

Der paths-Schlüssel (erforderlich)

Der paths-Schlüssel bestimmt, welche Pfade vorgerendert werden. Angenommen, Sie haben eine Seite mit dynamischen Routen namens pages/posts/[id].js. Wenn Sie getStaticPaths von dieser Seite exportieren und Folgendes für paths zurückgeben:

return {
  paths: [
    { params: { id: 1 } },
    { params: { id: 2 } }
  ],
  fallback: ...
}

Dann wird Next.js posts/1 und posts/2 zur Build-Zeit statisch mit der Seitenkomponente in pages/posts/[id].js generieren.

Beachten Sie, dass der Wert für jedes params mit den in der Seitenbezeichnung verwendeten Parametern übereinstimmen muss:

  • Wenn die Seitenbezeichnung pages/posts/[postId]/[commentId] lautet, sollte params postId und commentId enthalten.
  • Wenn die Seitenbezeichnung Catch-all-Routen verwendet, z.B. pages/[...slug], sollte params slug enthalten, das ein Array ist. Beispiel: Wenn dieses Array ['foo', 'bar'] ist, generiert Next.js die Seite statisch unter /foo/bar.

Der fallback-Schlüssel (erforderlich)

Das von getStaticPaths zurückgegebene Objekt muss einen booleschen fallback-Schlüssel enthalten.

Fallback: false

Wenn fallback false ist, führt jeder nicht von getStaticPaths zurückgegebene Pfad zu einer 404-Seite. Dies ist nützlich, wenn Sie wissen, dass alle Pfade zur Build-Zeit bekannt sein werden.

Hier ein Beispiel, das einen Blogpost pro Seite namens pages/posts/[id].js vorrendert. Die Liste der Blogposts wird aus einem CMS abgerufen und von getStaticPaths zurückgegeben. Dann werden für jede Seite die Post-Daten aus einem CMS mit getStaticProps abgerufen.

pages/posts/[id].js
import fetch from 'node-fetch';
 
function Post({ post }) {
  // Rendern des Posts...
}
 
// Diese Funktion wird zur Build-Zeit aufgerufen
export async function getStaticPaths() {
  // Rufen Sie einen externen API-Endpunkt ab, um Posts zu erhalten
  const res = await fetch('https://.../posts');
  const posts = await res.json();
 
  // Ermitteln Sie die Pfade, die wir basierend auf den Posts vorrendern möchten
  const paths = posts.map((post) => `/posts/${post.id}`);
 
  // Wir rendern nur diese Pfade zur Build-Zeit vor.
  // { fallback: false } bedeutet, dass andere Routen zu 404 führen sollten.
  return { paths, fallback: false };
}
 
// Diese Funktion wird ebenfalls zur Build-Zeit aufgerufen
export async function getStaticProps({ params }) {
  // params enthält die Post-`id`.
  // Wenn die Route z.B. /posts/1 ist, dann ist params.id 1
  const res = await fetch(`https://.../posts/${params.id}`);
  const post = await res.json();
 
  // Übergeben Sie die Post-Daten als Props an die Seite
  return { props: { post } };
}
 
export default Post;

Fallback: true

Wenn fallback true ist, ändert sich das Verhalten von getStaticProps. Next.js rendert die angegebenen Pfade zur Build-Zeit in HTML. Wenn ein Pfad nicht zur Build-Zeit generiert wurde, wird er bei einer Benutzeranfrage on-demand generiert.

Dies ist nützlich, wenn Ihre Anwendung viele Routen hat, die statisch generiert werden können, Sie aber nicht erhöhte Build-Zeiten für Seiten in Kauf nehmen möchten, indem Sie nur eine Teilmenge zur Build-Zeit generieren.

Der Benutzer, der die Generierung der Seite auslöst, erhält ein Fallback-HTML, in der Regel eine Seite mit einem Ladezustand. Der Grund dafür ist, dass statisches HTML von einem CDN bereitgestellt werden kann, wodurch die Seite immer schnell ist, selbst wenn sie noch nicht generiert wurde.

Ein Beispiel für die on-demand statische Generierung zusätzlicher Seiten:

pages/posts/[id].js
import { useRouter } from 'next/router';
import fetch from 'node-fetch';
 
function Post({ post }) {
  const router = useRouter();
 
  // Wenn die Seite noch nicht generiert wurde, wird dies angezeigt,
  // bis getStaticProps() fertig ist
  if (router.isFallback) {
    return <div>Laden...</div>;
  }
 
  // Rendern des Posts...
}
 
// Diese Funktion wird zur Build-Zeit aufgerufen
export async function getStaticPaths() {
  return {
    // Nur `/posts/1` und `/posts/2` werden zur Build-Zeit generiert
    paths: [{ params: { id: 1 } }, { params: { id: 2 } }],
    // Aktivieren der statischen Generierung zusätzlicher Seiten
    // Beispiel: `/posts/3`
    fallback: true,
  };
}
 
// Diese Funktion wird ebenfalls zur Build-Zeit aufgerufen
export async function getStaticProps({ params }) {
  // params enthält die Post-`id`.
  // Wenn die Route z.B. /posts/1 ist, dann ist params.id 1
  const res = await fetch(`https://.../posts/${params.id}`);
  const post = await res.json();
 
  // Übergeben Sie die Post-Daten als Props an die Seite
  return { props: { post } };
}
 
export default Post;

Weitere Informationen zu getStaticPaths finden Sie in der Datenabruf-Dokumentation.

getServerSideProps

Wenn Sie eine async-Funktion namens getServerSideProps aus einer Seite exportieren, wird Next.js diese Seite bei jeder Anfrage rendern (Server-seitiges Rendering (SSR)).

getServerSideProps läuft immer serverseitig und der Code wird automatisch aus den Browser-Bundles entfernt (Tree-Shaking), wodurch weniger Code an den Browser gesendet wird. So müssen Sie sich keine Gedanken über die Ausführung des Datenabruf-Codes in sowohl Server- als auch Browser-Umgebungen machen, die einige Inkonsistenzen aufweisen. Dies verbessert in vielen Fällen die Leistung, da der Server in der Regel eine schnellere Verbindung zur Datenquelle hat. Es erhöht auch die Sicherheit, indem weniger der Datenabruflogik offengelegt wird.

Dadurch können Sie jede asynchrone oder sogar synchrone Datenabruftechnik verwenden, einschließlich fetch, REST, GraphQL oder sogar den direkten Zugriff auf eine Datenbank.

Wenn Sie zwischen Seiten mit next/link navigieren, anstatt getServerSideProps im Browser auszuführen, führt Next.js einen Fetch zum Server durch, der das Ergebnis des Aufrufs von getServerSideProps zurückgibt.

pages/index.js
export async function getServerSideProps(context) {
  return {
    props: {}, // wird als Props an die Seitenkomponente übergeben
  };
}

Der context-Parameter ist ein Objekt mit den folgenden Schlüsseln:

Hier ist ein Beispiel, das getServerSideProps verwendet, um Daten zum Zeitpunkt der Anfrage abzurufen und sie darzustellen:

pages/index.js
function Page({ data }) {
  // Daten darstellen...
}
 
// Dies wird bei jeder Anfrage aufgerufen
export async function getServerSideProps() {
  // Daten von einer externen API abrufen
  const res = await fetch(`https://.../data`);
  const data = await res.json();
 
  // Daten über Props an die Seite übergeben
  return { props: { data } };
}
 
export default Page;

Weitere Informationen zu getServerSideProps finden Sie in der Dokumentation zum Datenabruf.

Vorschaumodus (Preview Mode)

Wie bereits früher in diesem Beitrag erwähnt, ist statische Generierung (Static Generation) nützlich, wenn Ihre Seiten Daten von einem Headless-CMS abrufen. Sie ist jedoch nicht ideal, wenn Sie einen Entwurf in Ihrem Headless-CMS schreiben und diesen sofort auf Ihrer Seite vorschauen möchten. Da die Ausgabe statisch ist, wird die Vorschau von Änderungen schwieriger, da Sie die statische Seite neu generieren müssten.

Die Einführung von getStaticProps in Next.js eröffnet neue Möglichkeiten, wie die Nutzung der On-Demand-Rendering-Fähigkeiten von Next.js unter bestimmten Bedingungen.

Wenn Sie beispielsweise einen Entwurf aus Ihrem Headless-CMS vorschauen möchten, sollten Sie das statische Rendering umgehen und die Seite stattdessen mit dem Entwurfsinhalt anstelle des veröffentlichten Inhalts on-demand rendern. Sie möchten, dass Next.js die statische Generierung nur für diesen speziellen Fall umgeht.

Wir freuen uns, eine neue integrierte Funktion von Next.js vorzustellen, die diesen Bedarf abdeckt: den Vorschaumodus (Preview Mode).

Der Vorschaumodus ermöglicht es Benutzern, die statisch generierte Seite zu umgehen und eine Entwurfsseite on-demand (SSR) von beispielsweise einem CMS zu rendern.

Sie sind jedoch nicht nur auf bestimmte CMS-Systeme beschränkt. Der Vorschaumodus integriert sich direkt mit sowohl getStaticProps als auch getServerSideProps, sodass er mit jeder Art von Datenabruflösung verwendet werden kann.

Der Vorschaumodus ist bereits verfügbar, wenn Sie next start verwenden oder nahtlos durch Bereitstellung im Vercel Edge Network.

Probieren Sie den Vorschaumodus selbst auf https://next-preview.vercel.app/ aus.

Erfahren Sie mehr über den Vorschaumodus, indem Sie die Dokumentation konsultieren.

Zusammenarbeit mit CMS-Anbietern

getStaticProps ermöglicht es Ihnen, Daten aus beliebigen Datenquellen abzurufen, einschließlich CMS-Systemen.

Wir arbeiten aktiv mit vielen wichtigen Akteuren im CMS-Ökosystem zusammen, um Beispiele und Anleitungen für die Integration mit Next.js bereitzustellen.

Beispiele, an denen derzeit aktiv gearbeitet wird, umfassen:

Wenn Ihr Unternehmen im CMS-Ökosystem aktiv ist, würden wir uns freuen, mit Ihnen zusammenzuarbeiten! Zögern Sie nicht, unser Team per E-Mail oder Twitter zu kontaktieren.

Integrierte Sass-Unterstützung für globale Stylesheets

Next.js 9.2 führte die integrierte Unterstützung für globale CSS-Stylesheets ein, um das Plugin next-css mit besseren Standardeinstellungen zu ersetzen und ein optimierteres Ergebnis zu liefern.

Kurz nach der Veröffentlichung wurden wir zunehmend gebeten, die Sass-Unterstützung zu integrieren, da viele Unternehmen, die zu Next.js wechseln, ein bestehendes Design-System auf Basis von Sass haben.

Bei der Untersuchung der Next.js-Plugin-Nutzung stellten wir fest, dass etwa 30 % der Next.js-Anwendungen heute next-sass verwenden. Im Vergleich dazu nutzen 44 % Vanilla CSS und 6 % Less.

Darüber hinaus hatte next-sass die gleichen fehlenden Einschränkungen wie next-css. Das bedeutet, dass Sie eine Sass-Datei in jeder Datei des Projekts importieren konnten, diese importierte Sass-Datei jedoch global für die gesamte Anwendung galt.

Nach Berücksichtigung dieser Statistiken und des Feedbacks freuen wir uns, bekannt zu geben, dass Next.js jetzt eine integrierte Unterstützung für den Import von Sass-Stylesheets bietet.

Um mit globalen Sass-Imports in Ihrer Anwendung zu beginnen, installieren Sie sass:

Terminal
npm install sass

Importieren Sie dann die Sass-Datei in pages/_app.js.

Beispielsweise betrachten Sie das folgende Stylesheet mit dem Namen styles.scss im Stammverzeichnis Ihres Projekts:

$primary-color: #333;
 
body {
  padding: 20px 20px 60px;
  margin: 0;
  color: $primary-color;
}

Erstellen Sie eine pages/_app.js-Datei, falls noch nicht vorhanden. Importieren Sie dann die Datei styles.scss:

pages/_app.js
import '../styles.scss';
 
// Dieser Standardexport ist in einer neuen `pages/_app.js`-Datei erforderlich.
export default function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />;
}

Da Stylesheets globaler Natur sind, müssen sie in der benutzerdefinierten <App>-Komponente importiert werden. Dies ist notwendig, um Konflikte bei Klassennamen und der Reihenfolge für globale Styles zu vermeiden.

In der Entwicklung ermöglicht diese Art der Stylesheet-Definition, dass Ihre Styles automatisch auf der Seite aktualisiert werden, während Sie sie bearbeiten.

In der Produktion werden alle Sass- und CSS-Dateien automatisch in eine einzige minimierte .css-Datei zusammengeführt. Diese CSS-Datei wird über ein <link>-Tag geladen und automatisch in das standardmäßige HTML-Markup eingefügt, das Next.js generiert.

Diese neue Funktion ist vollständig abwärtskompatibel. Wenn Sie @zeit/next-sass oder andere CSS-bezogene Plugins verwenden, ist die Funktion deaktiviert, um Konflikte zu vermeiden.

Wenn Sie derzeit @zeit/next-sass verwenden, empfehlen wir, das Plugin aus Ihrer next.config.js und package.json zu entfernen und nach dem Upgrade auf die integrierte Sass-Unterstützung umzusteigen.

Integrierte Sass-CSS-Modul-Unterstützung für komponentenspezifische Styles

Next.js unterstützt jetzt CSS-Module mit Sass-Dateien unter Verwendung der Namenskonvention [name].module.scss.

Im Gegensatz zur zuvor in Next.js 5+ mit next-sass verfügbaren Unterstützung können globale Sass- und CSS-Module jetzt koexistieren – next-sass erforderte, dass alle .scss-Dateien in Ihrer Anwendung entweder global oder lokal behandelt werden, aber nicht beides.

CSS-Module begrenzen Sass lokal, indem sie automatisch eindeutige Klassennamen erstellen. Dies ermöglicht es Ihnen, denselben Sass-Klassennamen in verschiedenen Dateien zu verwenden, ohne sich über Kollisionen Gedanken machen zu müssen.

Dieses Verhalten macht CSS-Module zur idealen Möglichkeit, komponentenspezifisches Sass einzubinden. CSS-Modul-Dateien können überall in Ihrer Anwendung importiert werden.

Um mit Sass-CSS-Modulen in Ihrer Anwendung zu beginnen, stellen Sie sicher, dass Sie sass installiert haben:

Terminal
npm install sass

Betrachten Sie nun eine wiederverwendbare Button-Komponente im Ordner components/:

Erstellen Sie zunächst components/Button.module.scss mit folgendem Inhalt:

/*
Sie müssen sich keine Sorgen machen, dass .error {} mit anderen `.css`- oder
`.module.css`-Dateien kollidiert!
*/
$color: white;
 
.error {
  color: $color;
  background-color: red;
}

Erstellen Sie dann components/Button.js, importieren Sie die obige CSS-Datei und verwenden Sie sie:

components/Button.js
import styles from './Button.module.scss';
 
export function Button() {
  return (
    <button
      type="button"
      // Beachten Sie, wie die "error"-Klasse als Eigenschaft des importierten
      // `styles`-Objekts aufgerufen wird.
      className={styles.error}
    >
      Destroy
    </button>
  );
}

CSS-Module für Sass-Dateien sind eine optionale Funktion und werden nur für Dateien mit der Erweiterung .module.scss aktiviert. Reguläre <link>-Stylesheets und globale Sass-Styles werden weiterhin unterstützt.

In der Produktion werden alle CSS-Modul-Dateien automatisch in viele minimierte und code-aufgeteilte .css-Dateien zusammengeführt. Diese .css-Dateien repräsentieren Hot-Execution-Pfade in Ihrer Anwendung und stellen sicher, dass die minimale Menge an CSS pro Seite geladen wird, damit Ihre Anwendung gerendert werden kann.

Wie oben ist diese neue Funktion vollständig abwärtskompatibel. Wenn Sie @zeit/next-sass oder andere CSS-bezogene Plugins verwenden, ist die Funktion deaktiviert, um Konflikte zu vermeiden.

Wenn Sie derzeit @zeit/next-sass verwenden, empfehlen wir, das Plugin aus Ihrer next.config.js und package.json zu entfernen und auf die integrierte Sass-Unterstützung umzusteigen.

Automatische statische Optimierung für 404

Die Veröffentlichung von Next.js 9 führte das Konzept der automatischen statischen Optimierung (Automatic Static Optimization) ein: Wenn eine Seite keine blockierenden Datenanforderungen hat, generiert Next.js die Seite automatisch als statisches HTML zur Build-Zeit. Allerdings gab es eine Seite, die nicht automatisch als statisches HTML gerendert wurde: die 404-Seite. Der Hauptgrund, warum die 404-Seite nicht automatisch statisch gemacht wurde, war, dass die /_error-Seite, die 404 bedient, mehr als nur 404 handhabte, zum Beispiel Fehler.

Da 404-Seiten für nicht existierende Routen gerendert werden, könnte das On-Demand-Rendering der Seite zu höheren Kosten und Serverlast führen.

Wir haben uns zum Ziel gesetzt, Sie in zwei Punkten zu unterstützen:

  • Die standardmäßige Next.js-Erfahrung generiert eine statische 404-Seite
  • Bei der Anpassung der 404-Seite wird weiterhin sichergestellt, dass Sie eine statische Seite erhalten

Diese Funktion ist vollständig abwärtskompatibel. Wenn Sie derzeit eine benutzerdefinierte pages/_error.js haben, wird diese weiterhin für die 404-Seite verwendet, bis Sie pages/404.js hinzufügen.

Statische 404-Seite standardmäßig

Wenn Ihre Anwendung keine benutzerdefinierte pages/_error.js-Seite hat, generiert Next.js automatisch eine statische 404-Seite und verwendet diese, wenn eine 404-Seite bereitgestellt werden muss. Dies geschieht automatisch und erfordert keine Änderungen.

Benutzerdefinierte 404-Seite mit pages/404.js

Um die standardmäßige 404-Seite zu überschreiben, können Sie jetzt eine pages/404.js erstellen, die weiterhin automatisch zur Build-Zeit statisch optimiert wird. Diese Seite wird anstelle von pages/_error.js verwendet, um eine 404-Seite darzustellen, falls Ihre Anwendung eine solche hat.

pages/404.js
export default () => <h1>Dies ist die 404-Seite</h1>;

32+ kB kleinere Laufzeit (15 kB+ Gzip)

Next.js unterstützt die gleichen Browser wie React selbst, ohne erforderliche Konfiguration. Dazu gehören Internet Explorer 11 (IE11) und alle gängigen Browser (Edge, Firefox, Chrome, Safari, Opera usw.).

Als Teil dieser Kompatibilität kompilieren wir Ihre Anwendung auch so, dass sie IE11-kompatibel ist: Dies ermöglicht es Ihnen, sicher ES6+-Syntax-Funktionen, Async/Await, Object Rest/Spread Properties und mehr zu verwenden – alles ohne erforderliche Konfiguration.

Ein Teil dieses Kompilierungsprozesses beinhaltet auch das transparente Einfügen der notwendigen Feature-Polyfills (z. B. Array.from oder Symbol). Diese Polyfills sind jedoch nur für weniger als 10 % des Webverkehrs notwendig, in den meisten Fällen zur Unterstützung von IE11.

Ab Next.js 9.3 lädt Next.js automatisch die Polyfills, die zur Unterstützung von Legacy-Browsern benötigt werden, und lädt diese Polyfills nur in diesen Legacy-Browsern.

In der Praxis bedeutet dies, dass 32 kB oder mehr von Ihrer First Load-Größe für 90 %+ Ihrer Benutzer eliminiert werden.

Diese Größeneinsparungen sind sogar noch größer für größere Anwendungen, die auf noch mehr Browser-Features angewiesen sind.

Diese Optimierung erfolgt vollautomatisch und erfordert keine Änderungen an Ihrer Anwendung, um davon zu profitieren!

Community

Wir freuen uns sehr über das weiterhin wachsende Interesse an Next.js:

  • Wir hatten über 927 unabhängige Mitwirkende.
  • Auf GitHub wurde das Projekt über 46.600 Mal mit einem Stern versehen.
  • Das Beispielverzeichnis enthält über 226 Beispiele.

Die Next.js-Community hat jetzt über 15.250 Mitglieder. Die Community findet sich jetzt auf GitHub-Diskussionen, einem neuen Ort für die Community, um zu diskutieren und Fragen zu stellen! Machen Sie mit!

Wir sind unserer Community und all dem externen Feedback und den Beiträgen dankbar, die diese Veröffentlichung mitgestaltet haben.

Besonderer Dank geht an Jeff Escalante für wertvolles Feedback zu den neuen Datenabrufmethoden.

Ein riesiges Dankeschön an alle, die zu dieser Veröffentlichung beigetragen haben: @arcanis, @lgordey, @ijjk, @martpie, @jaywink, @fabianishere, @dijs, @TheRusskiy, @quinnturner, @timneutkens, @lfades, @vvo, @adithwip, @rafaelalmeidatk, @bmathews, @Spy-Seth, @EvgeniyKumachev, @chibicode, @piglovesyou, @HaNdTriX, @Timer, @janicklas-ralph, @devknoll, @prateekbh, @ethanryan, @MoOx, @rifaidev, @msweeneydev, @motiko und @balazsorban44 für die Hilfe!