SSR vs SSG vs ISR in 2026: Choosing the Right Rendering Strategy

Two sites. Same content. Same design. One loads in 180 ms from anywhere in the world and costs $4/month to host. The other takes 1.8 seconds to first byte, chokes during traffic spikes, and bills $600/month on the same platform. The difference isn’t the framework — both were built in Next.js. It’s the rendering strategy. The SSR vs SSG decision (plus ISR, partial prerendering, and islands) is the single biggest architectural call you’ll make in 2026, and most teams still get it wrong by defaulting to whatever their framework tutorial showed first.

At TheBomb®, we’ve spent the last 12+ years migrating clients off the wrong render mode — usually SSR when SSG would’ve done, occasionally SSG when freshness mattered more than speed. Vercel’s own 2025 platform data showed that ISR-enabled pages served 85% of requests from the edge cache while still delivering sub-minute content freshness. That’s the kind of tradeoff the average “which framework is best” article refuses to quantify. This guide does.

What Are SSR, SSG, and ISR?

Server-side rendering (SSR) is the pattern where your server generates the HTML for every request, right when the request arrives. The visitor hits a URL, your server runs your code, queries your database, assembles the HTML, and sends it back. It’s always fresh — but every visitor pays the computation cost.

Static site generation (SSG) is the opposite philosophy. You pre-render every page at build time. HTML files get written to disk (or uploaded to a CDN), and when a visitor arrives, they get a static file served at the speed of physics. There’s no server doing work per request — the “server” is just a file host.

Incremental static regeneration (ISR) is the hybrid. Pages are statically generated like SSG, but they can be revalidated and rebuilt in the background after a configurable time window (say, every 60 seconds) or on-demand via a webhook. Visitors almost always get the cached static copy; stale content gets refreshed without blocking the request.

Two newer patterns matter in 2026: Partial prerendering (PPR), which lets you pre-render a page’s shell while streaming dynamic holes on request, and islands architecture (Astro, Fresh, Qwik), which ships static HTML with tiny interactive “islands” of JavaScript hydrated on demand. Both exist to solve the same underlying tension — static is fast, dynamic is flexible, and real sites need both.

When Does Static Generation Still Win?

Static generation is the default answer more often than modern framework marketing admits. If your content changes less than once per minute per page, SSG is almost certainly the right call. Marketing sites, documentation, blogs, landing pages, portfolios, changelog archives — none of these benefit from regenerating HTML on every request. They benefit from being served as pre-baked files from a CDN edge node, full stop.

The performance gap is brutal. A static HTML file served from Cloudflare’s edge network hits TTFB under 50 ms for most of the planet. An SSR-rendered page calling even a single cached database query will struggle to beat 200 ms consistently, and any cold start on serverless compute pushes that toward 800 ms. Google’s web.dev TTFB guidance recommends under 800 ms — static delivery gives you 16x headroom on that budget.

Cost is the other half. A static site hosted on Cloudflare Pages, Netlify, or Vercel’s static tier typically costs $0 to $20/month for sites serving millions of requests. The same site rendered with SSR on a serverless platform can easily hit $200 to $2,000/month once you factor in cold-start penalties, database read fan-out, and the outbound bandwidth your CDN no longer caches.

The one limitation teams overcorrect on is build time. Yes, building 50,000 pages takes longer than building 50. But with modern incremental builds in frameworks like Astro — which support content collections with typed schemas — and Next.js’s persistent build cache, a site with tens of thousands of pages rebuilds in minutes, not hours. If build time is your bottleneck, your real problem is usually ISR-shaped, not SSR-shaped.

When Does Server Rendering Actually Pay Off?

SSR earns its keep when content is genuinely per-request. Logged-in dashboards. Personalised product recommendations that depend on a user ID. Search results. Checkout flows with real-time inventory. Anything where the HTML for user A at 3:04 PM is provably different from the HTML for user B at the same moment.

The other legitimate SSR case is SEO for frequently-updated dynamic content — think auction listings, stock tickers, sports scores, or event ticketing where prices and availability must be accurate in crawlable HTML. Google can execute JavaScript, but render-blocking SEO dependencies still reward server-rendered markup with faster indexing and more reliable canonical signals.

What SSR is not good for is “I might want to change things later.” That’s a deployment-pipeline problem, not a rendering problem. Teams frequently reach for SSR because it feels more flexible, then absorb the latency tax and operational cost on every page view for years. The right test: can this page be stale for 30 seconds without anyone noticing or losing money? If yes, it doesn’t need SSR.

When SSR is the right answer, edge runtimes change the math. Cloudflare Workers runs V8 isolates with effectively zero cold starts, so the dreaded 400-800 ms first-hit penalty of traditional serverless functions collapses to single-digit milliseconds. Pair that with a globally distributed database like Turso or Neon, and SSR performance starts approaching SSG territory — at roughly 3-10x the cost.

ISR and Partial Prerendering — The Best of Both?

ISR is what most content-heavy sites actually want and didn’t know to ask for. You get the near-zero TTFB of static delivery 99% of the time, plus a controllable freshness window that keeps content reasonably current without a full redeploy. A news site with 10,000 articles can set a 60-second revalidation window and serve virtually all traffic from cache while still reflecting editor updates within a minute.

