The way a website generates HTML can have a major impact on how quickly users see content, how much JavaScript the browser must execute, how much server infrastructure is required, and how easily search engines can process the page.
For publishers, blogs, documentation sites, news websites, and content-heavy businesses, the rendering architecture is especially important because the primary product is the HTML content itself.
There are three major approaches to understand:
- Client-Side Rendering (CSR): JavaScript builds much of the page in the browser.
- Server-Side Rendering (SSR): the server generates HTML when the request arrives.
- Static Site Generation (SSG): HTML is generated ahead of time and then served as a static file.
Modern frameworks can combine these approaches on different routes or even different components. The right question is therefore not "Which architecture is universally best?"
The better question is:
For publishers, that decision can significantly affect TTFB, LCP, JavaScript cost, infrastructure requirements, caching, and search visibility.
How Client-Side Rendering Works
Compare traditional Server HTML against an empty CSR root shell
A traditional HTML page might return:
<!doctype html>
<html>
<head>
<title>Best PPC Strategies</title>
</head>
<body>
<main>
<h1>Best PPC Strategies for Small Businesses</h1>
<p>
Here are five strategies you can implement...
</p>
</main>
</body>
</html>The browser can immediately parse the document and begin rendering the content.
A basic SPA using client-side rendering may initially return something closer to:
<!doctype html>
<html>
<head>
<title>My Application</title>
</head>
<body>
<div id="root"></div>
<script src="/assets/app.js"></script>
</body>
</html>The important content isn't in the initial HTML. JavaScript must download, parse, execute, fetch application data, generate DOM elements, insert those elements into #root, and render the resulting interface.
Web.dev notes that client-side rendering can create significant performance costs because JavaScript must generate HTML/DOM on the client, and resources referenced only after JavaScript creates the markup may not be discovered as early by the browser's preload scanner.
<div id="root">Blank Screenapp.js BundleNetwork + CPU/api/articleAPI Round-TripWhy the Empty <div> Matters for Publishers
Consider a publisher's article page starting with <div id="root"></div> that then runs:
fetch("/api/article/123")
.then(response => response.json())
.then(article => {
document.querySelector("#root").innerHTML = `
<article>
<h1>${article.title}</h1>
<p>${article.content}</p>
</article>
`;
});This does not mean Google cannot process JavaScript. Modern search engines can render JavaScript. It means that relying on JavaScript to create your primary content adds complexity and additional main-thread processing to a task the browser performs efficiently when it receives HTML directly.
Use CSR Where Search Visibility Isn't Required
CSR isn't inherently bad. It is often an excellent choice for interfaces where search visibility isn't the primary requirement:
- Account dashboards
- Internal administration panels
- Analytics applications
- Project management software (
/projects,/tasks,/messages) - Logged-in user portals
The problem occurs when the same architecture is used for thousands of publicly searchable articles.
How Server-Side Rendering (SSR) Works
With SSR, the server generates HTML when the user requests the page:
<article>
<h1>Google Ads Guide</h1>
<p>
Google Ads can generate qualified traffic when campaigns
are structured around commercial search intent.
</p>
<h2>Keyword Research</h2>
<p>
Start by separating high-intent searches from informational queries.
</p>
</article>The user receives actual content rather than an empty application shell.
Evaluate SSR Advantages: Fresh Content, Personalization, and Strong Initial HTML
- Fresh Content: Useful when the response depends on real-time inventory or live pricing.
- Personalization: The server can render request-specific data (user session, currency, location).
- Strong Initial HTML: Headings, article body, internal links, metadata, and structured data arrive in the initial payload.
Account for the SSR Cost: Time to First Byte (TTFB)
SSR isn't free. Every uncached request can require application execution, database/API queries, and template rendering before the server can return the response. This can increase Time to First Byte (TTFB) unless mitigated with CDN caching, HTML caching, database caching, or streaming.
Zero database queries or template rendering required per visitor request.
How Static Site Generation (SSG) Works
Pre-generate static HTML during the build step
SSG moves rendering even earlier. Instead of generating HTML when the user requests the page, the site generates it during the build process:
dist/
├── blog/
│ ├── seo-guide/
│ │ └── index.html
│ ├── google-ads-guide/
│ │ └── index.html
│ └── technical-seo/
│ └── index.htmlWhen someone requests /blog/google-ads-guide, the CDN simply returns the already-generated HTML. This provides low server processing per request, excellent cacheability, fast CDN delivery, and immediate HTML availability.
The limitation of pure SSG is build time: for a site with millions of URLs, rebuilding every page for every edit can become slow—which is where hybrid and incremental regeneration models shine.
SSG vs. SSR vs. CSR
The fundamental difference is when the HTML gets generated:
| Architecture | HTML Generated | Initial Content | Server Work / Req | CDN Friendly | SEO-Friendly |
|---|---|---|---|---|---|
| CSR | Browser | After JS executes | Low | App shell cached | Possible, more complex |
| SSR | Request time | From server HTML | Higher | Yes, with caching | Strong |
| SSG | Build time | Static HTML | Very low | Excellent | Strong |
| Hybrid / ISR | Build / Revalidation | Usually HTML | Variable | Excellent | Strong |
The Publisher's Decision Matrix
Match each website section to the right rendering model
| Website Type | Recommended Architecture | Why |
|---|---|---|
| Blog / Documentation / Help Center | SSG | Articles change infrequently and benefit from edge CDN caching |
| Marketing Website | SSG | Predictable public pages that don't require request-time compute |
| News Publisher | SSG + Revalidation / Hybrid | Rapid publishing and updates without rebuilding the entire archive |
| E-commerce Catalog | SSG / Hybrid | Product pages generated ahead of time with periodic revalidation |
| Product Search / Checkout | SSR / CSR | Query-dependent or transactional user-specific flows |
| Personalized Dashboard / Account Area | CSR | Private, interactive UI where search indexing isn't needed |
What About Frequently Updated Content & Incremental Regeneration?
Use Incremental Static Regeneration (ISR) and isolated dynamic islands
Suppose a sports publisher has an article that updates occasionally alongside a live score widget that updates every few seconds. Avoid making the entire page dynamic just because one small component needs real-time data—serve the article HTML via SSG and update the live score component on the client.
Modern frameworks also support Incremental Static Regeneration (ISR), allowing static pages to be updated in the background after the initial build without rebuilding the entire site.
Manage Client-Side Hydration Overhead
Don't confuse SSG with "no JavaScript." An SSG page can still load scripts for interactive buttons, share widgets, or search bars.
However, full-page client-side hydration isn't free. If a massive JavaScript bundle must execute before the page becomes interactive, you can still hurt INP. Render the content early and hydrate only the interactivity that actually needs JavaScript.
How to Choose the Architecture: 5 Key Questions
Question 1: Does Google need to discover this content?
If no (dashboards, account areas), CSR is reasonable. If yes, deliver important content as HTML via SSG or SSR.
Question 2: Can the page be generated before the request?
If yes, SSG should be your first architecture to investigate.
Question 3: Does the page require request-time data?
If yes, SSR or a hybrid architecture may be appropriate.
Question 4: Does only part of the page need dynamic data?
Keep the document static HTML and isolate the small dynamic component rather than making the entire route dynamic.
Question 5: How frequently does the content change?
A page that changes once a month doesn't need per-request SSR. A page whose output changes every second requires live updates or short-TTL caching.
A Practical Architecture for a Publishing Website
Implement route-level hybrid rendering
A strong modern publishing site combines rendering strategies by route rather than forcing a single model across the entire domain:
/blog/*→ SSG/services/*→ SSG/docs/*→ SSG/about→ SSG
/product/*→ SSG + ISR/search→ SSR / CSR/live-data/*→ SSR Hybrid
/account/*→ CSR/dashboard/*→ CSR/settings/*→ CSR
Measure TTFB, LCP, and JavaScript Cost
Validate your architecture with real measurements: monitor TTFB and cache hit ratio for SSR; build duration and CDN cache hits for SSG; and JS transfer size, long tasks, LCP, and INP for CSR. Test with JavaScript disabled in Chrome DevTools to confirm your core article text is present in the initial HTML.
Avoid the 5 Common Rendering Myths
- Myth 1: "CSR is impossible to index." Google can render JS, but CSR adds unnecessary latency and complexity for public articles.
- Myth 2: "SSR is always faster." Uncached request-time rendering can increase TTFB.
- Myth 3: "SSG cannot have dynamic features." Static HTML pages can still hydrate interactive client components.
- Myth 4: "Every page needs the same rendering strategy." Per-route hybrid selection is almost always superior.
- Myth 5: "One live widget requires full-page SSR." Keep the article static and fetch the live widget separately.
Final Decision Matrix
| Requirement | SSG | SSR | CSR |
|---|---|---|---|
| Blog articles | ★★★★★ | ★★★★☆ | ★★☆☆☆ |
| Documentation & Marketing pages | ★★★★★ | ★★★★☆ | ★★☆☆☆ |
| Large content archive | ★★★★★ / Hybrid | ★★★★☆ | ★★☆☆☆ |
| Frequently changing public content | ★★★★☆ Hybrid | ★★★★★ | ★★★☆☆ |
| Personalized pages | ★★☆☆☆ | ★★★★★ | ★★★★★ |
| Real-time dashboards & Account portals | ★☆☆☆☆ | ★★★☆☆ | ★★★★★ |
| E-commerce product pages | ★★★★★ / Hybrid | ★★★★☆ | ★★☆☆☆ |
| SEO-focused public pages | ★★★★★ | ★★★★★ | ★★★☆☆ |
Conclusion
The fundamental difference between SSG, SSR, and CSR is when the HTML is produced:
For publishers, SSG is particularly powerful when content can be generated ahead of time. Static HTML can be distributed through a CDN without requiring the application server to rebuild the same article for every visitor.
The goal isn't to eliminate JavaScript or blindly choose SSG. The goal is to render the important content as early and as cheaply as the application's requirements allow.
Before choosing a framework or hosting architecture, ask one question: Does this page really need to be generated when the user requests it, or could we generate it once and serve it from the edge?