--- title: Server-Side Rendering description: A rendering strategy where the server generates full HTML for every request, giving the browser a complete page to display immediately. tokens: ~616 --- # Server-Side Rendering The server executes the application code on each request, produces a complete HTML document, and sends it to the browser. The user sees content as soon as the HTML arrives — no waiting for JavaScript to build the page. After the initial paint, the browser downloads JS and **hydrates** the page: it attaches event listeners and makes the static HTML interactive. ## How It Works ``` ┌──────────┐ ┌──────────┐ │ Server │ │ Browser │ └────┬─────┘ └────┬─────┘ │←──── request ──────│ │ │ │ full HTML+ `, { headers: { "content-type": "text/html" } }, ); } ``` On the client, `hydrateRoot` reuses the existing DOM instead of recreating it: ```typescript import { hydrateRoot } from "react-dom/client"; import { App } from "./App"; hydrateRoot(document.getElementById("root")!, ); ``` SSR is a good default for pages that need fast first paint and search-engine visibility. ## Trade-offs | Strength | Weakness | | ---------------------------------------------- | -------------------------------------------------------------- | | Fast FCP — complete HTML in the first response | TTFB depends on data-fetching time; slow APIs delay everything | | Strong SEO — crawlers receive full HTML | Higher server cost — every request requires CPU to render | | Works for dynamic, per-request content | Hydration gap — page looks ready before it actually is |