The caveat is that ISR isn’t uniformly supported. Next.js has the most mature implementation, with both time-based (revalidate: 60) and on-demand revalidation via revalidateTag and revalidatePath. Astro supports something conceptually similar through its on-demand rendering mode plus cache headers. Other frameworks either don’t support ISR at all or require you to roll your own via stale-while-revalidate HTTP semantics.

Partial prerendering (PPR) is the 2025-2026 evolution. Instead of deciding SSG-or-SSR per route, you mark individual components as dynamic within an otherwise static page. The framework pre-renders a shell — header, nav, static content — and streams in the dynamic holes (cart count, personalised “hello, Sarah”, recommended products) as they resolve. Visitors see the shell instantly and the dynamic bits populate within hundreds of milliseconds.

PPR is still maturing. It works well when the dynamic portions are genuinely small relative to the page, and badly when half the page is personalised — at which point you’ve just reinvented SSR with extra build complexity. Use PPR when the dynamic piece is a badge, a greeting, or a small widget; use SSR or client-fetched data when the dynamic piece is the whole point of the page.

Islands Architecture (Astro, Fresh, Qwik) — A Different Answer

Islands architecture reframes the question entirely. Instead of asking “should this page be static or dynamic,” it asks “which components on this page actually need to be interactive?” Most components on most pages — headers, hero images, body copy, footers — need zero JavaScript. A few — a search bar, an image carousel, a cart widget — need a little. Islands frameworks ship zero JS by default and hydrate only the interactive islands on demand.

The performance implications are dramatic. Astro’s islands architecture typically ships 90%+ less JavaScript than a React-equivalent SPA. A WIRED-style content site built in Astro can come in under 30 KB of JS total, versus 200-400 KB for the same site in Next.js app router. Smaller bundles mean faster parse, faster execute, and better Interaction to Next Paint (INP) — now a core ranking signal in the Page Experience update.

Qwik takes the idea further with resumability — the framework serializes application state into HTML so the client doesn’t have to re-execute component setup code to become interactive. Fresh (Deno’s framework) pushes islands into a small, opinionated runtime that runs on Deno Deploy edge.

The tradeoff: islands work best for content-primary sites with interactivity sprinkled in. If your product is a full SaaS dashboard with 50+ interactive components per page, islands architecture is awkward — you’ll end up hydrating so many islands that you’ve reimplemented an SPA with extra ceremony. For a marketing site, blog, docs, or e-commerce catalog, islands are often the best-in-class answer in 2026.

Cost and Complexity — The Numbers Most Guides Skip

Here’s the table most framework docs won’t show you. Real-world monthly hosting cost for a 100-page content site at roughly 500,000 monthly visits, based on 2025-2026 platform pricing we’ve billed for client work:

The complexity dimension rarely gets quantified. SSG has effectively zero operational burden — you deploy, it works, it doesn’t wake you up at 2 AM. ISR adds a cache-invalidation mental model and the occasional stale-content bug. SSR adds database connection pooling, cold-start management, timeout tuning, and error-rate monitoring. Islands are mostly simple operationally but require architectural discipline to avoid hydrating everything. PPR is the most conceptually complex today — expect to spend real time reasoning about which components are static vs dynamic.

Our rule of thumb at TheBomb®: default to SSG or islands for anything content-shaped, reach for ISR when freshness matters but real-time doesn’t, and only accept SSR when per-request personalisation is the product. Most sites that think they need SSR actually need ISR with on-demand revalidation.

Getting the Right Rendering Strategy Built

Choosing the wrong render mode is expensive — not just in hosting bills, but in every missed conversion from a 600 ms TTFB that should’ve been 60. If you’re already paying SSR prices for a site that changes three times a month, you’re on the wrong architecture.

At TheBomb®, we build and maintain sites across all five rendering strategies depending on what the business actually needs:

• Custom development — framework selection, render-mode architecture, migration from misfit stacks (WordPress to Astro, Next.js SSR to ISR, etc.)
• Ongoing maintenance — performance monitoring, Core Web Vitals tracking, render-mode tuning as traffic grows
• SEO strategy — rendering decisions that align with crawl behaviour, indexing, and Page Experience signals

Built in the Okanagan, performance-obsessed, no wasted abstractions. Let’s talk about your rendering stack — we’ll tell you straight whether you’re over-engineered, under-engineered, or on the right path.

Key Takeaways

• Default to static. SSG or islands architecture fits the majority of marketing, content, and documentation sites. Sub-80 ms TTFB, pennies in hosting, zero operational burden.
• Use ISR when freshness matters but real-time doesn’t. Blogs, news, product catalogs, and most e-commerce category pages belong here — not on SSR.
• Reserve SSR for genuinely per-request pages. Authenticated dashboards, personalised feeds, checkout, search. If you can tolerate 30 seconds of staleness, you don’t need SSR.
• Edge runtimes change the math. Cloudflare Workers and similar platforms make SSR 3-5x cheaper and 2-3x faster than traditional serverless — worth revisiting if you wrote SSR off years ago.
• Islands and PPR are the 2026 frontier. Astro, Fresh, and Qwik ship 90%+ less JavaScript than SPA frameworks. Partial prerendering splits the SSR/SSG decision per-component instead of per-route.