Server-Side Rendering (SSR)

The server executes the application code and returns a fully rendered HTML document in response to a request. Unlike Client-Side Rendering (CSR), which sends an empty shell, SSR provides the complete Document Object Model (DOM) immediately. This eliminates the render-blocking JavaScript execution phase on the client, allowing the browser's parser to begin constructing the page without waiting for bundles to download. The result is a First Contentful Paint (FCP) measured in milliseconds, not seconds.

SSR ensures that web crawlers from Google, Bing, and other search engines receive a static, text-rich HTML snapshot. This is critical because many crawlers execute JavaScript on a secondary, delayed wave or with limited rendering budgets. By pre-rendering content, SSR guarantees that critical metadata, body text, and internal links are present in the initial HTTP response. This directly improves Core Web Vitals scores and ensures content is indexed immediately, bypassing the crawl budget constraints of JavaScript-heavy sites.

After the static HTML is displayed, the client downloads the associated JavaScript bundle. The framework then performs hydration, a process where it attaches event listeners and component state to the existing server-rendered DOM nodes. This transforms a static page into a fully interactive Single Page Application (SPA). Efficient hydration strategies, such as React 18's Selective Hydration or Qwik's Resumability, prevent the main thread from being blocked, ensuring the page remains responsive to user input during this critical phase.

Unlike Static Site Generation (SSG), SSR fetches data at request time. The server can access databases, internal APIs, and microservices directly, often over low-latency internal networks. This allows the rendered HTML to contain personalized, real-time information based on the user's session, authentication state, or geographic location. Frameworks like Next.js implement this via getServerSideProps, enabling a seamless blend of dynamic data and pre-rendered markup without exposing internal API endpoints to the public client.

Modern SSR implementations support HTTP streaming, where the server sends chunks of HTML as they are generated, rather than waiting for the entire page to render. This allows the browser to progressively display content, unblocking critical resources like CSS and fonts early. Techniques such as Suspense boundaries enable developers to define independent loading states for slower components, ensuring that a slow data fetch in one section does not block the rendering of the rest of the page.

SSR logic can be deployed to edge compute environments, executing the rendering function on a CDN node geographically close to the user. This architecture, used by platforms like Cloudflare Workers and Vercel Edge Functions, combines the benefits of SSR with the low latency of a CDN. It enables the assembly of dynamic, personalized pages from cached Content Fragments and real-time data sources at the network edge, drastically reducing the physical distance data must travel.

A build-time rendering strategy that pre-renders every page into static HTML, CSS, and JavaScript files. Unlike SSR, which generates HTML on each request, SSG creates all pages once at build time and serves them directly from a CDN.

• Zero server execution at request time
• Ideal for content that doesn't change frequently
• Frameworks: Next.js, Gatsby, Hugo, Astro
• Common pattern: SSG for marketing pages, SSR for dashboards

The process that makes SSR-delivered HTML interactive. After the browser receives the fully rendered HTML from the server, the JavaScript framework attaches event listeners and state to the existing DOM nodes. Until hydration completes, the page appears functional but buttons and forms won't respond.

• Hydration mismatch errors occur when server and client state differ
• Partial hydration and islands architecture reduce JavaScript payload
• Progressive hydration prioritizes visible components first
• Key metric: Time to Interactive (TTI)

A markup language for dynamic content assembly at the CDN edge. ESI tags instruct edge servers to fetch and compose fragments with different cache policies into a single page. This enables SSR-like personalization without hitting the origin server for every request.

• Syntax: <esi:include src='...'/> for fragment inclusion
• Supports conditional logic and error fallbacks
• Each fragment can have independent TTLs
• Used by Akamai, Varnish, and Fastly for high-traffic sites

An advanced SSR technique where the server sends HTML to the browser in chunks as it's generated, rather than waiting for the entire page to render. The browser can begin parsing and displaying content immediately while slower data fetches resolve progressively.

• Uses HTTP Transfer-Encoding: chunked
• React Suspense enables component-level streaming
• Reduces Time to First Byte (TTFB) perception
• Critical for pages with slow backend API dependencies

A rendering pattern where a page is mostly static HTML with isolated regions of interactivity called 'islands'. Each island hydrates independently, avoiding the all-or-nothing hydration of traditional SSR frameworks.

• Islands can use different frameworks on the same page
• Static content ships with zero JavaScript
• Implemented by Astro, Fresh, and Marko
• Dramatically reduces Time to Interactive for content-heavy pages