Your feed is full of badges: SSR! SSG! ISR! Streaming! Partial hydration! Resumability! The industry keeps inventing new labels for the same handful of problems: render fast, ship content that search engines can find, and keep interaction snappy without melting your servers. The good news: you don’t need to memorize taxonomy. You need to optimize a small set of user-visible outcomes—and pick the strategy that serves them.

Let’s cut through the marketing fog and talk about what actually matters: time to first byte, time to interactive, and indexability. Then we’ll map those outcomes to the handful of architectures worth caring about.

The Taxonomy Problem: Most “Rendering” Is Just Caching and Scheduling⌗

Framework teams market rendering modes as if they’re fundamentally different technologies. In practice, many of them differ in when HTML is produced and how it’s cached and delivered.

  • SSR typically means: render HTML on demand (per request).
  • SSG typically means: render HTML ahead of time (build time).
  • ISR typically means: render HTML ahead of time, but refresh it later on a schedule or on demand.
  • Streaming SSR means: start sending the HTML before the full page is ready.
  • Partial hydration / islands means: ship HTML for everything, but only hydrate interactive parts.

Under the hood, you’re juggling three levers:

  1. Latency to HTML (how fast the server can produce bytes)
  2. Latency to interactivity (how fast JS becomes functional)
  3. Cacheability and freshness (how often you need to redo work)

If you keep these levers in mind, the taxonomy stops being confusing and starts being useful.

The Only Metrics That Pay Rent: TTFB, TTI, and Indexability⌗

Before you choose a framework feature, decide what you’re optimizing for. For most real products, these three metrics answer the question:

1) Time to First Byte (TTFB): Do users see something quickly?⌗

TTFB is the moment the browser receives the first byte of HTML (or a meaningful payload). People don’t judge “performance” in milliseconds; they judge whether the page feels responsive.

Practical test: throttle to a slow 4G profile, load the page, and see how quickly the first paint starts. If your SSR takes too long to produce HTML, streaming or pre-rendering might be the fix.

2) Time to Interactive (TTI): Can users do anything without waiting?⌗

TTFB can be great and still feel slow if you block interactivity with heavy JS bundles or delayed hydration.

Practical test: use DevTools to inspect long tasks and the moment event handlers become active. If “interactive” arrives late, your problem is often hydration strategy, not HTML delivery.

3) Indexability: Will search engines reliably understand the content?⌗

This isn’t about being “SEO-friendly” in the abstract—it’s about whether bots can fetch and interpret the content consistently.

If your “server-side” story depends on client-side rendering for the meaningful text, you’re forcing your users (and bots) to wait for JavaScript that may not run the way you expect.

Practical rule: if a page’s value is the content itself (docs, marketing copy, product descriptions), indexability should be non-negotiable.

With these three metrics, you can evaluate any rendering approach without caring what brand of taxonomy it wears.

Static Generation (SSG): The Best Default for Rarely Changing Content⌗

When content rarely changes, static generation isn’t just a “mode”—it’s the simplest path to excellent performance and stable indexing.

Why it works⌗

  • The server isn’t doing work at request time.
  • CDN caching is straightforward.
  • HTML exists before the first user asks for it.
  • Search engines can fetch the final markup immediately.

Where to use it⌗

  • Documentation sites
  • Blog archives and evergreen guides
  • Product pages where updates are infrequent and can be deployed in batches
  • Marketing pages with a predictable release cycle

Concrete example⌗

Imagine a “How it works” page for a SaaS that updates quarterly. Rendering it as SSG means the CDN can serve the same HTML worldwide with minimal latency. Your users get fast page loads, and your search engine doesn’t need to execute application code just to see the content.

What about “but my data changes”?⌗

That’s where ISR comes in. But if the content truly changes rarely, resist the temptation to “dynamic render everything” just because you can. Complexity is a tax.

ISR and Similar Caching Strategies: Freshness Without Sacrificing Speed⌗

Incremental Static Regeneration (ISR) is often marketed as a distinct revolution. What it’s really offering is a compromise: static delivery with periodic or on-demand refresh.

The practical goal⌗

  • Keep most requests fast (served from cache or pre-rendered HTML)
  • Update content eventually so it doesn’t go stale forever
  • Avoid full SSR load spikes

Where it shines⌗

  • Content that changes more often than quarterly but not every second
    • News tickers that update multiple times daily
    • Pricing pages that update occasionally
    • Catalog pages where inventory changes are frequent but don’t need perfect “live” accuracy on every request

