Rendering Strategies: CSR, SSR, SSG, ISR and Streaming

Hydrating less: selective, partial, islands and Server Components

Because hydration is the cost, several ideas pay less of it. Their names are often confused.

• Selective hydration (React 18 and later). With streamed HTML and <Suspense> boundaries, React can hydrate each boundary separately. The React 18 working group's architecture note describes the constraint it removed (all JavaScript loaded and all components hydrated before any interaction) and says a part the user interacts with is hydrated first.
• Progressive and partial hydration. web.dev defines progressive rehydration as booting parts of an app over time, and partial rehydration as turning the JavaScript of mostly static parts into inert references.
• Islands. A mostly static page with small interactive components hydrated independently. Astro's documentation defines a client island as an interactive component "hydrated separately from the rest of the page", with JavaScript shipped only for components that opt in.
• React Server Components (RSC). react.dev's description: components that render ahead of time, before bundling, in a separate environment, either once at build time or per request. The client receives their output, not their code. Components needing state or event handlers are marked "use client". In Next.js, JavaScript hydrates those Client Components, so hydration work applies to them. RSC is stable in React 19, but the APIs for building a framework do not follow semver, so in practice you use it through one.

Figure 4. A product page split into server output and an island

How to read this: most of the page is output with no client behaviour and needs no hydration. Only the button, which has state and a click handler, ships code and is hydrated. This is a design sketch of the idea, not any one framework's exact output.

Static site generation (SSG)

With SSG the HTML for each URL is produced once, at build time, and stored as files. MDN notes that a static site's content is generated at build time, not request time, and can be served from a CDN. At request time there is no rendering at all.

Figure 5. Request lifecycle of static generation

How to read this: the top half happens once, with no user waiting. The bottom half, repeated for every visitor, contains no server work.

web.dev says static rendering gives a consistently fast TTFB. SSG also fails well: if the back end is down, files already on the CDN keep serving. The costs: build time grows with the number of pages, content is as old as the last build, and one file serves everyone, so the HTML cannot hold anything specific to the visitor. That is a good deal for the store's home page, and a poor one for tens of thousands of product pages whose prices change during the day.

Incremental static regeneration (ISR)

ISR keeps the benefits of static pages while letting them update after deploy. The term was popularised by Next.js, which announced stable support in version 9.5 (July 2020). That announcement describes re-rendering existing pages in the background as traffic comes in, inspired by stale-while-revalidate (RFC 5861): serve the saved copy now, refresh it in the background, use the new copy afterwards.

The behaviour below is from the Next.js App Router documentation as read in early November 2026 (latest release then: 16.4), for ISR without the newer Cache Components option. New apps created with the recommended defaults already enable Cache Components, which has its own "ISR with Cache Components" guide, so check which model your app uses. Other frameworks differ in names and details.

// app/products/[id]/page.js (Next.js App Router)
export const revalidate = 3600; // seconds

export async function generateStaticParams() {
  const products = await fetch("https://api.example.com/products").then((r) => r.json());
  return products.map((p) => ({ id: String(p.id) }));
}

export default async function Page({ params }) {
  const { id } = await params;
  const product = await fetch(`https://api.example.com/products/${id}`).then((r) => r.json());
  return (
    <main>
      <h1>{product.name}</h1>
      <p>{product.price}</p>
    </main>
  );
}

Per the docs, pages from generateStaticParams are prerendered at build time and requests are served from the cache. After the revalidation time passes, the next request still receives the stale page and triggers regeneration in the background; once it succeeds, later requests get the new page. A path not prerendered is generated on first request (see dynamicParams). If regeneration throws, the last good page keeps being served and the next request retries.

Figure 6. Request lifecycle of incremental static regeneration

How to read this: the visitor who triggers regeneration does not wait; they get the old page. The price of that choice is that one visitor after expiry sees data older than the limit you set.

