•
•
•
•
•
•
•
How each rendering model affects performance, SEO, cost and developer experience
Every web page must eventually become HTML in a user's browser. Where and when that HTML is produced, on a server at build time, on a server per request, or in the browser, is the rendering strategy. The choice affects speed, search visibility, hosting cost and complexity. Modern frameworks such as Next.js, Nuxt, SvelteKit, Astro and Remix let teams mix strategies per page.
How it works: The server sends a minimal HTML shell and JavaScript. The browser downloads, parses and runs the JavaScript, fetches data and builds the page.
Pros:
Cons:
Best for: Logged-in dashboards and tools where SEO is irrelevant.
How it works: On each request, the server fetches data and renders full HTML, which the browser displays immediately. JavaScript then hydrates the page to make it interactive.
Pros:
Cons:
Best for: Personalised pages, search results, frequently changing content.
How it works: Pages are rendered to HTML at build time and served from a CDN.
Pros:
Cons:
Best for: Documentation, marketing pages, blogs with infrequent updates.
How it works: Pages are generated statically but regenerated in the background after a set interval or on demand when content changes.
Pros:
Cons:
Best for: E-commerce product pages, news archives, large content sites.
Some platforms run server rendering in data centres close to users (the edge), cutting network latency. Edge runtimes may have limits on available APIs and database access patterns.
| Strategy | First load speed | Freshness | Server cost | SEO friendliness |
|---|---|---|---|---|
| CSR | Slower | Real-time | Low | Weaker |
| SSR | Fast | Real-time | Higher | Strong |
| SSG | Fastest | Build-time | Lowest | Strong |
| ISR | Very fast | Near real-time | Low | Strong |
| Streaming SSR / RSC | Fast | Real-time | Moderate | Strong |
Ask for each route:
Most real sites mix strategies: static marketing pages, ISR product pages, SSR search and CSR dashboards.
Track Core Web Vitals (LCP, INP, CLS) with real-user monitoring, not just lab tests. Watch TTFB for SSR routes and JavaScript bundle size for interactivity.
Google can render JavaScript, but rendering may be delayed and errors can hide content. Server-rendered HTML is more reliable, and other crawlers and AI bots may not execute JavaScript at all.
Not always. For private dashboards, CSR is often simpler and adequate.
The process of attaching JavaScript behaviour to server-rendered HTML so the page becomes interactive.
There is no single best rendering strategy. Match each page's needs for freshness, personalisation, interactivity and search visibility, and modern frameworks let you combine approaches for speed and scale.
