Was ist Next.js?

Warum Next.js?

Reines React rendert im Browser — schlecht für Suchmaschinen und langsamer beim ersten Laden. Next.js kann Seiten auf dem Server vorrendern (SSR) oder zur Build-Zeit statisch erzeugen (SSG). Das Ergebnis: schnelle Ladezeiten und Inhalte, die Google direkt sieht.

Der App Router

• Dateibasiertes Routing: Ordner in app/ werden zu URLs
• Server Components als Standard — weniger JavaScript im Browser
• Client Components nur dort, wo Interaktivität nötig ist
• Eingebaute Metadata-API für SEO pro Seite

export const metadata = {
  title: "Über uns",
  description: "Wer hinter der Rusko Group steht.",
};

export default function Page() {
  return <h1>Über uns</h1>;
}

Drei Wege, eine Seite auszuliefern

Der große Vorteil von Next.js ist die Freiheit, pro Seite die passende Rendering-Strategie zu wählen. Statische Erzeugung (SSG) baut eine Seite schon beim Deployment fertig — ideal für Inhalte, die sich selten ändern, wie diese Wissensbibliothek. Server-Rendering (SSR) erzeugt die Seite pro Anfrage, etwa wenn Inhalte nutzerabhängig sind. Und mit inkrementeller Regeneration (ISR) lassen sich statische Seiten im Hintergrund aktualisieren. So bekommt jede Seite genau die Balance aus Geschwindigkeit und Aktualität, die sie braucht.

Daten direkt auf dem Server laden

Im App Router sind Komponenten standardmäßig Server Components. Sie dürfen Daten direkt dort holen, wo sie gerendert werden — etwa aus einer Datenbank oder einer API — noch bevor die Seite den Browser erreicht. Das spart eine zusätzliche Runde übers Netz, hält sensible Zugangsdaten auf dem Server und sorgt dafür, dass der Nutzer sofort fertige Inhalte sieht. Erst dort, wo echte Interaktivität nötig ist, kennzeichnet man eine Komponente gezielt als Client Component.

Eingebaute Performance-Optimierung

Next.js bringt viele Optimierungen von Haus aus mit. Die Komponente next/image liefert Bilder automatisch in modernen Formaten, in passender Größe und erst beim Scrollen. Über next/font werden Schriften ohne störendes Nachladen eingebunden. Code wird pro Route aufgeteilt, sodass der Browser nur lädt, was die aktuelle Seite wirklich braucht. Zusammen mit dem Server-Rendering ergibt das genau die schnellen Ladezeiten, die Google über die Core Web Vitals belohnt.

Next.js hat auch eine Backend-Seite

Weil ein Teil des Codes ohnehin auf dem Server läuft, braucht nicht jedes Projekt einen zweiten, getrennten Dienst. Route Handler stellen eigene HTTP-Endpunkte direkt im Projekt bereit — praktisch für Webhooks, Formularempfang oder eine kleine API für Dritte. Für das Absenden eigener Formulare gibt es zusätzlich Server Actions: Funktionen, die man in einer Komponente definiert, die aber garantiert auf dem Server ausgeführt werden. Beides hält Zugangsdaten und Datenbankzugriffe dort, wo sie hingehören, und erspart eine separate Backend-Anwendung, solange die Logik überschaubar bleibt.

Caching und Revalidierung verstehen

Damit Seiten schnell bleiben, hält Next.js gerenderte Ergebnisse und geladene Daten zwischen. Genau hier entsteht die häufigste Verwirrung im Alltag: Man ändert einen Inhalt, doch die Seite zeigt weiter den alten Stand. Die Lösung liegt in der Revalidierung. Zeitbasiert legt man fest, nach wie vielen Sekunden ein Inhalt als veraltet gilt und im Hintergrund neu erzeugt wird. Ereignisbasiert stößt man die Auffrischung gezielt an, sobald sich etwas ändert — etwa nachdem im Redaktionssystem ein Artikel gespeichert wurde. Wer bewusst entscheidet, welche Seite wie lange gültig ist, bekommt Tempo und Aktualität zugleich.