On-demand revalidation shortens that gap: code that knows the data changed (a price edit, say) calls revalidatePath or revalidateTag, which marks the page stale so it regenerates on the next request. Caveats from the same page: ISR needs the Node.js runtime and is not supported in a static export; with several instances the default file-system cache is per instance, so on-demand revalidation only invalidates the instance that received the call unless you share a cache; and the x-nextjs-cache header reports HIT, STALE, MISS or REVALIDATED.

At the HTTP level the same idea can be written for any CDN that supports it:

Cache-Control: public, s-maxage=300, stale-while-revalidate=60

This lets a shared cache keep the response fresh for 300 seconds and reuse it for up to 60 more while it fetches a new one (illustrative values; MDN documents the directives; support varies by cache, so check your CDN). See caching basics for TTLs and advanced caching for stampedes: the Next.js 9.5 announcement says at most one regeneration happens per revalidate window, to prevent one.

Streaming server rendering

Plain SSR sends nothing until the whole page is ready, so one slow query delays everything. Streaming sends the HTML in pieces. React's renderToPipeableStream (Node.js) defines the shell as everything outside any <Suspense> boundary. React sends the shell when ready, with a fallback (a skeleton, say) in place of each boundary still loading. When a boundary's data arrives, React sends its HTML plus a small inline script that swaps it in, and react.dev notes the swap does not wait for the page's JavaScript.

import { Suspense } from "react";

export default function ProductPage({ id }) {
  return (
    <>
      <ProductSummary id={id} />                 {/* in the shell: fast data */}
      <Suspense fallback={<ReviewsSkeleton />}>  {/* streamed when ready */}
        <Reviews productId={id} />
      </Suspense>
    </>
  );
}

Figure 7. Request lifecycle of streaming server rendering

How to read this: the shell leaves as soon as the fast data is ready. The slow service delays only its own section.

Streaming gives an earlier first paint than plain SSR, per-section loading states, and (per the Next.js streaming guide) independent hydration of boundaries. It also constrains you:

• The status code is committed with the first chunk. Once streaming begins you cannot change the status code or headers. A notFound() that fires mid-stream cannot become a 404; Next.js adds a noindex meta tag instead. To return a real 404, check existence before the boundary.
• Bots. react.dev suggests crawlers may be better served the complete document (onAllReady) than the shell, and Next.js holds back streaming for bots that need metadata in the initial HTML.
• Layers can buffer. Proxies, CDNs, serverless platforms and compression can hold chunks back and turn a stream into one late response.
• Layout shift and LCP. A skeleton of a different size moves the page when swapped, and an element inside a boundary cannot paint until its swap.

Hybrid models

Strategies can mix inside one URL. Two shapes matter.

1. Static shell, dynamic holes. Next.js calls this Partial Prerendering. With its Cache Components option (cacheComponents: true, already set in new apps created with the recommended defaults, per the docs), a route is prerendered into a static shell that a CDN can serve, while parts that read cookies or fetch uncached data sit behind <Suspense> and stream in per request.
2. Static page, client-side holes. Serve the same prerendered HTML to everyone and let a small client component fetch personal parts (cart count, "welcome back") after load. This works in any framework, at the cost of a visible update.

Comparison

Judgements are qualitative and describe usual behaviour, not measurements. "Time to interactive" means the moment the page reliably responds to input; lab tools have a formal TTI metric, but web.dev's rendering article focuses on TBT and INP instead.

How each strategy meets HTTP caches and CDNs

Two kinds of response are involved: the HTML document and the files it points to (JavaScript, CSS, images). The rendering strategy mostly decides the policy of the first.

• Hashed assets. Name each build file after its content (app.4f9c1e.js) and allow very long caching with immutable; the Next.js 9.5 announcement says it began setting such a header on hashed bundles, and the CDN lesson covers versioned URLs and cache headers. A new build means new names, so nothing needs purging.
• CSR shell, SSG and ISR pages. The shell is identical for everyone, so cache it, but briefly or with revalidation, because it names the current bundle. Static and regenerated pages live in the CDN and change on deploy or by the ISR rules above.
• SSR pages. Shared-cacheable only when the output is the same for many visitors. If it depends on the user, MDN advises private, or no-store for sensitive content, and warns that forgetting private on personalised content lets a shared cache reuse it for other users and leak personal information.
• Streamed responses. They can pass through a cache, but any layer that buffers removes the benefit.

