M Saad Ahmad

Posted on Feb 4

Rendering 101: The Foundation of Modern Frontend Architecture

#webdev #architecture #programming #learning

Rendering is the backbone of how the modern web works. Every webpage — whether a static blog, a dynamic dashboard, or an e-commerce product page—ultimately has one job: convert code into pixels the user can see and interact with. Yet despite being such a fundamental concept, the web today contains multiple rendering strategies, each with different performance characteristics, trade-offs, and architectural implications.

If you’ve ever wondered why one site loads instantly while another shows a spinner for five seconds, the answer is often hidden in how the app is rendered.

In this guide, we’ll break down rendering from the ground up:

What rendering actually is
All major rendering types
Deep dives into CSR, SSR, SSG, ISR, and Hydration
Pros, cons, and real-world use cases

Let’s start with the basics.

What Is Rendering?

At its core, rendering is the process of turning your application’s code (HTML, CSS, JavaScript, data) into the actual UI that appears in the browser.

Rendering answers two questions:

Where does the HTML get generated?
- In the browser?
- On the server?
- During a build step?
When is the HTML generated?
- Before the user requests a page?
- At the time of the request?
- Only once and cached?
- Dynamically regenerated later?

Different answers create different rendering strategies.

Types of Rendering Explained

Modern frontend frameworks use these rendering strategies:

CSR — Client-Side Rendering
SSR — Server-Side Rendering
SSG — Static Site Generation
ISR — Incremental Static Regeneration

and most rely on a process called Hydration to add interactivity to pre-rendered HTML. Let's break each down in depth.

1. Client-Side Rendering (CSR)

What is CSR?

Client-Side Rendering means the browser receives a minimal HTML shell and loads JavaScript that handles rendering the entire UI.

Think SPA frameworks: React, Vue, Angular, Svelte (when used client-only).

How CSR works under the hood

Browser loads an almost-empty HTML page.
JS bundle downloads.
Framework executes on the client.
UI gets rendered after JS evaluation.
App becomes interactive once the JS framework renders the UI.

This is why CSR often shows a blank screen or loader initially.

Pros of CSR

Great for highly interactive, app-like experiences
Reduces load on the server
Smooth client-side navigation (SPA behavior)
Easy to maintain stateful UIs

Cons of CSR

Slow Time-to-First-Byte (TTFB) and Time-to-Interactive (TTI)
Heavy JavaScript bundles
Potential SEO limitations
Poor performance on low-end devices or slow networks

Real-World Use Cases

Dashboards
Admin panels
SaaS applications
Social media UIs

Frameworks that rely on CSR

React (CSR mode)
Vue (CSR mode)
Angular
Create React App
Vite + React/Vue (default client mode)

2. Server-Side Rendering (SSR)

What is SSR?

Server-Side Rendering means the server generates the HTML for each request and sends a fully rendered page to the browser.

This is how traditional websites used to work—PHP, Rails, Django — and how modern frameworks like Next.js handle dynamic pages.

How SSR works under the hood

User requests a page.
Server fetches data.
Server renders HTML for that page.
Browser receives fully-rendered HTML.
JS bundle loads and hydrates the UI.

Pros of SSR

Fast initial page load (better LCP)
SEO-friendly (search bots receive full HTML)
Easy to serve dynamic content
Great for pages with personalized data

Cons of SSR

Higher server load
Slower under high traffic
Requires hydration, which still loads JS
Can be expensive at scale

Real-World Use Cases

E-commerce product pages
News sites
Marketplace listings
Authenticated content

Frameworks that rely on SSR

Next.js (pages or app router SSR)
Nuxt.js
Remix (partially SSR)
SvelteKit

3. Static Site Generation (SSG)

What is SSG?

Static Site Generation builds HTML pages at compile time, not at request time. These HTML files are then served directly from a CDN.

How SSG works under the hood

During build time, framework runs data-fetching.
All pages are rendered into static HTML files.
Hosting platform deploys these files to CDN.
Browser accesses already-rendered HTML.

Pros of SSG

Fastest load speeds (CDN-delivered HTML)
Zero server cost
Great for content that rarely changes
Strong SEO performance

Cons of SSG

Build times grow with more pages
Not ideal for frequently changing data
No per-request personalization without client-side JS

Real-World Use Cases

Marketing sites
Blogs
Documentation
Portfolio websites

Frameworks that rely on SSG

Astro
11ty
Hugo
Gatsby
Next.js (using getStaticProps)

4. Incremental Static Regeneration (ISR)

What is ISR?

Incremental Static Regeneration is a hybrid model introduced by Next.js that mixes the benefits of SSG and SSR.

Pages are statically generated once, and then selectively regenerated in the background when their “revalidation time” expires.

How ISR works under the hood

Build generates static pages.
User requests the page → served instantly from the cache.
If the cached version is older than revalidate time:
- The server regenerates it in the background.
- New version gets cached automatically.

Pros of ISR

Instant load from cache
Fresh content without full rebuilds
Low server cost
Ideal for large websites

Cons of ISR

Content can be slightly stale
Complexity increases with dynamic content
Requires hosting that supports ISR (Vercel, Netlify)

Real-World Use Cases

Blog posts that update periodically
Catalog pages
News articles
Documentation with periodic updates

Frameworks that rely on ISR

Next.js (built-in)
Gatsby Cloud (similar concepts)

5. Hydration

What is Hydration?

Hydration is the process of attaching JavaScript behavior to already rendered HTML so it becomes interactive.

SSG, SSR, and ISR all depend on hydration to turn a static HTML shell into a working application.

How Hydration works under the hood

Browser receives static HTML.
JS bundle downloads.
Framework “replays” the component tree.
Interactive event listeners are attached.
Page becomes fully usable.

Pros of Hydration

Best of both worlds: fast initial HTML + interactivity
Works with modern frameworks
Great for SEO + user experience

Cons of Hydration

Requires shipping JavaScript
Duplicate work: HTML rendered twice (server + browser)
Can cause hydration mismatch errors
Slows down Time-to-Interactive (TTI)

Real-World Use Cases

All SSR, SSG, and ISR frameworks rely on hydration.

Frameworks using hydration

React (traditional SSR/SSG hydration)
Next.js
Vue/Nuxt
SvelteKit

(Some next-gen frameworks like Qwik or Astro Islands aim to reduce or avoid hydration.)

Final Thoughts

Rendering has evolved far beyond “client vs server.” Today, modern frameworks blend strategies to balance performance, developer experience, SEO, personalization, and scalability. Understanding how* and where rendering happens is one of the most valuable skills a frontend developer can have.

Whether you’re building a static blog, a global e-commerce platform, or a complex dashboard, choosing the right rendering strategy can define your site’s performance — and your user’s first impression.

The best way to understand rendering is to experiment: try building the same page using CSR, SSR, SSG, and ISR, and compare how the user experience changes. Modern tools make it easier than ever to mix strategies. So explore, test, and discover what works best for your use case.