Lesson After the write: revalidate and pending states introduced revalidation, and that call is the hinge this unit turns on.
revalidatePath("/blog") invalidates the cached data for that route, so the next render fetches fresh data instead of reusing the stored copy. Mutations change the database, not the cache, which is why the action has to say so explicitly.
Sitting behind that call is a bigger question: when does a page get rendered in the first place. This unit answers it properly.
When a page gets rendered
Everything in Units 4 and 5 comes down to one decision per page: the moment at which the server runs your components. There are three possible answers.
- Static. Rendered once at build time (
next build). Every visitor gets the same prebuilt HTML instantly. Think marketing pages, docs, and blog posts listed bygenerateStaticParams. - Dynamic. Rendered on every request. Always fresh, always personal, but the visitor waits for the render. Think dashboards, carts, and anything reading cookies.
- ISR (Incremental Static Regeneration). The hybrid: served static, but re-rendered in the background after a time window (
revalidate: 60). Visitors always get instant HTML that is at most a little stale.
| Strategy | Rendered | Freshness | Cost per request |
|---|---|---|---|
| Static | Once, at build | Until the next build | Near zero, a CDN file |
| ISR | At build, then refreshed on a timer | Within the revalidate window | Near zero, plus occasional background renders |
| Dynamic | Every request | Always current | A full render per visitor |
Choosing a strategy for a news homepage
A news homepage must load instantly for millions of readers but should show new headlines within about a minute. ISR with revalidate: 60 fits best.
ISR serves prebuilt HTML, which is what makes it instant at that scale, while re-rendering in the background at most once per 60 seconds. Headlines are therefore never more than roughly a minute stale, which is well inside what readers expect from a news site.
The alternatives fail in opposite directions. Fully dynamic rendering would re-render the homepage for every one of those millions of requests, melting the servers for no editorial benefit, since all readers see the same headlines anyway. Fully static rendering with a daily build would be fast but hopelessly stale for news.
Classifying a shopping-cart page
A shopping-cart page that reads the user's session cookie to show their items is dynamic.
The page depends on the session cookie, and a cookie is information that exists only when a specific user makes a request. It cannot be rendered once at build time, because at build time there is no user, and it cannot be shared between visitors from a cache, because each visitor's cart differs. Every request gets its own render.
| Page | Same for everyone | Changes | Strategy |
|---|---|---|---|
| Docs page | Yes | Rarely | Static |
| News homepage | Yes | Every few minutes | ISR |
| Shopping cart | No | Per user, per request | Dynamic |
Why it works out that way
- Cookies are only available at request time, so touching them rules out build-time rendering by definition.
- Anything personalized is unshareable, and caching only pays off for responses that many visitors can reuse.