Caching Strategies
Master advanced caching strategies in Next.js — combining SSG, ISR, SSR, and client caching for optimal performance across different content types.
Last reviewed: January 2025
🔍 What Is It?
Caching strategy selection in Next.js means choosing the right combination of:
- →SSG — build-time static, served from CDN forever
- →ISR — static with time-based or on-demand revalidation
- →SSR — server-rendered per request, optionally cached at CDN
- →Client-side — fetched in the browser, cached by SWR/TanStack Query
- →unstable_cache — server-side function cache with TTL and tags
- →Redis — shared cache for multi-instance deployments
🎯 Why Do We Need It?
No single caching strategy fits all content:
- →A blog post (changes monthly) → SSG is perfect
- →A product price (changes daily) → ISR with 1hr revalidation
- →A user's order history (changes per user) → SSR
- →Live stock prices (changes per second) → SSR + client polling
Mixing strategies in one app is the norm, not the exception.
🏗️ What Happens in Real Projects?
Caching strategy map for an e-commerce platform:
| Route | Strategy | Reason |
|---|---|---|
| / (homepage) | ISR 1hr + on-demand | Featured products change |
| /products | ISR 1hr | Catalog changes infrequently |
| /products/[slug] | SSG + ISR on-demand | Individual products |
| /blog/[slug] | SSG + on-demand | Published once |
| /search | SSR | Dynamic query |
| /cart | SSR | User-specific |
| /dashboard | SSR | Auth + user-specific |
| /live-prices | SSR + client poll | Real-time |
⚙️ How It Works
Cache decision tree:
- Is the content the same for all users? → Yes: SSG/ISR. No: SSR
- How often does it change? → Never: SSG. Occasionally: ISR. Always: SSR
- Can you tolerate stale content? → Yes: ISR. No: SSR
- Is it triggered by user action? → On-demand ISR or SSR
- Is it real-time? → SSR + client polling or WebSocket
💻 Example
Mixed Caching Strategy Implementation — Different caching strategies in the same Next.js application.
🤔 Common Confusions
❓ Can I use ISR for user-specific pages?
No — ISR caches the same HTML for all users. A user-specific page cached with ISR would show one user's data to all users. Use SSR for any content that differs between users. The rule: ISR for public content, SSR for private content.
❓ Is unstable_cache production-ready?
Yes — despite the "unstable" prefix (a legacy naming issue), unstable_cache is widely used in production. It is the recommended way to add ISR-style caching to database queries. The API may change in future Next.js versions, but it is stable enough for production use.
❓ How do I choose between ISR revalidate time and on-demand revalidation?
Use both together. Time-based revalidation is the safety net — ensures content is eventually fresh even if the webhook fails. On-demand revalidation is the primary mechanism for immediate updates. Example: revalidate: 3600 (1hr safety net) + on-demand webhook on CMS publish.
🚨 Common Production Issues
Cache stampede on popular ISR pages — when a cached page expires and receives thousands of simultaneous requests, all trigger a rebuild simultaneously. Use a distributed lock (Redis) or configure Vercel's ISR cache to handle this automatically.
unstable_cache not shared between serverless instances — each serverless function instance has its own in-memory cache. For shared caching across instances, use Redis with a custom cache handler.
Mixing SSR and ISR on the same route — a route cannot be both SSR and ISR. If any part of the route is dynamic (reads cookies), the entire route is SSR. Design your routes to be either fully static or fully dynamic.
✅ Best Practices
Create a caching strategy document before building — map each route to its strategy
Use both time-based and on-demand revalidation for important content
Tag all cached content for precise on-demand invalidation
Use unstable_cache for DB queries that should have ISR semantics
Test your caching strategy with next build and production traffic patterns
🏛️ Architect's Note
Caching is the most impactful performance lever in a Next.js application. A well-designed caching architecture can reduce server costs by 90% and improve response times by 10x. Invest time upfront in designing the caching strategy for each content type — it is much harder to retrofit caching into an existing app.
💬 Frequently Asked Questions
🎯 Key Takeaways
🔗 Related Topics
🎯 Practice this topic in interviews
↗ Where this topic fits
Next.js Technology Guide
Return to the Next.js learning hub.
Frontend Engineer Career Path
A beginner-friendly journey through web foundations, React, production frontend engineering, and interview preparation.
Full Stack Java Developer Career Path
A guided route through frontend foundations, Java backend engineering, delivery workflows, and interview readiness.
Sources
Sources / References
Use these Next.js references to verify the concept in official docs and continue into the most relevant SplashRide pages.
Official documentation
Related SplashRide pages
SplashRide Next.js learning path
Browse the full Next.js topic collection and learning order on SplashRide.
Next.js Interview Prep
Practice Next.js interview questions and scenario-based answers.
Frontend Engineer Career Path
A beginner-friendly journey through web foundations, React, production frontend engineering, and interview preparation.
Full Stack Java Developer Career Path
A guided route through frontend foundations, Java backend engineering, delivery workflows, and interview readiness.
Incremental Static Regeneration (ISR)
Master ISR — the Next.js feature that gives you static performance with dynamic freshness. Learn time-based and on-demand revalidation for real production systems.
Caching in Next.js
Understand all four caching layers in Next.js — Request Memoisation, Data Cache, Full Route Cache, and Router Cache — and how they interact.