Detailed explanation
Client-side rendering (CSR) and server-side rendering (SSR) differ in where the initial UI markup is generated. In a typical CSR React application, the server returns a minimal HTML document, such as <div id="root"></div>, plus JavaScript references. The browser downloads and executes JavaScript, React renders the components, and the browser displays their output. If the page also needs API data, users may see a loading state until those requests finish. CSR suits highly interactive applications, especially private dashboards where search indexing is not a priority.
With SSR, the server renders React components into HTML for the initial request. For example, /courses can return course headings and descriptions directly in the response instead of waiting for browser-side rendering. The browser can display this content before React's JavaScript finishes loading. React then hydrates the existing HTML, connecting component logic and event handlers so the page becomes interactive. In conventional React SSR, the initial client render must match the server output; differences caused by random values, timestamps, or browser-only checks can cause hydration mismatches.
The performance difference is a trade-off, not a guarantee that SSR is always faster. SSR can improve how quickly meaningful content appears, particularly on slower devices, but server rendering and data fetching can increase response time. It also consumes server resources, and hydration still requires browser work and JavaScript. CSR can delay meaningful content while scripts and data load, although caching, code splitting, and efficient data fetching reduce that delay. SSR also supports streaming, allowing parts of the page to arrive progressively rather than waiting for everything.
SSR generally makes content easier for crawlers and link-preview tools to discover because it is present in the HTML response. However, saying all crawlers see CSR as an empty page is inaccurate: some execute JavaScript, with varying limitations. Interviewers expect you to distinguish visible content from interactivity and explain when each approach fits. Rendering can also be hybrid: a React framework may server-render the first request and use client-side navigation afterward.
Key points to remember
- CSR generates initial UI markup in the browser; SSR generates it on the server.
- SSR can show meaningful content earlier, but hydration is needed for React-managed interactions.
- CSR performance depends heavily on JavaScript loading, execution, and client-side data fetching.
- SSR improves content accessibility for crawlers but adds server work and can increase response latency.
- Choose per route: public content often benefits from SSR, while private interactive screens may suit CSR.
Common mistakes candidates make
- Claiming CSR cannot be indexed or SSR guarantees better search rankings.
- Assuming server-rendered HTML is immediately fully interactive or requires no client JavaScript.
- Saying SSR is always faster without considering server latency, caching, bundle size, and hydration costs.
Likely follow-up questions
What is hydration in React?
Hydration lets React take control of HTML that was already generated on the server, using hydrateRoot in a typical React setup. React expects matching initial output and connects the UI to its client-side behaviour rather than creating the entire page from scratch.
How is SSR different from static site generation?
SSR generates HTML when a request is handled, although responses may be cached. Static site generation produces HTML ahead of requests, usually during a build, making it easy to serve through a CDN but requiring a regeneration strategy when content changes.
Are React Server Components the same as SSR?
No: SSR concerns generating HTML on the server, while Server Components concern where components execute and which component code reaches the browser. They can be used together; Server Components do not hydrate themselves, while Client Components in a server-rendered page can hydrate.
Interview tip: Explain the request-to-render flow for both approaches, distinguish visibility from interactivity, and finish with a practical route-level trade-off.