All posts

A practical mental model for Next.js caching and ISR

8 min read
Next.jsCachingPerformance

When to reach for static generation, when to revalidate, and how to avoid fighting the framework when data freshness matters.

Caching in Next.js is powerful when you name what you are optimizing for: latency, freshness, or operational simplicity. This post is a field guide—not a replacement for the official docs.

Start with the request path

When a user hits a route, the framework composes cached segments. Static pieces can be reused across users; dynamic pieces run on the server (or edge) at request time.

Three questions before you pick a strategy

  1. Who needs this HTML—everyone, or a signed-in segment only?
  2. How stale can data be before the product feels wrong?
  3. Do you need global invalidation, or is per-entity revalidation enough?
Diagram of stacked cache layers
Figure 1 — Conceptual stack: route cache above data cache above per-request memoization.

When ISR fits

  • Marketing pages with occasional CMS updates.
  • Catalog-style views where eventual consistency is acceptable.
  • Anything where you would otherwise build a cron + static export pipeline by hand.

A tiny checklist before shipping

Revisit tags and revalidate windows after launch traffic patterns appear—what felt right in staging rarely survives reality unchanged.

Stack diagram thumbnail
Left — Layered caches share one mental model.
Pulse diagram thumbnail
Right — Revalidation is a rhythm, not a one-off event.
Line chart abstraction on dark background
Figure 2 — Full-bleed layout for hero-style diagrams (scrolls edge-to-edge on small screens).