Next.js 15 Caching: What Changed and Why

Most Next.js caching problems stem from aggressive defaults that made debugging production behavior unpredictable. Next.js 15 reverses this entirely. The framework shifted from "cache everything by default" to "cache nothing unless you ask." This is not a minor API tweak—this changes the mental model for every App Router application.

The Caching Philosophy Shift in Next.js 15

The original App Router caching strategy prioritized static optimization. GET requests cached indefinitely. Route handlers cached responses. Client-side router cache persisted navigation state across visits. Developers faced mysterious stale data issues in production that never appeared in development. The fix required explicit cache: 'no-store' flags scattered across fetch calls and aggressive revalidatePath invocations.

Next.js 15 flips this relationship. Fetch requests now default to dynamic behavior. Route handlers no longer cache by default. The router cache duration dropped from indefinite to zero for dynamic routes. This matters because the new defaults align with what developers actually expect: fresh data unless explicitly cached.

The implication here is that existing Next.js 14 applications will see more server requests after upgrading. Performance does not degrade—it shifts from stale-but-fast to fresh-but-intentional. Teams regain control over what caches and when.

What Changed: From Aggressive to Opt-In Caching

The Next.js 14 model treated every fetch as a cache candidate. A standard data-fetching component looked like this in production:

// Next.js 14: cached by default
async function UserProfile({ id }: { id: string }) {
  const user = await fetch(`https://api.example.com/users/${id}`);
  const data = await user.json();
  return <div>{data.name}</div>;
}

That request cached indefinitely on the server. Redeploying the application did not clear it. The only escape hatch was adding { cache: 'no-store' } or { next: { revalidate: 0 } } to every fetch call.

Next.js 15 inverts this. The same component now fetches fresh data on every request unless you opt into caching:

// Next.js 15: dynamic by default
async function UserProfile({ id }: { id: string }) {
  const user = await fetch(`https://api.example.com/users/${id}`, {
    next: { revalidate: 3600 } // explicit 1-hour cache
  });
  const data = await user.json();
  return <div>{data.name}</div>;
}

The shift affects static generation timing as well. Pages that previously pre-rendered at build time now render on-demand unless you add explicit caching directives or static params.

%% alt: Next.js 14 vs 15 caching decision tree
flowchart TD
    Request[Incoming Request]
    Request --> V14{Next.js 14}
    Request --> V15{Next.js 15}
    
    V14 --> Cache14[Cache by default]
    Cache14 --> Opt14[Must opt OUT with no-store]
    
    V15 --> Dynamic15[Dynamic by default]
    Dynamic15 --> Opt15[Must opt IN with revalidate]
    
    style Cache14 fill:#fee,stroke:#f00
    style Dynamic15 fill:#efe,stroke:#0a0

Understanding the New Fetch Behavior and Cache Defaults

The fetch API changes split into three categories: static requests, dynamic requests, and partial prerendering. Understanding the decision tree prevents production surprises.

In Next.js 14, this fetch cached indefinitely:

const response = await fetch('https://api.example.com/data');

Next.js 15 treats it as dynamic. To restore caching, add the force-cache option:

const response = await fetch('https://api.example.com/data', { 
  cache: 'force-cache' 
});

The force-cache directive tells Next.js to store the response permanently until explicit revalidation. This replaces the old default behavior but requires intentional opt-in.

For time-based revalidation, the next.revalidate option remains the primary API:

const response = await fetch('https://api.example.com/data', {
  next: { revalidate: 60 } // cache for 60 seconds
});

This creates a stale-while-revalidate pattern. The cached response serves immediately while Next.js fetches fresh data in the background. The failure mode here is subtle but expensive: forgetting the revalidate option means every request hits your API endpoint.

