Web Rendering Definition: SSR, CSR, SSG, ISR Explained

What is rendering?

In web development, "rendering" means producing the final HTML that a browser displays. The same React or Vue component can be rendered on the server (SSR), in the browser (CSR), at build time (SSG), or hybrid combinations. The choice profoundly affects performance, SEO, hosting cost, and developer experience.

Modern frameworks (Next.js, Nuxt, SvelteKit, Astro, Remix) let you mix rendering strategies per route or even per component. Understanding the tradeoffs is foundational to building fast, scalable web apps.

The five main rendering strategies

Static Site Generation (SSG)

HTML is generated once at build time and served as static files from CDN.

Pros: Fastest possible delivery (just static files), cheapest hosting, no server needed at runtime, immune to traffic spikes.

Cons: Re-build needed for content updates; not suitable for highly dynamic pages.

Tools: Astro, Hugo, Jekyll, Gatsby, Next.js (output: 'export'), 11ty.

Server-Side Rendering (SSR)

HTML is generated on the server for each request.

Pros: Always fresh content; great for personalized or rapidly-changing pages; SEO-friendly.

Cons: Slower TTFB than SSG; needs a running server; expensive at scale.

Tools: Next.js (default), Nuxt, Remix, SvelteKit, Astro (with adapter), Rails+Turbo.

Client-Side Rendering (CSR)

The server returns minimal HTML; JavaScript renders the page in the browser.

Pros: Highly interactive; cheap to serve (just static JS bundle); good for app-like experiences.

Cons: Slow first paint; bad for SEO without hydration; high JS payload; poor on slow devices.

Tools: Plain React/Vue/Angular SPA, Create React App.

Incremental Static Regeneration (ISR)

Combine SSG and SSR: pages are statically generated but can be re-generated on-demand or on a schedule.

Pros: Static performance + dynamic freshness; good middle ground for e-commerce.

Cons: Complex caching; first request after invalidation may be slow.

Tools: Next.js (revalidate), Astro (with adapter), Vercel.

Edge Rendering

SSR happens at CDN edge nodes (Cloudflare Workers, Vercel Edge), close to users globally.

Pros: Low latency worldwide; geo-personalization; runs at every PoP.

Cons: Limited runtime (no Node.js APIs in some); cold starts; debugging harder.

Tools: Cloudflare Workers, Vercel Edge Functions, Netlify Edge, Deno Deploy.

Hydration: where CSR meets SSR/SSG

SSR and SSG produce HTML, but interactive components need JavaScript. Hydration is the process where the client-side JS "attaches" to the server-rendered HTML, making it interactive.

Problem: hydration is expensive — entire React tree re-runs on the client. Solutions:

• Partial hydration (Astro Islands) — only hydrate interactive components.
• Streaming SSR (React 18) — server streams HTML chunks; hydrate as they arrive.
• Progressive hydration — hydrate components based on visibility/interaction.
• Resumability (Qwik) — skip hydration entirely; serialize state.
• HTMX / server components — minimize JS by sending HTML over the wire.

Comparison: rendering strategy tradeoffs

Choosing a rendering strategy

• Marketing site, blog, docs → SSG (Astro, Next.js export, Hugo).
• E-commerce catalog → ISR (Next.js, Vercel).
• SaaS dashboard (logged-in) → CSR or SSR (no SEO need; personalization required).
• News site (frequent updates, SEO critical) → SSR or ISR.
• Geo-localized landing pages → Edge rendering.
• Small interactive widget on otherwise-static page → Astro Islands (partial hydration).

Rendering and Core Web Vitals

Rendering strategy directly affects Google's Core Web Vitals:

• LCP (Largest Contentful Paint) — best with SSG/SSR; CSR struggles because JS must download + execute.
• INP (Interaction to Next Paint) — heavy hydration tanks INP; partial hydration helps.
• CLS (Cumulative Layout Shift) — server-rendered pages are more stable; hydration can cause shifts if not careful.

Google ranking + user experience both improve with the right rendering choice.

FAQ: web rendering

SSR or SSG: which is better?

SSG if content doesn't change often. SSR if content is highly dynamic or personalized. ISR for the middle ground.

Is CSR dead?

No — still ideal for logged-in app dashboards (no SEO need, lots of interactivity). But for public/SEO pages, CSR is largely a bad choice now.

What's the difference between SSR and SSG?

Timing. SSR generates HTML per request; SSG generates HTML at build time. SSR = always fresh, slower TTFB; SSG = faster, but stale until rebuild.

What is "React Server Components"?

A React feature where some components run only on the server and never ship JS to the client. Reduces bundle size dramatically.

What about Astro Islands?

Static HTML by default; only specific "island" components ship JS and hydrate. Optimal for content-heavy sites with sparse interactivity.

How does rendering affect SEO?

Crawlers prefer pre-rendered HTML. SSG/SSR are ideal. CSR works (Googlebot runs JS) but is slower and less reliable. Use SSR/SSG for any SEO-important page.

What is the "rendering pipeline" in browsers?

How a browser turns HTML/CSS/JS into pixels: parse → DOM → CSSOM → Render Tree → Layout → Paint → Composite. Optimize by reducing reflows/repaints.

Test rendering performance with LoadFocus

LoadFocus runs Lighthouse audits from 25+ regions and load-tests dynamic pages with k6/JMeter, helping you compare SSR/SSG/CSR performance under real-world conditions. Sign up free at loadfocus.com/signup.