Rendering Patterns

Understanding the difference between Client-Side Rendering (CSR), Server-Side Rendering (SSR), and Static Site Generation (SSG) in modern web development.

React7 min readConcept 45 of 48

Where does the HTML come from?

In standard React (like Create React App or Vite), the server sends an empty HTML file: <div id="root"></div>. The browser downloads a massive JavaScript bundle, executes it, and finally paints the UI. This is **Client-Side Rendering (CSR)**.

**Server-Side Rendering (SSR)** shifts this work to the server. When a user requests a page, the server runs the React code, fetches the database, generates the full HTML, and sends it to the browser. The user sees the UI instantly while the JavaScript loads in the background.

SEO and Perceived Performance

CSR is terrible for SEO because web crawlers often see a blank page. It's also bad for users on slow networks, as they stare at a white screen or spinner while waiting for JavaScript to download and APIs to resolve.

SSR solves both. Search engines instantly index the fully rendered HTML. Users perceive the site as lightning-fast because the UI paints immediately, even if it takes a second for the buttons to become interactive (a process called *hydration*).

The Hydration Process

When using SSR, the server sends static HTML. But HTML alone isn't interactive (you can't onClick a static button).

Once the browser paints the HTML, it then downloads the React JavaScript bundle and attaches event listeners to the existing DOM nodes. This process of 'waking up' the static HTML is called **Hydration**.

The Network Race

Watch the animated difference between Client-Side Rendering (CSR) and Server-Side Rendering (SSR). Notice where the 'heavy lifting' (fetching data and painting UI) happens in each paradigm.

// Client-Side Rendering (CSR)
// Browser downloads JS, then fetches data.
export default function Page() {
const [data, setData] = useState(null);
useEffect(() => {
fetch('/api/data').then(setData);
}, []);
if (!data) return <Spinner />; // User waits
return <div>{data}</div>;
}
// Server-Side Rendering (SSR)
// Server fetches data, sends full HTML.
export async function getServerSideProps() {
const data = await fetchDB();
return{ props: { data } };
}
export default function Page({ data }) {
// No spinner needed! Instant content.
return <div>{data}</div>;
}
Server
Empty HTML
Fetch API
JSON Data
Request JS
JS Bundle
Browser
User Viewport
Waiting for response...

Compare the network races. CSR forces the user to stare at a spinner while the browser fetches data. SSR forces the server to do the heavy lifting, delivering instant (but temporarily frozen) HTML to the user.

Check yourself

Pick an answer to lock it in, then read why. Getting one wrong is part of how it sticks.

  1. 1What is the primary difference between Client-Side Rendering (CSR) and Server-Side Rendering (SSR)?
  2. 2What is 'Hydration' in the context of SSR?
  3. 3When should you prefer Static Site Generation (SSG) over Server-Side Rendering (SSR)?

Remember this

  • CSR: Browser gets an empty div, downloads JS, fetches data, builds UI. Slow initial load, bad SEO.
  • SSR: Server fetches data, builds HTML, sends to browser. Fast initial load, great SEO, requires server computing.
  • Hydration: The process of attaching React event listeners to server-rendered HTML.
  • SSG: HTML is built once at compile time. Fastest and cheapest, but cannot handle highly dynamic user-specific data.
  • Modern frameworks (like Next.js) allow you to mix CSR, SSR, and SSG on a per-page basis.

Done with this concept?

Mark it complete to track your progress. No login needed.