Most arguments about rendering are really arguments about where work happens and when. The SSG vs SSR debate gets framed as a religious war, but the honest answer is that a serious site usually mixes strategies: static for the pages that never change, server rendering for the ones that do, and a few escape hatches for the rest. Pick per page, not per project, and most of the hard trade-offs dissolve.
This is a practitioner’s guide, not a benchmark. The goal is to give you a model for choosing a rendering strategy on purpose, so the decision is made with the design and the content rather than discovered at launch.
The five strategies, in plain terms
There are really five rendering modes worth knowing. They differ along one axis: when the HTML gets built, and where.
- SSG (Static Site Generation). Pages are rendered to HTML at build time and served as flat files. Nothing happens on the server per request. The work was done once, ahead of time.
- SSR (Server-Side Rendering). Pages are rendered on the server per request. Every visitor triggers fresh HTML generation, so the response reflects the latest data.
- ISR (Incremental Static Regeneration). A hybrid: pages are static, but the server quietly rebuilds them on a schedule or on-demand after they go stale. You get static speed with periodic freshness.
- Edge rendering. SSR moved physically closer to the user. The same per-request rendering runs in a distributed network of locations near the visitor instead of one origin region.
- CSR (Client-Side Rendering). The server ships a near-empty HTML shell and JavaScript. The browser does the rendering after the page loads. The classic single-page-app model.
Everything else (streaming, partial hydration, “islands”) is a refinement of these. Get the five straight and the rest reads as variations.
Rendering is not a project-wide setting. It’s a per-page decision about how fresh the content needs to be and who pays the cost of making it.
SSG vs SSR: the core trade-off
The SSG vs SSR question is the heart of it, so let’s make the trade-off concrete. Both produce real HTML the browser and crawlers can read. The difference is when that HTML is produced and what that timing costs you.
Where SSG wins
Static generation pre-builds everything. That has consequences that compound:
- TTFB is near-instant. You’re serving a file from a CDN edge, not waiting on a server to compute a response. Time to first byte is as low as it gets.
- Cost is trivial. No per-request compute. A static page scales to a traffic spike for the price of bandwidth.
- The attack surface shrinks. There’s no live rendering server to exploit per request, no database in the hot path.
- It is reliably fast. Performance doesn’t degrade under load, because there’s no load-bearing computation at request time.
The catch is freshness. A static page is a snapshot of the data at build time. If the content changes, the page is wrong until the next build. For a marketing page, a blog post, or documentation, that’s a non-issue: you rebuild on publish. For a price that changes hourly or a dashboard, it’s a dealbreaker.
Where SSR wins
Server rendering computes the page per request, so it’s always current. That’s its whole reason to exist.
- Freshness is guaranteed. The HTML reflects the data at the moment of the request: personalized content, live inventory, authenticated views.
- Logic lives server-side. You can gate content, run per-user logic, and keep secrets off the client cleanly.
The costs are the mirror image of SSG’s wins. TTFB is higher because the server has to do work before the first byte ships. Cost scales with traffic because every request burns compute. And complexity goes up: you now operate a rendering server, with the caching, scaling, and failure modes that implies.
The practical rule: prefer static, reach for server rendering only where the content genuinely can’t be known at build time. Most teams over-use SSR because their framework defaults to it, then spend the next year fighting cache invalidation and cold starts they didn’t need.
ISR and edge: the useful middle
The SSG-vs-SSR framing is a false binary, and the interesting strategies live between the poles.
ISR: static speed, periodic freshness
Incremental Static Regeneration serves a static page but regenerates it in the background, on a timer or when triggered by a content change. The visitor gets a cached file at static speed; behind the scenes, the page refreshes so the next visitor gets newer data.
This is the right answer for content that changes occasionally but not per request: a product catalog updated a few times a day, an article that gets edited, a listing page backed by a CMS. You keep static’s TTFB and cost profile and accept a small, bounded staleness window. The complexity is real but contained: you’re mostly reasoning about revalidation timing, not running a full per-request render.
Edge: SSR, geographically closer
Edge rendering takes per-request rendering and distributes it to locations near the user. The win is latency: a visitor in Singapore hits a node in Singapore, not your origin in Virginia. For genuinely dynamic, latency-sensitive responses (personalization, geolocation, A/B logic, auth redirects), edge cuts the round-trip dramatically.
The constraints are real, though. Edge runtimes are leaner than a full server. Cold data is still slow if your database lives in one region, so you can move the compute to the edge and still wait on a distant query. Edge shines for lightweight, request-time logic on top of cached or globally-distributed data, not as a free upgrade for every SSR page.
CSR: the narrow case
Client-side rendering still has a place, but a narrow one. It’s the right tool for highly interactive surfaces behind a login: a dashboard, an editor, an app where most of the screen is live state and SEO is irrelevant. If that app also needs to work offline or on unreliable connections, adding a service worker converts it to a PWA without changing the rendering model. For anything public-facing and content-led, CSR is usually a mistake: the crawler and the visitor both wait on JavaScript to see content that could have been HTML, which is exactly the kind of avoidable cost we cover in the real cost of a slow website.
The SEO and Core Web Vitals angle
Rendering strategy is an SEO decision, not just an engineering one, and the mechanism is straightforward: search engines and AI answer engines reward content they can read fast and reliably.
SSG, SSR, ISR, and edge all ship real HTML, so all four are crawlable out of the box. CSR is the outlier. Content rendered client-side may be indexed late or incompletely, and it almost always hurts your Largest Contentful Paint because the browser does layout work before anything meaningful appears. If you care about ranking and citation, default to a strategy that delivers HTML in the first response.
Rendering also drives Core Web Vitals directly. Static and well-cached pages start with the lowest TTFB, which gives every downstream metric room to pass. We go deep on the field-versus-lab reality in our Core Web Vitals field guide, but the headline is simple: the rendering you choose sets the ceiling on how fast the page can ever be.
There’s a quieter SEO payoff too. As discovery shifts toward AI assistants, a page that returns clean, complete HTML is easier to parse, quote, and cite. Structured, machine-legible markup matters more every year for the same reason. Fast, server-delivered HTML is the foundation that everything else sits on.
A practical decision guide
Skip the project-wide debate and decide per page. Two questions resolve almost every case.
1. How fresh does this page need to be?
- Changes on publish, same for everyone → SSG. Marketing pages, blog posts, docs, most landing pages.
- Changes occasionally, same for everyone → ISR. Catalogs, CMS-backed listings, content that’s edited but not per-request.
- Changes per request or per user → SSR, or edge if latency is critical.
- Mostly live state, behind auth, SEO irrelevant → CSR.
2. Who pays the cost, and can you afford it?
If a page is hit hard and rarely changes, static is almost free and infinitely scalable, and paying for SSR there is pure waste. If a page is genuinely dynamic, budget for the server compute and the operational complexity honestly, and confine that cost to the pages that truly need it.
A healthy site usually looks like this: the marketing and content layer is static or ISR, a handful of dynamic routes are server-rendered, latency-critical request-time logic runs at the edge, and the logged-in app is CSR or SSR. One stack, the right tool per surface. That mixed model only works when rendering is decided alongside the website information architecture, not retrofitted after the design is frozen. The structure of the site and the way it renders are the same decision viewed from two angles. If you are still deciding which frameworks and runtimes to build on, How to Choose a Web Tech Stack covers how rendering mode fits into that broader selection.
How Strynal approaches rendering
We treat rendering as an architecture decision made early, with the content and the design, never bolted on at the end. Because the senior team that scopes a build is the team that ships it, the freshness requirements and the performance budget get settled before a line of layout exists. That’s how you avoid the year-long fight with a stack that defaulted you into the wrong mode.
Every engagement starts on a blank page, so the rendering plan fits the site you actually have rather than a template’s assumptions. As the in-house studio for Global Digital Platforms, we’ve shipped enough of these to know where static ends and where server or edge starts earning its keep, and that judgment is the spine of our websites and apps practice.
If you’re not sure whether your site should be static, server-rendered, or a deliberate mix, that’s a good first conversation. Tell us how your content changes, and we’ll map the rendering to it honestly, including the parts where the simpler answer is also the faster one.