How do you implement caching strategies for SSR responses in Next.js? (CDN, Cache-Control, stale-while-revalidate)

Question

Accepted Answer

Implementing caching for Server-Side Rendering (SSR) in Next.js transforms dynamic pages into performant, cacheable assets. By setting appropriate Cache-Control headers in getServerSideProps, you instruct CDNs to store rendered HTML and serve it instantly to users, while using stale-while-revalidate to keep content fresh in the background. This approach reduces server load, improves Time to First Byte (TTFB), and provides a balance between dynamic data needs and static performance. // pages/products/[id].js
// Implementing stale-while-revalidate caching strategy

export async function getServerSideProps({ params, res }) {
  // Set cache control headers before any response
  res.setHeader(
    'Cache-Control',
    'public, s-maxage=10, stale-while-revalidate=59'
  );
  
  try {
    // Fetch data from your API or database
    const product = await fetch(`https://api.example.com/products/${params.id}`)
      .then(r => r.json());
    
    return {
      props: { product }
    };
  } catch (error) {
    // Even error responses can be cached briefly
    res.setHeader('Cache-Control', 'public, s-maxage=5');
    return {
      notFound: true
    };
  }
}

// Header breakdown:
// public - Allows CDN and browser caches to store
// s-maxage=10 - CDN caches for 10 seconds (fresh window)
// stale-while-revalidate=59 - For 59 seconds after expiry, serve stale + background refresh
// Total cacheable window: 69 seconds (10 fresh + 59 stale) public: Allows any cache (CDN, proxy, browser) to store the response. Essential for CDN caching. s-maxage: Specifies how long the CDN should consider the response fresh (in seconds). After this, it becomes stale. stale-while-revalidate: During this window, the CDN can serve the stale response while asynchronously fetching a fresh version. stale-if-error: If the origin fails during revalidation, serve stale content for up to this many seconds as a fallback. private: Prevents CDN caching; only browser can cache. Use for user-specific content. no-cache, no-store: Disables caching entirely. Use for sensitive or real-time data. The stale-while-revalidate pattern is the foundation of modern SSR caching. When a request arrives for a cached page, the CDN checks its freshness: If within s-maxage, the cached version is served instantly (HIT). If past s-maxage but within stale-while-revalidate window, the CDN serves the stale version immediately while triggering a background request to your origin to generate a fresh copy. The next user gets the updated version. This ensures users never wait for page generation, even during cache expiration, while content eventually updates. This pattern is identical to how ISR works, but applied to SSR responses. // pages/products/[id].js
// Dynamic caching based on content type or user status

export async function getServerSideProps({ params, req, res }) {
  // Check if user is authenticated (via cookie)
  const isAuthenticated = req.cookies.session ? true : false;
  
  if (isAuthenticated) {
    // Private content - no CDN caching
    res.setHeader('Cache-Control', 'private, no-cache, no-store, must-revalidate');
    
    const userData = await fetch(`https://api.example.com/user-products/${params.id}`)
      .then(r => r.json());
    
    return { props: { product: userData, isAuthenticated } };
  } else {
    // Public content - aggressive caching
    // Check if this is a popular product (maybe from your analytics)
    const isPopular = await checkProductPopularity(params.id);
    
    if (isPopular) {
      // Popular products: longer cache
      res.setHeader(
        'Cache-Control',
        'public, s-maxage=3600, stale-while-revalidate=86400'
      );
    } else {
      // Regular products: moderate cache
      res.setHeader(
        'Cache-Control',
        'public, s-maxage=300, stale-while-revalidate=3600'
      );
    }
    
    const product = await fetch(`https://api.example.com/products/${params.id}`)
      .then(r => r.json());
    
    return { props: { product, isAuthenticated } };
  }
}

// This ensures authenticated users always see fresh data,
// while public traffic benefits from aggressive caching When deploying to platforms like Vercel, the Cache-Control headers are automatically respected by their global CDN. You can monitor cache performance using response headers: x-vercel-cache indicates HIT, MISS, or STALE. For self-hosted deployments with CDNs like Cloudflare, Fastly, or AWS CloudFront, these headers are also respected. However, you may need to configure your CDN to forward the Cache-Control headers correctly and set up purging mechanisms for manual invalidation when content changes unexpectedly. // Add custom headers to monitor cache behavior

export async function getServerSideProps({ params, res }) {
  const startTime = Date.now();
  
  res.setHeader(
    'Cache-Control',
    'public, s-maxage=10, stale-while-revalidate=59'
  );
  
  const product = await fetch(`https://api.example.com/products/${params.id}`)
    .then(r => r.

How do you implement caching strategies for SSR responses in Next.js? (CDN, Cache-Control, stale-while-revalidate)

Implement SSR caching in Next.js by setting Cache-Control headers with s-maxage and stale-while-revalidate directives in getServerSideProps, enabling CDN caching with background revalidation

How do you implement caching strategies for SSR responses in Next.js? (CDN, Cache-Control, stale-while-revalidate)

Implement SSR caching in Next.js by setting Cache-Control headers with s-maxage and stale-while-revalidate directives in getServerSideProps, enabling CDN caching with background revalidation

Scenario Questions

Follow-up Questions