%% alt: Fetch caching comparison between Next.js 14 and 15
flowchart LR
    subgraph V14["Next.js 14: Aggressive Caching"]
        F14[fetch request] --> C14{Has no-store?}
        C14 -->|No| Cache14[Cache indefinitely]
        C14 -->|Yes| Dynamic14[Dynamic request]
        Cache14 --> Serve14[Serve from cache]
    end
    
    subgraph V15["Next.js 15: Opt-In Caching"]
        F15[fetch request] --> C15{Has force-cache or revalidate?}
        C15 -->|No| Dynamic15[Dynamic request]
        C15 -->|Yes| Cache15[Cache with rules]
        Cache15 --> Serve15[Serve from cache]
    end

Using revalidateTag and revalidatePath for Manual Cache Control

The on-demand revalidation APIs remain the most powerful cache control mechanism in Next.js. These functions clear cached data without waiting for time-based expiration. The pattern works across both caching models but becomes more critical in Next.js 15 where explicit cache configuration determines what persists.

Tag-based revalidation associates cache entries with semantic labels:

// app/actions.ts
'use server'
 
import { revalidateTag } from 'next/cache';
 
export async function updateUser(userId: string, data: object) {
  await fetch(`https://api.example.com/users/${userId}`, {
    method: 'PATCH',
    body: JSON.stringify(data),
  });
  
  revalidateTag('user-profile');
  revalidateTag(`user-${userId}`);
}
 
// app/profile/[id]/page.tsx
async function ProfilePage({ params }: { params: { id: string } }) {
  const user = await fetch(`https://api.example.com/users/${params.id}`, {
    next: { revalidate: 3600, tags: ['user-profile', `user-${params.id}`] }
  });
  
  return <UserProfile data={await user.json()} />;
}

The revalidateTag call purges every fetch response associated with that tag across the entire application. This matters because you can invalidate related data without knowing exact URLs. A user update can clear profile pages, dashboard widgets, and navigation components in a single function call.

Path-based revalidation targets specific routes:

'use server'
 
import { revalidatePath } from 'next/cache';
 
export async function publishPost(postId: string) {
  await fetch(`https://api.example.com/posts/${postId}/publish`, {
    method: 'POST'
  });
  
  revalidatePath('/blog');
  revalidatePath(`/blog/${postId}`);
  revalidatePath('/dashboard/posts', 'layout');
}

The third argument to revalidatePath controls scope. The 'page' option (default) revalidates only the exact path. The 'layout' option revalidates the path and all nested segments. This distinction is critical when working with Next.js layouts and templates that share data across multiple routes.

The 'use cache' Directive: Preparing for Next.js 16

Next.js 16 introduces the 'use cache' directive as the primary caching primitive. While Next.js 15 does not support it in stable releases, understanding the pattern prepares codebases for migration. The directive marks entire functions or components for caching rather than individual fetch calls.

The proposed syntax looks like this:

'use cache'
 
async function getProductData(id: string) {
  const response = await fetch(`https://api.example.com/products/${id}`);
  return response.json();
}
 
export default async function ProductPage({ params }: { params: { id: string } }) {
  const product = await getProductData(params.id);
  return <ProductDetails data={product} />;
}

The 'use cache' directive at the function level tells Next.js to cache the entire function result, not just the fetch response. This enables caching for database queries, file system operations, and computed data without wrapping everything in fetch calls.

The mental model shift here is significant. Instead of annotating individual requests, developers mark cacheable operations at the function boundary. This aligns with React Server Components semantics where async functions represent the unit of server work.

Next.js 16 pairs 'use cache' with cacheLife and cacheTag APIs for granular control:

'use cache'
export async function getUserPosts(userId: string) {
  'use cacheLife'
  const posts = await db.query(
    `SELECT * FROM posts WHERE user_id = $1`,
    [userId]
  );
  
  return posts;
}

This pattern separates what caches from how long it caches. Teams preparing for Next.js 16 should identify expensive operations that benefit from caching and isolate them into dedicated functions now. The migration path then becomes adding the directive rather than restructuring code.

Router Cache and staleTimes Configuration

The client-side router cache stores page data during navigation. Next.js 14 held this cache indefinitely for static routes and 30 seconds for dynamic routes. Next.js 15 reduces both to zero by default. Users navigating back to a page always see fresh data, but this means more server requests.

