What is SSR and data flow?
Server-side rendering produces HTML on the server, with data already fetched, so the user sees content immediately; client rendering fills the page in the browser after it loads. Modern frameworks mix both, and the key decision is where each piece of data is fetched.
Why it matters
Where you render and fetch shapes performance, SEO, and complexity. Fetching on the server cuts round trips and ships content fast; fetching on the client suits interactive, user-specific data. Full-stack developers make this call constantly, and getting it right is central to a fast, correct app.
What to learn
- Server rendering versus client rendering
- React Server Components and the client boundary
- Where to fetch: server vs client
- Hydration and what can go wrong
- Streaming and progressive rendering
- Caching server-rendered data
- Avoiding waterfalls
Common pitfall
Creating request waterfalls — fetching one thing, waiting, then fetching the next based on it, in series — so the page crawls. Fetch independent data in parallel, and move fetches to the server where you can to collapse round trips. Sequential dependent fetches are a top cause of slow full-stack pages.
Resources
Primary (free):
- Next.js — Rendering · docs
- React — Server Components · docs
- web.dev — Rendering on the web · article
Practice
Build one page that fetches data on the server and renders it as HTML, and another that fetches user-specific data on the client. Identify a waterfall — two sequential fetches — and parallelize it. Done when you can justify where each fetch runs and the page has no needless waterfalls.
Outcomes
- Compare server and client rendering and choose between them.
- Decide where each piece of data is fetched.
- Reason about the server/client component boundary.
- Eliminate request waterfalls with parallel and server fetching.