HTTP Caching for the Front End covers document caching in depth. One rendering-specific hazard belongs here: version skew, which the Next.js glossary defines as clients still active after a deploy referencing JavaScript, CSS or data from an older build. A CDN may hold HTML naming old assets, or a user may hold an old page requesting files a new deploy removed. A common precaution is to keep previous build assets available for a period.

Choosing per page type

Figure 8. Choosing a strategy for a page

How to read this: start at the top and take the first answer that fits. "Must the first HTML contain the content" is about search, link previews and perceived speed, not taste.

Applied to the store, as a starting point rather than a rule:

Mixing strategies in one product

Strategies are chosen per route, and they coexist. react.dev says frameworks let you add server-side rendering per route when it makes sense.

Figure 9. The store with a strategy per route

How to read this: shared pages travel the top path and are produced ahead of time or in the background. Per-user pages take the bottom path, produced per request. Dashed flow marks work off the request path.

Three rules keep a mixed product coherent. Shared layout code must be safe in every mode: no reads of window or the clock while rendering. Personal fragments inside shared pages, such as the cart count in the header, are islands or streamed holes so the page itself stays shareable. And after the first load most frameworks navigate in the browser, so a shopper moves between a static category page and a dynamic account page without noticing.

Which metric moves

Metrics, thresholds and measurement belong to Loading Performance and Core Web Vitals. Here is only the direction each strategy tends to push them, drawn from web.dev's Rendering on the Web and the Next.js streaming guide. LCP is largest contentful paint, CLS is cumulative layout shift.

The cost of choosing wrongly

Moving data fetching between browser and server changes code structure, error handling and security assumptions, which is why the choice belongs early in a design.

In practice: moving a store's product and category pages off client-side rendering

The situation

A mid-sized online store sells about 40,000 products (illustrative). It is a React single-page application on a CDN, with a REST catalogue API and a separate cart and account API. Product pages rank poorly, link previews in chat apps show only the site name, and the largest contentful paint is late on mid-range phones. Prices change several times a day during promotions.

Starting architecture

Figure 10. Starting architecture: everything is built in the browser

How to read this: the CDN serves only an empty shell and the bundle. Every product view makes the browser call the catalogue API, so content appears last (the sequence in Figure 2).

Options considered

The decision

The page price is a hint and the cart is the truth: the cart re-reads price and stock from the catalogue service.

Rollout and verification

1. Compare before switching. Fetch sample product URLs from old and new builds and compare the fields in the HTML (title, price). Differences are bugs.
2. Route by route. Switch category pages first, then product pages, behind a routing rule that can return one group to the old build.
3. Verify cache behaviour. Check x-nextjs-cache and the CDN hit ratio, and confirm an edited price appears after the on-demand call.
4. Verify outcomes and failure. Compare LCP and INP field data by route, indexed pages and link previews, and fail the catalogue API during a staging regeneration: the old page must keep serving.

The 2 a.m. failure

A promotion ends at midnight. At 02:00 support reports category pages still showing sale prices while the cart shows full prices.

Figure 11. One invalidation call, several caches

How to read this: the invalidation is one request, and only the instance that receives it clears its cache.

The cause is a documented ISR caveat: with several instances the default file-system cache is per instance, so on-demand revalidation only invalidates the instance that received the call. Detection: price mismatches between page and cart. First three checks: x-nextjs-cache on repeated requests (different instances answer differently), how many instances run, and whether a shared cache handler is configured. Mitigation: shorten the time-based revalidation for the affected routes, or redeploy to reset caches. Follow-ups: configure a shared cache handler as the Next.js documentation describes, alert on page versus cart price mismatches, and test invalidation against more than one instance.