Concrete example⌗

A pricing comparison page might update weekly. With ISR, you ship pre-rendered HTML for immediate responsiveness, then regenerate in the background when it’s due. Users still get a fast TTFB, and the page remains indexable because it’s real HTML, not an empty shell.

The decision you should make⌗

Choose your freshness model intentionally:

  • Time-based revalidation: “Update at most every X minutes.”
  • Request-triggered regeneration: “Update when a user hits it after it’s stale.”

The marketing label matters less than how you control the staleness window—and how you prevent regeneration storms.

Streaming SSR: When Personalization and Data Fetching Dominate⌗

SSR becomes a necessity when each request’s HTML depends on personalized data or complex server-side computation. But naive SSR can be slow if you block on everything before sending bytes.

Streaming SSR solves a specific pain: it lets you start sending the response early, before the slowest data sources finish.

Why it works⌗

Instead of doing this:

  1. Fetch A, fetch B, fetch C
  2. Render the whole page
  3. Send HTML

Streaming does this:

  1. Send the shell/layout immediately
  2. Stream sections as data arrives
  3. Finish the response when the last pieces are ready

Where it shines⌗

  • Personalized dashboards where the “chrome” can render immediately, but some widgets depend on user-specific data
  • Account pages, onboarding flows, and “resume where you left off” pages
  • Pages with expensive server calls where you want the user to see progress rather than a blank screen

Concrete example⌗

A dashboard can often render:

  • navigation + page title immediately
  • “recent activity” once queried
  • “recommendations” when the recommender returns

Streaming means users see the dashboard skeleton early, improving perceived responsiveness even if total server work still takes time.

The trade-off⌗

Streaming complicates your HTML and component boundaries. Don’t adopt it because it sounds modern—adopt it because your pages can benefit from progressive section delivery.

Partial Hydration and Islands: Fixing the Interactivity Bottleneck⌗

Many teams assume “SSR means fast.” It doesn’t—at least not fully. A page can arrive quickly and still feel dead if you hydrate everything, eagerly, with a massive JS bundle.

That’s where islands and partial hydration earn their keep: you ship HTML for the whole page, but only hydrate interactive regions.

Why it works⌗

  • Static or read-only content doesn’t pay for JS.
  • Interaction is enabled only where needed.
  • Your time to interactive improves because the browser does less work.

Where it shines⌗

  • Content sites with interactive widgets:
    • search boxes
    • comment systems
    • subscribe forms
    • polls
  • Documentation or blog pages with a few islands (like code copy buttons or embedded diagrams)
  • Commerce pages where some sections require interactivity but the rest is largely static HTML

Concrete example⌗

A blog post page might have:

  • the article body (no interactivity needed)
  • a “copy code” button (small interactive island)
  • a newsletter form (interactive island)
  • a related posts carousel (interactive island)

If you hydrate the entire page as a full client app, you’re wasting time executing code that does nothing on most screens.

Practical advice⌗

Treat islands like “budgeted JavaScript.” If an island’s code grows, it should fight for its place. Measure hydration cost. Keep interactive widgets small and lazy-load them when they enter view—if your UX allows it.

What About Streaming, Resumability, and Everything Else?⌗

You don’t need to treat every new label as a new dimension of value. Most “advanced” features boil down to one of the same three outcomes:

  • Better TTFB (send bytes earlier, reduce blocking)
  • Better TTI (reduce JS, hydrate less, unblock interaction)
  • Better indexability (deliver meaningful HTML reliably)

If a “resumability” story doesn’t map to user-visible improvement—or it only helps edge cases you don’t actually have—you should be skeptical. Great engineering deserves skepticism. Marketing deserves it more.

A useful framing: ask whether the feature changes what the browser receives and when it becomes usable, not whether it sounds impressive at a conference.

Conclusion: Choose Rendering Like a Product Manager, Not Like a Theorist⌗

The rendering landscape is noisy because frameworks compete on labels, not outcomes. Your job is to pick the approach that meets user needs:

  • Use SSG for content that doesn’t change much: fast, cacheable, indexable.
  • Use ISR/caching regeneration when you need freshness without losing CDN speed.
  • Use streaming SSR when personalized or data-heavy pages can benefit from early partial delivery.
  • Use partial hydration / islands when interactivity is localized and hydrating everything would slow users down.

Stop chasing “server-side” as a badge. Chase TTFB, TTI, and indexability—and let the architecture follow.