How does SSG differ from SSR and CSR?

Question

Accepted Answer

SSG (Static Site Generation), SSR (Server-Side Rendering), and CSR (Client-Side Rendering) represent three fundamental approaches to rendering web applications. They differ primarily in **when** and **where** the page HTML is generated. SSG generates HTML at build time, SSR generates it on each request on the server, and CSR generates it in the browser after JavaScript loads. Each approach has distinct implications for performance, SEO, user experience, and development complexity. **SSG (Static Site Generation):** HTML generated at build time, served as static files. Fastest performance, best SEO, but content can become stale without rebuilds. **SSR (Server-Side Rendering):** HTML generated per request on the server. Fresh data every time, good SEO, but slower response times and more server load. **CSR (Client-Side Rendering):** HTML generated in browser using JavaScript. Dynamic and interactive, but slower initial load and poor SEO without additional techniques. // app/blog/[slug]/page.tsx // SSG: Generated at build time export async function generateStaticParams() { // Runs at build time only const posts = await fetch('https://api.example.com/posts') .then(res => res.json()); return posts.map((post) => ({ slug: post.slug })); } export default async function BlogPost({ params }: { params: { slug: string } }) { // This fetch runs at build time (or revalidation time with ISR) const post = await fetch(`https://api.example.com/posts/${params.slug}`) .then(res => res.json()); return (

{post.title}

{post.content}

Published: {post.date}

); } // Characteristics: // ✓ Fastest Time to First Byte (TTFB) // ✓ Can be served from CDN edge // ✓ SEO friendly (full HTML at load) // ✗ Content may be stale until rebuild // ✗ Not suitable for user-specific data // app/profile/[id]/page.tsx // SSR: Rendered on each request export const dynamic = 'force-dynamic'; // Forces SSR // or simply omit generateStaticParams export default async function ProfilePage({ params }: { params: { id: string } }) { // This fetch runs on EVERY request const profile = await fetch(`https://api.example.com/profiles/${params.id}`, { // No 'next: { revalidate }' means no caching = SSR cache: 'no-store' }).then(res => res.json()); if (!profile) { return notFound(); } return (

{profile.name}

Member since: {profile.joinDate}

{profile.bio}

{/* Real-time data always fresh */}

Current status: {profile.status}

); } // Characteristics: // ✓ Always fresh data // ✓ SEO friendly (full HTML at load) // ✓ Works with user-specific content // ✗ Slower than SSG (server processing per request) // ✗ Higher server load and cost // ✗ Cannot be cached at CDN edge // app/dashboard/page.tsx (Server Component) // CSR: Initial shell from server, data fetched in browser export default function DashboardPage() { return (

Dashboard

{/* Data fetched in browser */}

); } // app/dashboard/ClientDashboard.tsx (Client Component) 'use client'; import { useState, useEffect } from 'react'; export default function ClientDashboard() { const [data, setData] = useState(null); const [loading, setLoading] = useState(true); useEffect(() => { // Fetch runs in browser after page loads fetch('/api/dashboard-data') .then(res => res.json()) .then(data => { setData(data); setLoading(false); }); }, []); if (loading) return

Loading dashboard...

; return (

Welcome back, {data.user.name}!

Your stats: {data.stats.views} views today

{/* Highly interactive components */}

); } // Characteristics: // ✓ Highly interactive after load // ✓ Reduced server load // ✓ Great for authenticated/user-specific content // ✗ Poor SEO (initial HTML is empty) // ✗ Slower initial visible content // ✗ JavaScript-dependent Choose SSG when: Content is public, changes infrequently, and performance is critical. Examples: blogs, documentation, marketing pages, product catalogs with ISR. Choose SSR when: Data changes per request, needs to be fresh for every visit, and SEO is important. Examples: user profiles, real-time dashboards, personalized content. Choose CSR when: The page is behind authentication, highly interactive, or SEO isn't a concern. Examples: admin panels, complex data visualizations, social media feeds. Note: Modern frameworks like Next.js allow mixing approaches - static shell with client-side data fetching for the best of both worlds. // app/products/[id]/page.tsx // Hybrid: Static core with client-side dynamic data // SSG for static product information export async function generateStaticParams() { const pr

How does SSG differ from SSR and CSR?

SSG pre-renders pages at build time, SSR renders on each request, and CSR renders in the browser, each with different trade-offs for performance, SEO, and data freshness

How does SSG differ from SSR and CSR?

SSG pre-renders pages at build time, SSR renders on each request, and CSR renders in the browser, each with different trade-offs for performance, SEO, and data freshness

Scenario Questions

Follow-up Questions