🏗️ Rendering Strategies - SSR, SSG, & ISR

Don’t ask “which framework is best?” Ask “When does the HTML get generated?” A Programmer chooses the strategy that minimizes the work the user’s browser has to do, balanced against how frequently the data changes.

🌎 1. SSR (Server-Side Rendering)

The server generates the full HTML for every request.

Frameworks: Next.js (getServerSideProps), Nuxt (useAsyncData), Remix (Loaders).
Pros: Dynamic data is always fresh; excellent for SEO; fast “First Contentful Paint” (FCP).
Cons: Higher server load; slower “Time to First Byte” (TTByte) compared to static files.
The “Hydration” Cost: After the HTML arrives, the browser still has to download and execute JS to make the page interactive.

🧊 2. SSG (Static Site Generation)

The HTML is generated once at build time and served as static files via a CDN.

Frameworks: Next.js (getStaticProps), Nuxt (Static target), Astro.
Pros: Extreme performance (serving raw HTML from a CDN edge); zero server cost at runtime; highly secure.
Cons: Build times can explode if you have 100k+ pages; data is “stale” until the next build.

♻️ 3. ISR (Incremental Static Regeneration)

The “Holy Grail” for large-scale sites. It allows you to update static pages after you’ve built the site, without needing a full rebuild.

How it works: You serve a static page. After a background timeout (revalidate period), the next request triggers a rebuild of just that specific page in the background.
Use Case: An e-commerce site with 50,000 products. You don’t want to build all 50k pages every time, but you want price updates to reflect within 60 seconds.

⚖️ Strategic Comparison: Next.js vs. Nuxt vs. Remix

Feature	Next.js (React)	Nuxt (Vue)	Remix (React)
Philosophy	”The Vercel Way”: Optimized for DX and edge deployment.	”The Vue Way”: Highly modular and developer-friendly.	”The Web Standards Way”: Focus on native browser APIs (Forms, Fetch).
Data Fetching	Server Components (RSC) & Actions.	Auto-imported composables & integrated Nitro server.	Loaders and Actions (focused on mutations).
Caching	Aggressive, complex caching built into the router.	Flexible caching per route or component.	Relies heavily on HTTP Cache headers.
Best For	Large-scale enterprise & e-commerce.	Vue-based ecosystems & rapid prototyping.	Data-heavy dashboards & form-heavy apps.

🧠 Architectural Concepts

1. React Server Components (RSC)

This is a paradigm shift. Unlike traditional SSR, RSCs never send JavaScript to the client.

Programmer’s Move: Use RSCs for the heavy lifting (fetching data from a DB, heavy markdown parsing) and only use “Client Components” for interactivity (buttons, forms). This drastically reduces your JS bundle size.

2. Edge Rendering

Running your SSR logic on CDN nodes (like Cloudflare Workers or Vercel Edge) instead of a central server.

Benefit: Reduces the physical distance between the server and the user, bringing SSR speeds closer to SSG speeds.

3. The Waterfall Problem

In many SSR apps, Component A waits for data, then renders Component B, which then fetches its own data.

Solution: Use Parallel Data Fetching (fetching all data at the top level) or Streaming SSR (sending parts of the UI to the client as they become ready using <Suspense>).

💡 Note: Beware of “Over-hydration.” If you have a static blog post with a single “Like” button, don’t ship 200kb of React just to make that button work. Consider “Islands Architecture” (Astro) or “Resumability” (Qwik) to keep the client-side JS near zero.