Why We Choose Next.js App Router for Production Projects
Server Components, streaming, and ISR change how we think about performance. Here is how we use the App Router on real client work.
The App Router shipped in Next.js 13 and became stable in 14. After building more than a dozen projects on it, we have a clear picture of when it shines and when it complicates things.
Server Components by default
Every component in the App Router is a React Server Component unless you add 'use client'. This means database queries, API calls, and heavy computation stay on the server — zero JavaScript sent to the browser for those parts.
For a content-heavy marketing site, this is the right default. The HTML arrives fully rendered, LCP is fast, and search engines index the real content.
ISR with per-page revalidation
We set export const revalidate = 3600 on pages that pull from the API. The page is cached as static HTML after the first request, then regenerated in the background every hour. Users always get a fast cached response; fresh content appears automatically.
Streaming for long-running fetches
When a page needs data from multiple slow endpoints, we use React Suspense to stream sections independently. The shell renders instantly; each section appears as its data resolves.
When to stay on Pages Router
The App Router is not always the right choice. Projects that rely heavily on getServerSideProps patterns, have large existing codebases on Pages Router, or need mature third-party integrations should migrate carefully — not urgently.
Our rule: new projects start on App Router. Legacy projects migrate when there is a clear performance or DX benefit, not just to chase the latest.