SSR vs SSG vs CSR: Rendering Explained Simply

These three abbreviations decide how fast your pages feel and how well Google reads them. The concept is simpler than the acronyms: it is about where the page gets assembled.

SSG: built once, served instantly

Static Site Generation pre-builds pages at deploy time into plain HTML files. Fastest possible, perfect for content that does not change per visitor: marketing pages, blogs, docs. This website works this way.

// Next.js: a page is static by default when it needs no request data
export default function AboutPage() {
  return <h1>About us</h1>
}

// Dynamic routes become static with generateStaticParams
export function generateStaticParams() {
  return posts.map((post) => ({ slug: post.slug }))
}

SSR: assembled fresh per request

Server-Side Rendering builds the page on the server each time it is requested. Right for personalized or constantly changing content: dashboards with user data, live listings, search results.

// Reading cookies, headers, or per-request data opts into SSR
export default async function OrdersPage() {
  const user = await getUserFromSession()
  const orders = await db.orders.findMany({ where: { userId: user.id } })
  return <OrderList orders={orders} />
}

CSR: assembled in the browser

Client-Side Rendering ships an empty shell plus JavaScript, and the browser builds the page. Fine behind a login where SEO does not matter, weak for public pages because crawlers may see an empty shell and users see a loading spinner first.

Which one for what

• Marketing pages, blog, docs: SSG, always
• Feeds, search, personalized pages: SSR
• Logged-in dashboard interactions: CSR on top of an SSR shell
• One Next.js app mixes all three per page, which is exactly why it became the default

Why Google cares

Crawlers reliably index what arrives as ready HTML. SSG and SSR deliver that. Pure CSR pages sometimes get indexed late or incompletely. If ranking matters, your public pages should never be client-rendered only.