web dev//rendering

Rendering is the process of building the HTML of a web page, and where and when it happens is the single most important architectural decision for a web app, because it determines what crawlers see, how fast the page loads and how much JS the browser needs.

Rendering is the process of building the HTML of a web page, and where and when it happens is the single most important architectural decision for a web app, because it determines what crawlers see, how fast the page loads and how much JS the browser needs.

In client-side rendering (CSR) the server sends an empty <div id="root"></div> and a JS bundle, and the browser executes the JS, builds the DOM and fills the page. Until the JS runs there is no content. React SPAs and Notion work this way, and most crawlers and tools like WebFetch cannot read them, because they do not execute JS and see an empty shell; that is why the rendering model matters for SEO.

In server-side rendering (SSR) the server builds the HTML on every request and sends it ready-made, so the browser paints it immediately and JS hydrates the page afterwards (adds interactivity). Next.js with SSR does this. In static site generation (SSG) the HTML is pre-built at build time, with no server needed per request: the result is static files served from a CDN, the fastest possible load. Astro does this by default.

The three form a spectrum, from CSR (all in the browser, no content without JS) through SSR (a server per request, content ready) to SSG (pre-built, content baked in). Astro defaults to SSG, Next.js supports all three, and pure React with Vite is CSR. Each point has its own note: CSR (the browser builds the page), SSR (the house arrives assembled) and hydration (JavaScript connects the buttons afterwards), with SSG for the build-time end, plus SPA and its opposite MPA, which are about navigation rather than rendering, and DOM, the difference between the HTML that arrived and the page that exists.