Headless WordPress, ISR vs SSR: pick the rendering mode by content cadence
The “ISR or SSR” question only makes sense per-route. There is no whole-site answer. Astro and Next.js both let you choose mode at the page or layout level, and the senior-engineering move is to choose deliberately, route by route, against a content-cadence model.
This article anchors to the Headless WordPress service pillar and pairs with the Next.js vs Astro decision matrix, which covers the framework-level choice.
TL;DR
- ISR (or static + revalidation) wins when content cadence is predictable and traffic is high.
- SSR wins when the page is personalised, session-driven, or contains live data.
- Cache invalidation drives ISR correctness; webhooks beat time-based revalidation.
- Cloudflare Workers runs both; ISR pays almost no CPU, SSR pays the full render.
- The default is the cheapest mode that satisfies correctness; promote to SSR only when needed.
What each mode actually does
Static / Static Site Generation (SSG). The page is built once, at build time, and served as flat HTML. Cheapest at request time, slowest to update.
Incremental Static Regeneration (ISR). The page is built once but can be regenerated on a trigger, usually a webhook on publish or a time-based revalidation interval. Cheap at request time, eventual consistency on update.
Server-Side Rendering (SSR). The page is rendered on every request. Always fresh, but the runtime cost scales with traffic. Personalisation, authentication, and live data fit naturally here.
In headless WordPress, all three read from the WordPress origin via REST or GraphQL. The difference is when they read.
The decision rule
Two inputs matter:
Content cadence. How often does this page change? Once a quarter, once a day, every minute, in real time?
Personalisation surface. Does this page differ per visitor? Logged-in state, location-aware pricing, A/B test variant.
The rule: pick the cheapest mode that satisfies correctness. Static is cheapest. SSR is most expensive. Promote toward SSR only when correctness fails on a cheaper mode.
| Page type | Default mode | Why |
|---|---|---|
| Marketing pages, blog posts | Static (rebuild on publish) | Low cadence, no personalisation |
| Category and tag archives | ISR with publish webhook | Cadence tied to content publish |
| Product pages, stable catalogue | ISR with stock webhook | Predictable invalidation |
| Product pages, real-time stock | SSR with edge cache | Stock changes within seconds |
| Cart and checkout | SSR | Session-driven by definition |
| Authenticated dashboard | SSR | Per-user state |
| Editorial homepage | ISR with publish webhook | Cadence tied to publish events |
Cache invalidation is the load-bearing piece
ISR sounds free until it serves a stale canonical URL after a slug change. The pattern that prevents that:
Webhook-driven invalidation. WordPress fires a webhook on publish, slug change, or post deletion. The front-end framework consumes the webhook and triggers a regeneration of the affected pages. The cost is one webhook integration on the WordPress origin, paid once.
Time-based revalidation as a backstop only. Setting a 60-second revalidation interval covers webhook delivery failures but should not be the primary trigger. A page that revalidates every 60 seconds also rebuilds 60 times per hour; on a 5000-page site that is unsustainable.
Cache tags, not URLs. Every cached page is tagged with the WordPress post ID, the term IDs it references, and any cross-cutting tags (homepage, sitemap). When a webhook arrives, the front purges by tag, not by URL. This is the difference between “regenerate the product page” (fragile) and “regenerate everything that references product 8421” (correct).
Where Cloudflare Workers fits
Both Astro and Next.js compile to a Workers-compatible runtime. The mode-by-mode cost picture:
- Static at the edge. Cloudflare Pages serves flat HTML for almost no CPU per request. Cheapest mode.
- ISR. First request after invalidation pays the full render cost; cached requests pay almost nothing. Workers handles both.
- SSR. Every request pays the full render cost on Workers. Predictable per-request, expensive at scale.
Per the headless economics article, the cost difference matters at high traffic. At low traffic, the choice is correctness, not cost.
Three real route patterns
Marketing homepage. Static, rebuilt on every editorial publish via webhook. Cache for 24 hours at the edge with manual purge override. SSR fallback only if a country-specific banner is added.
WooCommerce product detail page. ISR keyed by product ID. Webhook from WooCommerce on stock change, price change, or content update. Cache window: 1 hour as backstop. SSR only if real-time stock display is a UX requirement.
Customer order history. SSR. Per-user, session-driven, no caching at the edge.
The same architecture; three different rendering modes; one decision rule.
Where this fits
This long-tail article anchors to the Headless WordPress service pillar. For framework-level choice, see the Next.js vs Astro decision matrix. For migration-side risks, the SEO patterns checklist is the seven-point list. For commerce specifics, Headless WordPress for WooCommerce is the focused decision article.
