What's the difference between fetch caching in the App Router vs traditional getServerSideProps?

Question

Accepted Answer

The shift from Pages Router to App Router represents a fundamental change in how data fetching and caching work in Next.js. In the Pages Router, getServerSideProps was a special function that ran on every request, separate from your component logic, and had no built-in caching mechanism—developers had to manually implement caching via Cache-Control headers or external CDNs. In contrast, the App Router integrates data fetching directly into Server Components using the native fetch() API, with granular caching controls that unify static and dynamic rendering under a single, flexible model. This moves from a "function-based" to a "declarative caching" paradigm where rendering strategy is determined by cache options rather than separate data-fetching methods. Location of data fetching: Pages Router required data fetching in separate functions (getServerSideProps, getStaticProps) outside components; App Router allows direct async/await fetching inside Server Components. Default behavior: getServerSideProps always runs on every request; App Router's fetch defaults to 'force-cache' (static) unless explicitly configured otherwise. Granularity: Pages Router operated at page level—one function per page; App Router operates at component level, allowing different caching strategies within the same page. API design: Pages Router used special Next.js functions; App Router uses standard Web fetch() API with Next.js extensions for caching. In the Pages Router, getServerSideProps was the primary mechanism for Server-Side Rendering. It ran on every request, executed on the server, and returned props that were passed to the page component. Critically, it had no built-in caching—each request triggered a fresh execution, and caching had to be implemented manually by setting Cache-Control headers on the response object. This meant developers needed to understand both Next.js and HTTP caching headers to optimize performance. The function also couldn't be used inside components, forcing all data for a page to be fetched upfront, which could create request waterfalls. // pages/products/[id].js (Pages Router) // Traditional SSR with manual caching export async function getServerSideProps({ params, res }) { // Runs on EVERY request - no built-in caching const product = await fetch(`https://api.example.com/products/${params.id}`) .then(r => r.json()); // Manual caching via HTTP headers (optional) res.setHeader( 'Cache-Control', 'public, s-maxage=10, stale-while-revalidate=59' ); return { props: { product } // Passes data to component }; } export default function ProductPage({ product }) { return

{product.name}

; } // Characteristics: // ✓ Runs per request // ✓ Manual caching only // ✓ Page-level only // ✗ No component-level granularity The App Router completely reimagines this model by making Server Components the default and integrating data fetching directly into components using the native fetch API. Instead of separate functions, you write async components that fetch data directly. The caching behavior is controlled through fetch options, unified across static and dynamic rendering. This means the same fetch API can produce SSG (with 'force-cache'), SSR (with 'no-store'), or ISR (with 'next.revalidate') behavior, all determined by cache options rather than function names. // app/products/[id]/page.tsx (App Router) // Different caching strategies with same fetch API // SSG (Static) - like getStaticProps export default async function ProductPage({ params }) { const product = await fetch(`https://api.example.com/products/${params.id}`, { cache: 'force-cache' // Default - caches until build/invalidation }).then(r => r.json()); return

{product.name}

; } // SSR (Dynamic) - like getServerSideProps export default async function DashboardPage({ params }) { const data = await fetch(`https://api.example.com/dashboard/${params.id}`, { cache: 'no-store' // Fresh on every request }).then(r => r.json()); return

{data.value}

; } // ISR (Revalidating) - like getStaticProps with revalidate export default async function BlogPost({ params }) { const post = await fetch(`https://api.example.com/posts/${params.slug}`, { next: { revalidate: 60 } // Revalidate every 60 seconds }).then(r => r.json()); return

{post.title}

; } // Characteristics: // ✓ Component-level granularity // ✓ Built-in caching via fetch options // ✓ Unified API for all strategies // ✓ Can mix strategies in one page Under the hood, App Router introduces a sophisticated four-tier caching system that works together with fetch options. Understanding this architecture explains why fetch caching behaves differently from getServerSideProps . The layers are: Request Memoization (deduplicates fetches within a single render), Data Cache (persists fetch responses across requests and deployments), Full Route Cache (caches rendered HTML and RSC Payload), and Router Ca

What's the difference between fetch caching in the App Router vs traditional getServerSideProps?

App Router replaces getServerSideProps with per-component fetch caching, where data fetching is integrated directly into components and controlled by cache options, while Pages Router required a separate function that ran on every request without built-in caching

What's the difference between fetch caching in the App Router vs traditional getServerSideProps?

App Router replaces getServerSideProps with per-component fetch caching, where data fetching is integrated directly into components and controlled by cache options, while Pages Router required a separate function that ran on every request without built-in caching

Scenario Questions

Follow-up Questions