Der App Router ist seit Next.js 13.4 stabil und inzwischen der Standard-Ausgangspunkt für neue Projekte. Nach zehn damit ausgelieferten Kundenprojekten, von einfachen Marketing-Websites bis zu mehrsprachigen SaaS-Dashboards, haben wir ein klares Bild davon, wo er überzeugt und wo er Probleme verursacht, die es mit dem Pages Router nicht gab.
Das ist kein Tutorial. Es ist ein ehrlicher Bericht über die Entscheidungen, Fehler und Erkenntnisse aus dem Produktionseinsatz.
Das Caching-Modell des App Routers ist das Wichtigste, was Sie verstehen sollten, bevor Sie eine Zeile Code schreiben. Es ist zugleich die Quelle der verwirrendsten Bugs, die wir in Produktion gesehen haben.
Es gibt vier Caching-Ebenen:
fetch-Aufrufe innerhalb eines einzelnen Render-Baumsfetch-Antworten über Requests hinweg (auf dem Server)Das Problem ist nicht, dass es diese Caches gibt. Das Problem ist, dass sie auf eine Weise zusammenwirken, die nicht offensichtlich ist, bis Sie einen Bug debuggen, bei dem ein Nutzer nach einer gerade ausgeführten Aktion veraltete Daten sieht.
Was wir gelernt haben:
tags und nutzen Sie nach Mutationen revalidateTag; das ist für die meisten dynamischen Inhalte das richtige Mustercache: 'no-store' eignet sich für wirklich dynamische Daten (personalisierte Inhalte, Echtzeitdaten), nicht als Pauschallösung für Caching-Verwirrungunstable_cache ist stabil genug für die Produktion; meiden Sie es nicht wegen des NamensStandard im App Router sind Server Components. Alles ist eine Server Component, solange Sie nicht 'use client' hinzufügen.
Der Fehler, den wir anfangs gemacht haben: Wir haben die Grenze zwischen Server und Client als architektonische Vorliebe behandelt statt als Grenze der Fähigkeiten.
Komponenten sollten Server Components sein, wenn:
Komponenten sollten Client Components sein, wenn:
useState, useEffect, useContext)window, localStorage, IntersectionObserver)Die praktische Regel: Verschieben Sie die 'use client'-Grenze so tief wie möglich. Eine Seite, die zu 80 % aus statischen Inhalten und einem interaktiven Button besteht, sollte eine Server Component mit einer einzigen 'use client'-Button-Komponente sein, keine Client-Component-Seite.
Zwei Performance-Verbesserungen zeigten sich durchgängig über alle Projekte:
Streaming. Der App Router unterstützt das Streaming von HTML über die Suspense-Grenzen von React. Bei Seiten mit langsamen Datenabhängigkeiten sorgt ein Suspense-Wrapper dafür, dass der Browser sofort das Seitengerüst erhält und die Inhalte nachgestreamt werden, sobald sie bereitstehen. Bei einem Kundenprojekt sank dadurch die Zeit bis zum ersten aussagekräftigen Rendern einer datenintensiven Analytics-Seite auf Mobilgeräten von 2,8 s auf 0,9 s.
Paralleles Laden von Daten. Im Pages Router lädt getServerSideProps Daten standardmäßig nacheinander. Im App Router laden Server Components auf verschiedenen Ebenen des Baums ihre Daten gleichzeitig. Ein Layout, das Nutzerdaten lädt, und eine Seite, die Inhaltsdaten lädt, laufen parallel; die Antwort ist fertig, sobald die langsamste Abfrage abgeschlossen ist.
Was wir nicht bekommen haben: Deutliche LCP-Verbesserungen bei vollständig statischen Marketing-Websites. Die statische Generierung des Pages Routers ist bereits exzellent; der App Router macht eine ohnehin schnelle Website nicht nennenswert schneller.
Der App Router wurde mit Blick auf Vercel entwickelt. Manche Features funktionieren auf Vercel deutlich besser als auf anderen Plattformen.
Edge Runtime: läuft auf Vercel überall mit automatischer globaler Verteilung. Beim Self-Hosting müssen Edge-Knoten manuell eingerichtet werden.
Bildoptimierung: Das next/image-CDN von Vercel ist schnell und automatisch. Beim Self-Hosting braucht es ein konfiguriertes Bild-CDN, sonst funktioniert die Vercel-spezifische Optimierung nicht.
ISR (Incremental Static Regeneration): funktioniert auf Vercel mit verteilter Cache-Invalidierung. Beim Self-Hosting muss die On-Demand-Revalidation-API korrekt eingerichtet werden, und Ihre Hosting-Umgebung muss sie unterstützen.
Was überall problemlos funktioniert: Standardmäßiges serverseitiges Rendering, statische Generierung, Server Components (ohne Edge Runtime), alle Standard-API-Routen.
Für die meisten Kundenprojekte ist Vercel die richtige Wahl. Die Developer Experience ist exzellent, die Deployment-Pipeline ist nativ mit GitHub integriert, und die Kosten für Marketing-Websites sind planbar (der Pro-Tarif für 20 € pro Monat reicht für die meisten Anwendungsfälle). Wir hosten nur dann selbst, wenn ein Kunde Anforderungen an den Datenstandort hat (nur EU), bestehende Infrastruktur nutzen möchte oder eine Kostenstruktur hat, bei der die Preise von Vercel im großen Maßstab nicht aufgehen.
Wir sind dem App Router nicht ideologisch verpflichtet. Es gibt Fälle, in denen der Pages Router die bessere Wahl ist:
Bestandsprojekte. Eine große Pages-Router-Codebasis auf den App Router zu migrieren, ist ein erheblicher technischer Aufwand mit begrenztem geschäftlichem Nutzen bei stabilen Websites. Solange das Projekt kein bestimmtes App-Router-Feature braucht, migrieren wir nicht.
Teams ohne App-Router-Erfahrung. Der App Router hat eine steilere Lernkurve als der Pages Router. Bei Projekten, deren Weiterentwicklung der Kunde nach dem Launch übernimmt, senkt der Pages Router das Übergaberisiko.
Kompatibilität mit Drittanbieter-Bibliotheken. Die meisten großen Bibliotheken unterstützen den App Router inzwischen, aber nicht alle. Prüfen Sie das immer, bevor Sie ein App-Router-Projekt mit einer ungewöhnlichen Bibliotheksanforderung beginnen.
Einfache Websites ohne Caching-Anforderungen. Eine statische Website mit fünf Seiten profitiert kaum von der Komplexität des App Routers. Wir nutzen ihn trotzdem (er ist der Standard), behandeln ihn aber als unkomplizierte statische Seitengenerierung, nicht als verteilte Caching-Architektur.
Nach zehn Projekten sind das unsere App-Router-Konventionen:
Das Laden von Daten erfolgt in Server Components oder Route Handlern, niemals in Client Components, es sei denn, es handelt sich um rein clientseitige Daten (Formularzustand, Browser-APIs).
Jeder fetch hat eine explizite Cache-Richtlinie: entweder cache: 'no-store' für dynamische Daten oder einen Revalidierungszeitraum und einen Tag für die Invalidierung.
'use client'-Dateien exportieren nur interaktive Komponenten; sie binden Server Components über Komposition ein, niemals umgekehrt.
Layouts laden gemeinsame Daten einmal: Nutzersession, Navigationsdaten und globale Konfiguration werden im Root-Layout geladen und weitergereicht, nicht auf jeder Seite neu abgefragt.
Fehler- und Lade-UI sind immer definiert: error.tsx und loading.tsx auf jeder Ebene der Routensegmente. Nutzer sehen nie einen unbehandelten Fehler oder einen leeren Bildschirm bei langsamer Verbindung.
Der App Router ist eine echte Verbesserung gegenüber dem Pages Router für Anwendungen, die von seiner Architektur profitieren: Streaming, paralleles Laden von Daten, feingranulares Caching und gemeinsame Layouts über Routen hinweg.
Für statische Marketing-Websites ist die Verbesserung minimal. Der Pages Router funktioniert gut und ist einfacher. Der App Router bringt Komplexität mit, die sich nur auszahlt, wenn Sie brauchen, was er bietet.
Entscheiden Sie danach, was Sie bauen, nicht danach, was neu ist.
Sie bauen mit Next.js und kämpfen mit der Komplexität des App Routers? Starten Sie ein Gespräch – wir haben die meisten Fehlerszenarien schon durchlebt und helfen Ihnen, sie zu meistern.
Wir nehmen jeden Quartal eine begrenzte Anzahl von Projekten an. Erzählen Sie uns, was Sie bauen.
Seit 28. Juni 2025 gilt das BFSG. Wer betroffen ist, wer nicht, was droht und wie Sie Ihre Website barrierefrei machen: mit Selbsttest und Checkliste.
Eine App zu bauen kostet 2026 zwischen 15.000 € und 350.000 €+. Die Aufschlüsselung nach Komplexität, die echten Kostentreiber und laufenden Kosten.
