Wir betreiben mehrere SaaS-Produkte und diese Website auf dem Next.js App Router. innopulse.io selbst erzeugt beim Build über 1500 Seiten statisch, zweisprachig, mit strukturierten Daten und automatisierter Prüfung. Dieser Beitrag fasst zusammen, welche Muster sich mit Next.js 15 im Betrieb bewährt haben und wo Teams typischerweise Zeit und Sicherheit verlieren.
Server Components als Standard
Im App Router sind Komponenten standardmässig Server Components: Sie laufen auf dem Server, greifen direkt auf Daten zu und schicken kein JavaScript an den Browser. Client Components braucht man nur dort, wo Interaktion stattfindet — Formulare mit Zustand, Menüs, Diagramme. Die wichtigste Regel ist, die Grenze bewusst zu ziehen: Ein „use client“ weit oben im Baum macht alles darunter zum Client-Code und verschenkt den Vorteil. Bewährt hat sich, Seiten als Server Components zu bauen und kleine interaktive Inseln einzusetzen.
Server Actions sind öffentliche Endpunkte
Server Actions fühlen sich an wie Funktionsaufrufe, sind technisch aber HTTP-Endpunkte, die jeder aufrufen kann, der ihre Kennung kennt. Daraus folgen dieselben Pflichten wie bei jeder API: Eingaben validieren, etwa mit einem Schema, Authentifizierung und Berechtigung bei jedem Aufruf prüfen, Mandantengrenzen serverseitig durchsetzen und Fehler kontrolliert zurückgeben. Eine Server Action, die nur prüft, ob ein Button im Frontend sichtbar war, ist eine Sicherheitslücke.
Caching nach den neuen Defaults
Next.js 15 hat die Caching-Defaults umgedreht: fetch-Anfragen, GET-Route-Handler und der clientseitige Router-Cache für Seiten werden nicht mehr standardmässig zwischengespeichert. Das hat viele Überraschungen früherer Versionen beseitigt, in denen Daten unerwartet veraltet waren. Im Gegenzug muss man Caching jetzt bewusst einschalten, wo es sinnvoll ist: statische Inhalte über statische Generierung, teure Abfragen über gezielte Revalidierung. Neuere Versionen gehen in dieselbe Richtung expliziter Steuerung; wer heute bewusst cacht, ist dafür gut vorbereitet.
Asynchrone Request-APIs
In Next.js 15 sind cookies(), headers(), params und searchParams asynchron. Das ist bei der Migration lästig, aber konsequent: Es macht sichtbar, welche Teile einer Seite von der Anfrage abhängen und deshalb dynamisch gerendert werden müssen. Wer eine Seite statisch halten will, sollte diese APIs dort nicht verwenden und dynamische Teile isolieren.
Supabase-Authentifizierung richtig einbinden
Mit Supabase läuft die Sitzung über Cookies. Ein Server-Client liest sie in Server Components, Server Actions und Route Handlern, und die Middleware erneuert die Sitzung bei jeder Anfrage. Für Berechtigungsentscheidungen auf dem Server sollte man den Nutzer gegen den Auth-Dienst prüfen, statt einer lokal gelesenen Sitzung blind zu vertrauen. Die eigentliche Absicherung liegt aber in der Datenbank: Mit Row Level Security hält die Mandantentrennung auch dann, wenn im Anwendungscode eine Prüfung fehlt. Mehr dazu im Supabase-Playbook zur Datenresidenz.
Statische Generierung im grossen Massstab
Für Inhalte, die sich nicht pro Anfrage ändern, ist statische Generierung mit generateStaticParams die robusteste Wahl: schnell, günstig, gut für Suchmaschinen. Wir erzeugen so Glossar, Ratgeber, Vergleiche und Regionenseiten in zwei Sprachen. Zwei Dinge sind dabei wichtig. Erstens ehrliches hreflang: Eine Seite, die es nur auf Deutsch gibt, liefert auf Englisch einen echten 404 statt einer falschen Alternative. Zweitens eine automatisierte Prüfung nach dem Build, die kontrolliert, dass jede Sitemap-URL existiert, eine korrekte Canonical hat und intern verlinkt ist. Ohne diese Prüfung wachsen Fehler unbemerkt mit der Seitenzahl. Den inhaltlichen Teil beschreibt der Beitrag zur Topical Authority.
Hosting-Region und Datenresidenz
Bei Vercel laufen Serverfunktionen ohne Konfiguration in einer US-Region. Wer Personendaten aus der EU oder der Schweiz verarbeitet, sollte die Funktionsregion bewusst in die Nähe der Datenbank legen, etwa nach Frankfurt. Das senkt zugleich die Latenz, weil jede Datenbankabfrage sonst den Atlantik zweimal überquert. Die Grundsatzfrage zum Standort beschreibt die Entscheidungshilfe Schweizer Hosting oder EU-Hosting.
Updates sind Betrieb, nicht Option
Framework-Updates gehören zum Betrieb. Ende 2025 mussten wegen einer kritischen Sicherheitslücke in React Server Components zahlreiche Next.js-Projekte kurzfristig aktualisiert werden. Wer seine Abhängigkeiten regelmässig pflegt, macht solche Updates in Minuten; wer Versionen über Monate einfriert, steht dann vor einer Migration unter Zeitdruck. Automatische Hinweise auf Sicherheitsupdates und eine Pipeline mit Tests machen den Unterschied, siehe CI/CD.
Die häufigsten Fehler
- Client Components zu weit oben im Baum, wodurch unnötig viel JavaScript ausgeliefert wird.
- Server Actions ohne Validierung und ohne Berechtigungsprüfung.
- Caching nach Gefühl statt nach bewusster Entscheidung pro Datenquelle.
- Service-Schlüssel der Datenbank in Code, der im Browser landet.
- Serverfunktionen in einer anderen Region als die Datenbank.
- Keine automatisierte Prüfung nach dem Build bei grossen statischen Seitenmengen.
Einordnung
Der App Router ist reif für den Produktivbetrieb, verlangt aber ein klares mentales Modell: Server zuerst, Client nur wo nötig, jede Server Action wie eine API behandeln, Caching bewusst, Daten in der richtigen Region. Diese Muster setzen wir in eigenen Produkten und für Kunden um, etwa im Angebot Next.js-Webapp zum Festpreis oder in der Multi-Tenant-SaaS-Architektur.