The staleTimes configuration in next.config.js controls this behavior:

// next.config.ts
import type { NextConfig } from 'next';
 
const config: NextConfig = {
  experimental: {
    staleTimes: {
      dynamic: 30, // cache dynamic routes for 30 seconds
      static: 180, // cache static routes for 3 minutes
    },
  },
};
 
export default config;

Setting stale times re-enables the router cache. This improves perceived performance for apps with frequent back-and-forth navigation patterns. The tradeoff is stale data during the cache window.

%% alt: Router cache behavior with staleTimes configuration
flowchart TD
    Nav[User navigates to page]
    Nav --> Check{Data in router cache?}
    Check -->|Yes| Age{Within staleTime?}
    Check -->|No| Fetch[Fetch from server]
    Age -->|Yes| Serve[Serve from cache]
    Age -->|No| Fetch
    Fetch --> Cache[Store in router cache]
    Cache --> Display[Display page]
    Serve --> Display

The router cache interacts with parallel routes and complex layouts in non-obvious ways. A layout with multiple parallel slots can cache each slot independently. Setting stale times at the layout level affects all nested routes.

The failure mode here is expecting zero stale times to disable caching entirely. The router cache only affects client-side navigation. Direct page loads or refreshes always fetch fresh data. This creates a testing gap where manual testing shows fresh data but production users see stale cached responses.

Migration Strategy: Moving from Next.js 14 to 15 Caching

The migration path from Next.js 14 to 15 requires inventorying fetch calls and static generation patterns. Most applications fall into one of three categories: primarily static, primarily dynamic, or hybrid.

Primarily static apps that pre-render content at build time need explicit force-cache directives:

// Before (Next.js 14)
async function getBlogPosts() {
  const res = await fetch('https://cms.example.com/posts');
  return res.json();
}
 
// After (Next.js 15)
async function getBlogPosts() {
  const res = await fetch('https://cms.example.com/posts', {
    cache: 'force-cache'
  });
  return res.json();
}

Add generateStaticParams to ensure static generation still runs at build time:

export async function generateStaticParams() {
  const posts = await getBlogPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

Primarily dynamic apps benefit from Next.js 15 defaults. Remove cache: 'no-store' flags and revalidate: 0 options—they are redundant now. Focus on adding revalidate values to data that can tolerate staleness.

Hybrid apps require auditing each route. Start with critical user-facing paths and add caching where appropriate. Use the principles of effective caching to identify candidates: high-traffic routes with expensive data fetching or computation.

The testing strategy should verify cache behavior in production mode. Development mode always bypasses caching. Run next build && next start locally and inspect network requests for cache headers. Look for unexpected dynamic rendering or missing cache hits.

When to Use force-cache vs Dynamic Rendering

The decision between force-cache and dynamic rendering maps to data freshness requirements. Use force-cache for content that changes infrequently and tolerates staleness: blog posts, documentation, product catalogs, marketing pages. These routes benefit from instant response times and reduced server load.

Dynamic rendering fits user-specific content, real-time data, and frequently updated resources: user profiles, dashboards, search results, inventory counts. The cost of a server request on every visit is acceptable when data must be current.

The middle ground uses time-based revalidation with next.revalidate. This works for content that updates periodically but does not require per-request freshness: news articles (revalidate every 60 seconds), pricing data (revalidate every 5 minutes), analytics dashboards (revalidate every 30 seconds).

The critical mistake is applying force-cache to user-specific routes. This creates security issues and data leakage. A user viewing their profile should never see another user's cached data. Always use dynamic rendering for authenticated routes unless the data is truly user-agnostic.

That covers the essential patterns for Next.js 15 caching. The shift from aggressive defaults to opt-in caching makes production behavior predictable. Apply explicit cache directives, use revalidation APIs for on-demand purging, and prepare for the 'use cache' directive in Next.js 16. The difference in debugging time and user-facing freshness will be immediate.