Day 67: Trade-offs Analysis: Client-side vs Server-side Rendering
Build a crisp, defensible framework for the "CSR vs SSR" question that goes beyond "SSR is better for SEO" into real product/business tradeoffs.
Study
Concepts
Reframe the question around WHO the page is for
The strongest answer to "CSR vs SSR" starts from the audience and purpose of the specific route, not a blanket rule: a public marketing/product page needs to be crawlable and fast on first load for anonymous visitors who may never return — SSR or SSG (Day 29) wins here. An authenticated, highly interactive dashboard has no SEO need at all, is visited repeatedly by a returning user (so a cached JS bundle after first load is cheap), and benefits more from CSR's simpler infrastructure (a static bundle, no server rendering compute) and richer client-side interactivity.
The real cost SSR introduces that is easy to underweight: server compute cost that scales with TRAFFIC (unlike a static CDN-served bundle), infrastructure complexity (a Node/Deno runtime to operate, scale, and monitor, rather than "just" static file hosting), and the hydration-mismatch failure class (Day 29) that CSR-only apps never encounter at all.
A decision framework you can state in one breath
State three questions and how each biases the choice: "Does this page need to be crawlable/shareable with a rich preview?" (yes → SSR/SSG) — "Is content the same for every visitor, or per-user?" (same → SSG/ISR; per-user real-time → SSR) — "Is the user likely to navigate to many pages in one session, or land on exactly one?" (many → CSR's upfront-bundle-then-cheap-navigation model wins; one → SSR/SSG's fast-first-paint wins). This is a much stronger interview answer than a memorized rule, because it demonstrates you reason from product requirements to architecture, exactly what Day 66 says interviewers are testing for.
See It
Visualizations
Visualization
When each rendering strategy wins
| SSR / SSG leans right | CSR leans right | |
|---|---|---|
| Needs to be crawlable / shareable (OG previews) | ✓ | |
| Same content for every visitor | ✓ (SSG/ISR) | |
| Per-user, highly personalized, real-time | ✓ (SSR) | ✓ (also viable) |
| User navigates many pages in one session | ✓ — cached bundle, cheap client nav | |
| Simple static hosting preferred | ✓ — no server compute needed | |
| Rich, app-like interactivity is the core value | ✓ |
Build It
Code Examples
The same product, two routes, two deliberate strategies
// app/products/[slug]/page.tsx — public, SEO-critical, same for every visitor
// -> SSG/ISR: crawlable, fast, cheap to serve, revalidated periodically.
export const revalidate = 3600;
export default async function ProductPage({ params }) {
const product = await getProduct(params.slug);
return <ProductDetail product={product} />;
}
// app/dashboard/page.tsx — authenticated, per-user, repeat visits, highly interactive
// -> CSR: no SEO need, bundle is cached after first visit, richest interactivity.
'use client';
export default function Dashboard() {
const { data } = useQuery({ queryKey: ['dashboard'], queryFn: fetchDashboardData });
return <DashboardView data={data} />;
}Remember
Key Takeaways
- Frame the decision around the SPECIFIC route's audience and purpose, not a blanket "SSR is better" rule.
- SSR/SSG wins for crawlable, shared, mostly-uniform content viewed by mostly-new visitors.
- CSR wins for authenticated, highly interactive, repeat-visit experiences where SEO is irrelevant.
- SSR introduces real, easy-to-underweight costs: per-request server compute, infra complexity, and hydration-mismatch risk.
- A three-question decision framework (crawlable? per-user? single-page-or-many-page session?) is a stronger interview answer than a memorized rule.
Do It
Practice
- 1Classify 5 real routes from a product you use daily (home, product page, checkout, dashboard, settings) by which rendering strategy they likely use, and justify each.
- 2Write a one-paragraph answer to "would you SSR our entire app for consistency" and argue against it using the cost side of the tradeoff.
- 3Pick a route in this portfolio site and justify (in writing) whether it should be SSG, ISR, SSR, or CSR if rebuilt in Next.js.