SSR definition
Server-Side Rendering (SSR) is a technique where the server generates the full HTML for a page on each request and sends it to the browser, instead of the browser building the page with JavaScript. Users see content sooner and search engines can read it immediately, then JavaScript hydrates the page to make it interactive.
How does server-side rendering work?
When a request arrives, the server runs the page's component code, fetches the data it needs, and produces a complete HTML document. The browser can paint that HTML immediately. In parallel, it downloads the JavaScript for the same components and runs a step called hydration, which attaches event handlers to the existing markup so buttons and forms work. Frameworks that handle this include Next.js, Nuxt, SvelteKit, React Router (formerly Remix), Angular SSR and Astro for its interactive islands.
SSR vs CSR vs SSG
The three rendering strategies differ in when and where HTML is produced. Most modern frameworks let you choose per route, which is usually the right answer. Choosing well per route can cut hosting costs and improve both search visibility and perceived speed.
- Client-side rendering (CSR): HTML is built in the browser, good for logged-in apps
- Server-side rendering (SSR): HTML is built per request, good for personalized or fast-changing pages
- Static site generation (SSG): HTML is built once at deploy time, best for content that rarely changes
- Incremental regeneration: static pages refreshed in the background on a schedule or trigger
- Streaming SSR: the server sends HTML in chunks so the page shell appears before slow data finishes
- Edge rendering: SSR run on CDN edge servers close to the user for lower latency
Benefits and limitations of SSR
SSR improves first contentful paint and Largest Contentful Paint on slow devices, gives crawlers and link previews complete HTML, and keeps secrets such as API keys on the server. The costs are real: every request uses server compute, slow database queries directly delay the page, and caching becomes harder for personalized content. Hydration can also cause a window where the page looks ready but does not respond to taps, which hurts Interaction to Next Paint.
Example: an ecommerce product page
A product page needs to rank in search, show the current price and stock, and load quickly on a phone. With SSR, the server fetches the product, price and stock, renders HTML and sends it. The description and images can be cached at the CDN for a few minutes, while the stock badge streams in separately so a slow inventory service never blocks the rest of the page.
Reviews and recommendations, which are not needed for the first view, load on the client after hydration. This split gives search engines complete product content, gives shoppers a fast first paint, and keeps server work proportional to what genuinely needs to be fresh on every request.
When to use server-side rendering
Use SSR for pages that need fresh or user-specific data and also need to rank or load quickly, such as product pages with live stock, search results, news and listings. If content changes rarely, static generation with a CDN is cheaper and faster. Nexzem builds Next.js sites that combine static, server-rendered and client-rendered routes, picking the cheapest strategy that still meets freshness and SEO needs for each page.