Der App Router ist seit Next.js 13.4 stabil und ist jetzt der Standard-Startpunkt für neue Projekte. Nach zehn Kundenprojekten damit — von einfachen Marketing-Sites bis zu mehrsprachigen SaaS-Dashboards — haben wir ein klares Bild davon, wo er liefert und wo er Probleme schafft.
Das Caching-Modell des App Routers ist das Wichtigste, das man verstehen muss, bevor man eine Zeile Code schreibt. Es ist auch die Quelle der verwirrendsten Bugs in der Produktion.
Es gibt vier Caching-Schichten:
fetch-Aufrufe innerhalb eines einzelnen Render-Baumsfetch-Antworten zwischen AnfragenWas wir gelernt haben:
tags und verwenden Sie revalidateTag nach Mutationencache: 'no-store' ist für genuinlich dynamische Daten geeignet, nicht als Blanket-Lösungunstable_cache ist stabil genug für die Produktion trotz des NamensKomponenten sollten Server-Komponenten sein wenn:
Komponenten sollten Client-Komponenten sein wenn:
useState, useEffect, useContext)window, localStorage)Die praktische Regel: Drücken Sie die 'use client'-Grenze so tief wie möglich.
Streaming. Der App Router unterstützt HTML-Streaming durch Reacts Suspense-Grenzen. Auf einem Kundenprojekt reduzierte das die Time-to-First-Meaningful-Paint von 2,8s auf 0,9s auf Mobile.
Paralleles Datenfetching. Server-Komponenten auf verschiedenen Ebenen des Baums fetchen Daten gleichzeitig. Ein Layout, das Benutzerdaten fetcht, und eine Seite, die Inhalte fetcht, laufen parallel.
Was besser auf Vercel funktioniert: Edge Runtime, Bildoptimierung, ISR mit verteilter Cache-Invalidierung.
Was überall gut funktioniert: Standard-SSR, statische Generierung, Server-Komponenten (ohne Edge Runtime), alle Standard-API-Routen.
Für die meisten Kundenprojekte ist Vercel die richtige Wahl. Wir hosten selbst nur, wenn ein Kunde Anforderungen an den Datensitz (EU-only) hat oder Vercel-Preise bei Skalierung nicht funktionieren.
Legacy-Projekte. Das Migrieren einer großen Pages-Router-Codebase zum App Router ist erheblicher Engineering-Aufwand.
Teams, die mit dem App Router nicht vertraut sind. Für Projekte, bei denen der Kunde die Entwicklung nach dem Launch übernimmt.
Drittanbieter-Bibliotheks-Kompatibilität. Die meisten größeren Bibliotheken unterstützen jetzt den App Router, aber einige nicht.
Einfache Sites ohne Caching-Anforderungen. Eine fünfseitige statische Site profitiert minimal von der App-Router-Komplexität.
Datenfetching lebt in Server-Komponenten oder Route-Handlers — nie in Client-Komponenten außer für nur clientseitige Daten.
Jeder fetch hat eine explizite Cache-Richtlinie.
'use client'-Dateien exportieren nur interaktive Komponenten.
Layouts fetchen gemeinsame Daten einmal — Benutzersitzung, Navigationsdaten und globale Konfiguration werden im Root-Layout gefetcht.
Error- und Loading-UI sind immer definiert — error.tsx und loading.tsx auf jeder Route-Segment-Ebene.
Der App Router ist eine genuinliche Verbesserung für Anwendungen, die von seiner Architektur profitieren: Streaming, paralleles Datenfetching, granulares Caching.
Für statische Marketing-Sites ist die Verbesserung minimal. Der Pages Router funktioniert gut und ist einfacher. Entscheiden Sie auf Basis von dem, was Sie bauen, nicht was neu ist.
Bauen Sie in Next.js und stoßen auf App-Router-Komplexität? Starten Sie ein Gespräch — wir haben die meisten Fehlermodi durchgemacht.
Wir nehmen jeden Quartal eine begrenzte Anzahl von Projekten an. Erzählen Sie uns, was Sie bauen.
React Native und Flutter sind beide ausgereift. Die Wahl hängt nicht davon ab, welches besser ist — sondern von Ihrem Team, Ihrem Zeitplan und was Sie bauen. So entscheiden Sie.
Webflow sieht beim Launch günstig aus. Individueller Code sieht teuer aus. Drei Jahre später kehrt sich die Rechnung um. Hier ist, was Agenturen Ihnen nicht sagen, bevor Sie unterschreiben.