Server-Side Rendering

Explanation

In SSR, when a browser requests a URL, the server executes the application code, fetches required data, renders the complete HTML, and sends it as the response. The browser receives fully-formed HTML and displays it immediately. This is how the web originally worked, and still the right choice for many use cases. The alternative, client-side rendering (CSR), sends a minimal HTML shell with a large JavaScript bundle. The browser downloads and executes the JavaScript, which then fetches data and renders the UI. Until this completes, users see a blank page or loading spinner. On slow devices or networks, this delay directly impacts Core Web Vitals like Largest Contentful Paint (LCP). SSR advantages: faster First Contentful Paint, better SEO (content visible to crawlers without JavaScript execution), better performance on low-powered devices. Disadvantages: server must render on every request (higher server load), Time to Interactive (TTI) may still be delayed during JavaScript hydration, and server-side code has no access to browser APIs. Static Site Generation (SSG) pre-renders HTML at build time, not per-request. Pages are served as static files from a CDN — extremely fast and cheap, but content can only be as fresh as the last build. Incremental Static Regeneration (ISR, Next.js) allows static pages to be regenerated periodically. The right rendering strategy depends on whether the page content is static, user-specific, or real-time.

Code Example

// Next.js rendering strategies

// SSG: rendered once at build time (fastest, cheapest)
export async function getStaticProps() {
  const posts = await fetchAllPosts(); // runs at build time
  return { props: { posts } };
}

// SSR: rendered on every request (fresh data, more server work)
export async function getServerSideProps(context) {
  const { id } = context.params;
  const user = await fetchUser(id); // runs per-request on server
  return { props: { user } };
}

// ISR: static but revalidates every N seconds
export async function getStaticProps() {
  const data = await fetchProductData();
  return {
    props: { data },
    revalidate: 60, // regenerate if a request comes after 60s
  };
}

// CSR: fetch on the client after hydration (private/user-specific data)
function UserDashboard() {
  const { data } = useSWR('/api/dashboard', fetcher);
  if (!data) return ;
  return ;
}

Why It Matters for Engineers

SSR vs CSR vs SSG is one of the most consequential architectural decisions in web development, directly affecting SEO ranking, load performance, server costs, and development complexity. When AI generates a Next.js app with server components, understanding which rendering strategy is being used — and whether it's the right one — requires knowing SSR mechanics. Hydration bugs (mismatch between server-rendered and client-rendered HTML) are a common class of Next.js issues that are nearly impossible to debug without understanding the SSR lifecycle: the server renders with one set of data, the client hydrates with another, and React warns about mismatched content.