Server-Side Rendering (SSR)
The process of rendering a web page on the server and sending the fully constructed HTML to the client.
Detailed Explanation
In SSR, the server handles the initial rendering logic and data fetching, delivering a complete HTML page to the browser. This results in faster 'First Contentful Paint' (FCP) and is highly beneficial for SEO, as search engine crawlers can easily parse the content without needing to execute complex JavaScript. Modern frameworks like Next.js have popularized SSR by combining it with client-side interactivity.
Quick Summary
SSR generates the page HTML on the server for every request, sends a complete document to the browser, and then hydrates it with JavaScript. It trades server CPU for faster perceived load, better SEO, and meaningful content for users on slow networks.
Key Takeaways
- SSR returns ready-to-paint HTML, so users see content before any JavaScript executes.
- It improves Core Web Vitals (LCP, FCP) and is preferred by search crawlers that do not run JS reliably.
- Every request costs server CPU and memory, caching (CDN, ISR) is what makes SSR economical at scale.
- After paint, JavaScript still runs to attach event handlers; this step is called hydration.
- SSR is distinct from SSG (built once at deploy) and ISR (regenerated on a schedule).
When to use it
- E-commerce product pages and marketing sites where SEO and time-to-content are revenue-critical.
- Personalised dashboards where content depends on the signed-in user and cannot be pre-built.
- News and blog sites that need fresh content indexed and visible immediately.
- Apps targeting low-powered devices or slow networks where shipping a large JS bundle delays interactivity.
Common Mistakes
- Calling browser-only APIs (window, localStorage) on the server, causing build or runtime errors.
- Forgetting that data fetched at render time leaks into the HTML, never inline secrets into rendered pages.
- Skipping caching and paying full server cost for every visit, especially under traffic spikes.
- Producing different markup on server and client, which causes hydration mismatches that flash or break UI.
Server-Side Rendering (SSR), Frequently Asked
Is SSR better than CSR for SEO?
Generally yes. Search engines can index SSR output reliably without executing JavaScript. CSR works for SEO too, but indexing is delayed and inconsistent across crawlers, especially smaller ones.
What is the difference between SSR and SSG?
SSR renders the HTML per request at runtime. SSG (static site generation) renders once at build time and serves the same file to everyone. SSG is faster and cheaper; SSR is required when content is per-user or changes per request.
Does SSR remove the need for client-side JavaScript?
No. The server delivers the initial HTML, but interactivity (clicks, navigation, state) still needs JavaScript loaded and hydrated in the browser.