Rendering Strategies Interview Questions
With Answers & Code Examples

These are four strategies for deciding where and when HTML is produced.

CSR (Client-Side Rendering) — the server sends a bare HTML shell; JavaScript downloads and renders everything in the browser. Fast TTFB, slow FCP, poor SEO.

SSR (Server-Side Rendering) — HTML is generated on the server per request. Good SEO and fast FCP but higher TTFB under load; server must run Node.

SSG (Static Site Generation) — HTML is generated once at build time and served as a static file from a CDN. Fastest possible delivery; stale for frequently changing data.

ISR (Incremental Static Regeneration) — SSG pages are regenerated in the background after a revalidate interval (Next.js). First visitor after expiry may see stale content while rebuild happens.

// Next.js ISR example
export async function getStaticProps() {
  const data = await fetchData();
  return {
    props: { data },
    revalidate: 60, // regenerate at most once per 60s
  };
}

Choose SSR over SSG when:

• Content is per-user — a dashboard, cart, or profile page. SSG can't encode user-specific data at build time.
• Data changes very frequently — live scores, stock prices, breaking news. ISR revalidation windows would always show stale content.
• SEO matters AND content is real-time — SSR delivers fresh HTML to crawlers without client-side rendering delay.
• You need request-time context — cookies, headers, geolocation, A/B test assignments available only at request time.

Trade-offs of choosing SSR:

• Higher server cost — every request spins up rendering work.
• Higher TTFB vs CDN-cached static files.
• Must manage server scaling and cold starts.

Streaming SSR uses HTTP chunked transfer encoding to flush HTML to the browser incrementally rather than waiting for the entire page to render server-side.

How it works (React 18 + Next.js App Router):

1. Server sends the HTML shell immediately (nav, layout, static content).
2. Slow data-fetching components are wrapped in <Suspense> with a fallback (skeleton).
3. As each suspended boundary resolves, React streams the HTML chunk followed by an inline <script> that replaces the placeholder.

// app/page.tsx
export default function Page() {
  return (
    <Layout>
      <HeroBanner /> {/* static, streams immediately */}
      <Suspense fallback={<Skeleton />}>
        <RecommendationFeed /> {/* slow DB query, streams when ready */}
      </Suspense>
    </Layout>
  );
}

Performance benefit: TTFB is fast (shell), FCP is fast (visible content), and Time to Interactive is not blocked by the slowest data fetch on the page.

Hydration is the process where React takes server-rendered HTML already in the DOM and attaches event listeners + React fiber state to it without re-rendering the whole tree from scratch.

Why mismatches happen: React compares the server HTML with what the client render would produce. If they differ, React throws a hydration error and falls back to a full client re-render (slow and potentially visually jarring).

Common mismatch causes:

• Date.now() or Math.random() used during render — different values server vs client.
• Accessing window, localStorage, or navigator during SSR — they don't exist server-side.
• Browser extensions injecting DOM nodes (ads, dark-mode extensions).
• Incorrect HTML nesting (e.g., <p> inside <p>) that browsers auto-correct differently.
• Locale-dependent formatting (dates, numbers) where server and client timezones differ.

// Fix: defer browser-only code
const [mounted, setMounted] = useState(false);
useEffect(() => setMounted(true), []);
if (!mounted) return null; // renders same as server

Islands architecture (Astro, Fresh, Marko) treats a page as mostly static HTML with isolated "islands" of interactivity that hydrate independently.

Traditional SSR problem: Even if 90% of the page is static text, the entire component tree must hydrate — downloading and parsing all JavaScript just to make a nav dropdown work.

Islands approach:

• Static sections are pure HTML — zero JS shipped for them.
• Interactive widgets (carousel, form, modal) are explicit islands — each hydrates independently with only its own JS bundle.
• Result: drastically smaller Total Blocking Time and better INP.

// Astro syntax
---
import Counter from './Counter.tsx'; // React component
---
<main>
  <h1>Static content — no JS</h1>
  <Counter client:load />  {/* hydrates this island only */}
</main>

React Server Components push the same idea into React itself — server components render to HTML, client components hydrate selectively.

CSR SEO concerns:

• Googlebot does render JavaScript but via a second wave deferred by days or weeks — content may not be indexed promptly.
• Other crawlers (Bing, social previews, Slack unfurls) do not execute JavaScript — they see an empty shell.
• Meta tags for OG / Twitter cards are missing on CSR pages without SSR or a pre-rendering service.

SSR / SSG advantages:

• Full HTML is available on first byte — crawlers index it immediately.
• Title, description, canonical, structured data are all present in the initial response.
• Faster TTFB and FCP improve Google's page experience signals (LCP, CLS).

Mitigation options for CSR:

• Use a pre-rendering service (Prerender.io) for non-Google crawlers.
• Dynamic rendering — detect crawler user-agents and serve SSR HTML.
• Migrate high-priority landing pages to SSR or SSG.