Next.js has undergone the most significant architectural shift in its history over the past two years. The App Router โ introduced in Next.js 13 and now the recommended approach โ replaced the Pages Router that Next.js developers had used since the framework’s early days. Understanding what changed, why Vercel made these decisions, and when each approach is appropriate is now essential knowledge for anyone building React applications.
The Core Change: React Server Components
The App Router is built around React Server Components (RSC), a new rendering model that allows components to run on the server and stream HTML to the client without contributing to the JavaScript bundle. In the Pages Router, getServerSideProps and getStaticProps were the mechanisms for server-side data fetching โ they ran on the server but the components that consumed their data still ran in the browser and contributed to the client bundle.
With RSC, entire component trees can render on the server and send the result as an HTML stream. Components that do not need interactivity โ the vast majority of content in most applications โ never ship JavaScript to the client. Only components that explicitly need client-side reactivity are marked with ‘use client’ and included in the bundle.
Practical Impact: Bundle Size and Performance
For content-heavy applications โ marketing sites, blogs, documentation, e-commerce product pages โ the RSC model can dramatically reduce bundle sizes. Components that fetch and display data, format dates, render markdown, or compose layout elements can all run on the server. The browser receives HTML and CSS without the JavaScript for those components.
This matters particularly for mobile users on slower connections, where JavaScript parse and evaluation time is a significant component of time-to-interactive. Core Web Vitals scores โ especially Interaction to Next Paint (INP) โ benefit when the browser has less JavaScript to process before the page becomes interactive.
The New File System Conventions
The App Router introduces a new convention for the app directory. Routes are defined by folders, with page.tsx files defining the route component, layout.tsx files wrapping routes with persistent layouts, loading.tsx files providing Suspense boundaries for streaming, and error.tsx files handling runtime errors. This is a meaningful departure from the pages directory approach, where file names mapped directly to routes without the added flexibility of colocated layout and loading state files.
Nested layouts are one of the App Router’s most practically useful features. A dashboard application with a sidebar navigation can define the sidebar in a layout.tsx at the dashboard segment level โ it renders once and persists across navigation between dashboard routes, rather than re-mounting on every page change as would happen with a shared component in the Pages Router.
When to Still Use the Pages Router
The Pages Router is not deprecated and Vercel has committed to long-term support. For existing applications built on it, migration to the App Router is a significant undertaking that needs to be evaluated carefully. The two routers can coexist in the same application during an incremental migration, but the differences in data fetching patterns, layout structure, and caching behaviour mean teams need to fully understand both approaches to maintain a hybrid codebase without introducing subtle bugs.
For new projects starting today, the App Router is the right default choice. For existing applications working well on the Pages Router, the migration cost needs to be weighed against the specific performance gains the App Router would provide โ and that calculation will differ by application.