Architect's notes

• Decide per page type, early, with one line each: strategy, freshness limit, personalisation. Changing later moves code between browser and server.
• State the freshness limit as a business number. How old may a category price be? The answer chooses between ISR, streaming and SSR.
• Treat displayed facts as a cache, and keep personal data out of shared caches by separating shell from per-user parts in the component tree, not by remembering headers.
• Measure hydration, not just load. INP field data by route shows a page that paints early and stays unresponsive.
• Defer exotic options. Partial prerendering, Server Components and islands are worth adopting when a measured problem calls for them.

Common mistakes

• Treating "SSR" as one thing. Plain, streamed, static and regenerated pages differ in first byte, caching and failure. Name the exact strategy.
• Calling a page static while it reads cookies. Request-dependent data makes a page dynamic in Next.js, and a shared cache must not store it.
• Hydration mismatches from time, randomness or window checks in render code. Render the same on both sides, then update after mount.
• Putting the key element in a slow Suspense boundary. The largest content arrives last.
• Forgetting that a crawler or preview fetcher is not a browser. If its output matters, inspect the initial HTML.

Key takeaways

• Every strategy answers two questions: where and when the HTML is produced.
• CSR moves work to the browser and costs first paint and search visibility; it suits pages behind a login.
• SSR sends content early but waits for the server first.
• SSG and ISR turn pages into files: fastest and most resilient, with staleness as the price. ISR refreshes in the background using the stale-while-revalidate idea.
• Streaming trades a complete page for an early shell, but commits the status code first and relies on layers not buffering.
• Hydration is the shared cost, and a mismatch means the browser's first render differs from the server's HTML.
• Selective hydration, islands and Server Components pay less hydration by hydrating less code.
• Choose per page type, mix strategies in one product, keep personal data out of shared caches, and remember a displayed price is a cache: the step that charges must re-check.

Practice exercises

Exercise 1 - Starter (30 min): For each of the store's five page types, write the strategy you would choose and the maximum age of its data. Compare with the table in this lesson and note where you differ and why.

Exercise 2 - Intermediate (1 hour): Fetch a client-rendered page and a server-rendered or static page with curl -s <url>. List what text a crawler would see in each, then open both with JavaScript disabled and describe what changes.

Exercise 3 - Intermediate (2 hours): Build a small server-rendered page whose component prints new Date().toLocaleTimeString() and hydrate it. Reproduce the mismatch warning in development, then fix it with the render-the-same-then-update approach.

Exercise 4 - Advanced (half day): In a framework that supports ISR, create a product page with revalidate set to 30 seconds (illustrative). Change the source data, request the page repeatedly and note when the new content appears. Add on-demand revalidation and repeat.

Related reading

In this course:

• HTTP Caching for the Front End — which responses the browser keeps, and for how long.
• The Critical Rendering Path — how bytes become pixels, and what blocks what.
• How a Browser Actually Works — the processes and threads inside a browser, and the path of a navigation.
• Loading Performance and Core Web Vitals — how to measure loading, interaction and stability.

Elsewhere on the site:

• System Design: Caching Basics: TTLs and invalidation, the back-end view of what ISR does for pages.
• System Design: CDN and Object Storage: edge caches, cache headers and versioned URLs.
• System Design: Advanced Caching: stampedes and refresh strategies.
• System Design: Request Lifecycle: what a server does with a request, including the work SSR adds.

Official documentation

• Rendering on the Web (web.dev): definitions and trade-offs of CSR, SSR, static rendering, streaming and rehydration.
• hydrateRoot (react.dev): what hydration is and how mismatches behave.
• renderToPipeableStream (react.dev): the shell, Suspense boundaries and streaming.
• Server Components (react.dev): what Server Components are and when they run.
• Incremental Static Regeneration (Next.js docs): revalidation behaviour and caveats.
• Streaming (Next.js docs): the HTTP contract, bots and buffering.