FE3: Server rendering with Next.js
Where pages are rendered
🎯You'll be able to
Choose client, server, static or incremental rendering for each page, and justify it.
🏠The everyday picture
A restaurant can serve a dish cooked fresh to order, keep some ready-made on a warm counter, or give you ingredients to cook at your table. Each suits different dishes, crowds and waiting times.
📘What it really is
-
Client-side rendering (CSR): the browser downloads JavaScript, then builds the page. Simple to host; slower first view on weak phones; search engines may see less content at first.
-
Server-side rendering (SSR): the server builds the HTML for each request, so the page shows content quickly, then JavaScript makes it interactive (hydration). Good for personalised or fast-changing pages.
-
Static site generation (SSG): pages are built once at build time and served from a CDN. Very fast and cheap; content is as fresh as the last build.
-
Incremental regeneration (ISR or revalidation): static pages rebuilt in the background after a set time or on demand. A middle path for content that changes now and then.
-
Most real apps mix these per page. Ask of each page: Does it need to be found by search engines? How often does it change? Is it personal to the user? How fast must the first view be on a slow phone?
📝A worked example
Kirana Express pages and their rendering choices:
| Page | Choice | Why |
|---|---|---|
| Home and store pages | Static, revalidate every hour | Same for everyone; should be fast and searchable |
| Product pages (5,000) | Static, revalidate on price change | Searchable; prices change a few times a day |
| Search results | Server-rendered per request | Depends on the query |
| Cart and checkout | Client-rendered inside a server layout | Personal; heavy interaction |
| Order tracking | Server-rendered shell, live updates in the browser | Personal and live |
Moving product pages from client rendering to static with revalidation cut the time until the product appeared on a mid-range phone over 4G from about 3.8 s to about 1.4 s.
🌍Where it's used
- Shops and catalogues: static product pages with revalidation.
- News and blogs: static or regenerated pages.
- Dashboards behind a login: often client-rendered, since search engines don't need them.
📝Case scenario
A coaching institute's course pages are a client-rendered app, and they barely appear in search results. Moving the course pages to static generation, with revalidation when the fee or dates change, makes their content visible in the HTML. Over the next months the pages start appearing for course searches in the institute's city.
🖱️Try it
List ten pages of a site you know. For each, choose CSR, SSR, static, or static with revalidation, and write one line on why.
⚠️Common mistakes
- One rendering choice for the whole site. Sign: a static product page re-rendered on every request. Fix: choose per page by how often data changes and who sees it.
- Client-rendering content search engines need. Sign: empty HTML for product pages. Fix: render those on the server or ahead of time.
🛠️For your project
In the starter, product pages are built ahead of time (generateStaticParams), while cart and checkout run in the browser. Record why in Project 2.
✅Quick check
What is hydration?
Show the answer
JavaScript taking over server-rendered HTML in the browser so the page becomes interactive.
When does static generation with revalidation fit?
Show the answer
For pages that are the same for everyone and change occasionally, such as product pages.