CSS transitions
CSS animations
JS-based animation libraries

They all try to solve the same problem:

Move UI from one state → to another state.

But they all share the same limitation:

They animate elements.

Not views.

First, What Is a “Transition”?

Before jumping into APIs, lets look into transition.

A transition is not:

“fade this div”

A transition is:

“move the user from one UI state to another, without breaking continuity”

Example:

• Clicking a product → opens product page

• Switching tabs → content changes

• Filtering a list → items reorder

Without transitions:

UI jumps

With transitions:

UI flows

The Core Problem With Traditional Animations

Let’s take a simple route change.

You go from:

Home → Product Page

What happens?

• Old DOM is removed

• New DOM is inserted

There is no connection between them

So developers try to fake it:

• clone elements

• manually position

• animate opacity/position

• sync timings

This becomes:

complex
fragile
hard to maintain

This is why most apps either:

• don’t animate route changes

• or use heavy libraries

  ---

  Enter View Transitions

  The View Transition API changes the abstraction.

  Instead of animating elements manually, you tell the browser:

  “I’m about to change the UI. You handle the transition.”

What It Actually Does

At a high level, the browser:

1. Takes a snapshot of the old UI

2. Applies your DOM update

3. Takes a snapshot of the new UI

4. Animates between them

This happens at the browser compositor level
—not inside your React tree or CSS layout.

That’s the key difference.

Important: What View Transition API Is NOT

Let’s clear the biggest misconception:

View Transition API is NOT an extension of CSS transitions

It does not animate:

width
height
position
opacity

directly on DOM elements.

Instead:

It creates visual snapshots and animates them using keyframes at the compositor level

This is why:

• it feels smoother

• it avoids layout thrashing

• it works across page navigations

Why This Matters?

Traditional animation:

DOM → Layout → Paint → Composite

View Transition:

Snapshot → Composite Animation

No layout recalculation during animation.

Result:

✔ smoother animations
✔ less jank
✔ better performance

The Core API

The entry point is simple:

document.startViewTransition(() => {
  // your UI update here
})

This tells the browser:

“Capture before and after, then animate between them.”

What Happens Internally?

When you call it:

1. Browser captures current frame

2. Runs your update function

3. Captures new frame

4. Creates pseudo elements:

::view-transition-old(root)
::view-transition-new(root)

1. Animates between them

You can control this with CSS.

Basic Example

document.startViewTransition(() => {
  setPage('product')
})

Then in CSS:

::view-transition-old(root) {
  animation: fadeOut 0.3s ease;
}

::view-transition-new(root) {
  animation: fadeIn 0.3s ease;
}

This Changes How You Think About Animations

Before:

animate individual components

Now:

animate entire UI state changes

This is a mental shift.

Shared Element Transitions

This is where it gets powerful.

You can link elements across states:

.card {
  view-transition-name: product-card;
}

Now the browser understands:

“This element in old view = same element in new view”

And animates it seamlessly.

SPA vs MPA

The API works in both:

SPA (React, Next.js)

document.startViewTransition(() => {
  navigate('/product')
})

MPA (normal links)

Browser handles navigation transitions automatically (where supported).

Why This API Exists?

Historically:

• SPA transitions → complex JS

• MPA transitions → almost impossible

View Transitions unify both.

They reduce:

manual DOM work
animation bugs
sync issues

React’s Experimental <ViewTransition>

React is trying to make this even easier.

import { ViewTransition } from 'react';

<ViewTransition>
  <Page />
</ViewTransition>

What React Is Doing Under the Hood?

React:

• automatically assigns view-transition-name

• groups elements

• triggers transitions during state updates

You don’t manually call startViewTransition.

Important Behavior

React triggers transitions only when updates happen inside:

startTransition()
Suspense
useDeferredValue

Not every state update triggers animation.

Types of Transitions in React

React categorizes transitions:

enter
exit
update
shared

Each can be customised.

Example

<ViewTransition enter="slide-in" exit="fade-out">
  <ProductCard />
</ViewTransition>

Why This Is Powerful?

Instead of:

manually syncing animations across components

You get:

automatic view-level transitions

Limitations (Important)

This API is powerful, but not magic.

1. It’s still evolving

• React version is experimental

• Some browsers still catching up.

2. Debugging is harder

Because animations happen:

outside your DOM
inside compositor

3. Not everything animates perfectly

• layout shifts can break continuity

• shared elements need correct naming

The Real Mental Model

If you remember one thing:

View Transitions don’t animate elements
They animate snapshots of UI states

When Should You Use It?

Use it when:

route transitions
page navigation
list → detail views
UI state switches

Avoid it when:

micro animations (hover, button click)
fine-grained control needed

Conclusion

For years, web animations were:

“move this element from A to B”

Now the browser is finally giving us:

“move the entire experience from A to B”

That’s a big shift.

Containerization
Orchestration

Containerization packages applications.

Orchestration runs those containers at scale.

Tools like Docker and Kubernetes power this system.

But what actually happens when you run:

docker run nginx

Does Docker start a virtual machine?

Does it boot an operating system?

Not exactly.

To understand Docker properly, we need to understand one key idea:

Containers are just Linux processes.

Everything else in Docker is built around that fact.

What Docker Really Is?

Docker is a containerization platform.

It helps developers:

Build containers
Ship containers
Run containers

Docker introduced three core building blocks:

Dockerfile
Docker Image
Docker Container

These three components form the foundation of how Docker works.

But before understanding them, we need to understand what a container actually is.

Containers Are Just Linux Processes

A container is not a virtual machine.

It is simply a Linux process running with isolation.

You can think of a container as:

Application + Runtime + Dependencies

All running as an isolated process on the host system.

Under the hood, Docker simply asks the Linux kernel to start a process.

But with two important mechanisms applied:

Linux Namespaces
Linux cgroups

Namespaces create isolation.

cgroups control resource limits.

Together they form the foundation of containers.

The Role of Linux Namespaces

Linux namespaces are responsible for isolation.

They make a process believe it is running in its own environment.

In other words, namespaces create the illusion of a separate system.

A container might think it has:

its own process tree
its own network interfaces
its own filesystem
its own hostname

But in reality, everything is still running on the same host machine.

The Linux kernel simply isolates what each process can see.

Types of Linux Namespaces

Linux provides several different namespaces.

Each namespace isolates a different part of the system.

Docker combines multiple namespaces together to create containers.

1. PID Namespace (Process Isolation)

The PID namespace isolates process IDs.

Each container gets its own process tree.

Inside a container, if you run:

ps aux

You might see something like:

PID 1    node server.js
PID 7    nginx

But on the host machine, the same processes might appear as:

PID 12834    node server.js
PID 12840    nginx

Inside the container, the application sees itself as PID 1, which normally represents the main system process.

This makes the container believe it is running on its own system.

Each container therefore has its own independent process tree.

2. Network Namespace

The network namespace isolates networking.

Each container gets its own network stack including:

IP address
Network interfaces
Routing table
Port space

Example:

Container A → 172.17.0.2
Container B → 172.17.0.3

Even if both containers run the same port, they do not conflict.

For example:

Container A → port 3000
Container B → port 3000

Because they exist in separate network namespaces, both applications can run on the same port.

Docker internally connects containers through a virtual bridge network.

3. Mount Namespace (Filesystem Isolation)

The mount namespace isolates the filesystem.

Each container sees its own filesystem.

This filesystem is built from Docker image layers.

For example a container might see:

/
├ bin
├ usr
├ app
└ node_modules

Containers cannot access host files unless explicitly mounted.

This is why Docker volumes exist.

4. UTS Namespace (Hostname Isolation)

The UTS namespace controls the system hostname and domain name.

Each container can have its own hostname.

Example:

docker run --hostname myapp nginx

Inside the container:

hostname
→ myapp

Even though the host machine may have a completely different hostname.

5. IPC Namespace (Inter-Process Communication)

The IPC namespace isolates communication mechanisms between processes.

These include:

shared memory
message queues
semaphores

Containers cannot share these resources with other containers unless explicitly configured.

This prevents unintended communication between processes in different containers.

6. User Namespace

The user namespace maps users inside a container to different users on the host system.

This improves security.

For example:

Inside a container, a process may run as:

root (UID 0)

But on the host machine, that same process might actually map to:

UID 100000

So even though the process appears to have root privileges inside the container, it does not actually have root access on the host system.

This prevents containers from gaining full system privileges.

Namespace Summary

Namespace   What it isolates

PID         Processes
Network     Networking stack
Mount       Filesystem
UTS         Hostname
IPC         Process communication
User        User IDs

Together, these namespaces create the illusion that a container is running on its own machine.

What Happens When a Container Starts

When you run a command like:

docker run nginx

Docker does not start a virtual machine.

Instead, Docker asks the Linux kernel to start a new process with isolated namespaces.

The kernel creates something like this:

Container A
 ├ PID namespace
 ├ Network namespace
 ├ Mount namespace
 ├ UTS namespace
 ├ IPC namespace
 └ User namespace

The container process runs inside these isolated views of the system.

Each container gets its own set of namespaces.

Example system:

Host Machine
 ├ Container A
 │   ├ PID namespace A
 │   ├ Network namespace A
 │   └ Mount namespace A
 │
 └ Container B
     ├ PID namespace B
     ├ Network namespace B
     └ Mount namespace B

Because of this isolation:

Container A cannot see

Processes of Container B
Network interfaces of Container B
Filesystem of Container B

All containers share the same kernel, but each sees a different isolated view of the system.

What Namespaces Do NOT Do

Namespaces isolate resources.

But they do not limit resource usage.

For example, one container might consume:

100% CPU
20 GB RAM

Even though it is isolated, it can still exhaust system resources.

This is where cgroups come in.

What Are cgroups?

cgroups (Control Groups) limit how much system resources a process can use.

They control things like:

CPU usage
Memory usage
Disk I/O
Network bandwidth

Docker uses cgroups to enforce resource limits.

Example:

docker run -m 512m myapp

This limits the container to 512 MB of RAM.

The Linux kernel enforces this using cgroups.

The Real Definition of a Container

A container is essentially:

Linux Process + Namespaces (isolation) + cgroups (resource limits)

Docker simply makes it easier to create and manage this setup.

Why Containers Start Instantly

Virtual machines must:

boot an operating system
initialize hardware
start system services

Containers do none of this.

Starting a container simply means:

create namespaces
apply cgroup limits
start the process

This is why containers start in seconds or even milliseconds.

Docker Images

Docker images are read-only templates used to create containers.

They contain:

application code
runtime
libraries
dependencies

Images use a layered filesystem.

Example layers:

Base OS layer
Node runtime layer
Dependencies layer
Application code layer

Each instruction in a Dockerfile creates a new layer.

Docker caches these layers which makes builds much faster.

A Common Misconception About Images

Many people believe containers must always be created from images.

In Docker workflows this is usually true.

But technically, containers do not require images.

Remember:

A container is just a process with namespaces and cgroups.

Images simply provide a convenient way to package the filesystem required for that process.

Dockerfile

A Dockerfile is the blueprint used to build Docker images.

Example:

FROM node:20

WORKDIR /app

COPY package.json .

RUN npm install

COPY . .

CMD ["node", "index.js"]

This tells Docker:

Start from a Node.js base image
Create a working directory
Copy package.json
Install dependencies
Copy application code
Start the server

Build process:

Dockerfile → Image → Container

Container Networking

Containers often need to communicate with each other.

Docker creates virtual networks to enable this.

Example system:

Container A → API
Container B → Database
Container C → Cache

Docker automatically assigns IP addresses and allows containers to communicate using service names.

Under the hood this uses:

network namespaces
virtual ethernet interfaces
linux bridges

Docker Volumes

Containers are ephemeral.

If a container is deleted, its data disappears.

To persist data, Docker uses volumes.

A volume is a directory on the host filesystem mounted into the container.

Example:

Host directory → /var/lib/docker/volumes/mydata
Container path → /data

Types of Docker Volumes

Bind Mounts

You specify the exact host directory.

Example:

docker run -v /home/user/data:/data myapp

Anonymous Volumes

Docker creates a volume automatically without a name.

These are harder to manage.

Named Volumes

Docker manages the volume with a specific name.

Example:

docker volume create mydata

Named volumes are easier to reuse and maintain.

Putting It All Together

When you run:

docker run nginx

Docker does roughly this:

pull image
create namespaces
apply cgroups
configure networking
mount volumes
start the process

What you see as a container…

Is really just a Linux process running with isolation and resource limits.

Now we understand how Docker actually works internally.

We covered:

Linux namespaces
cgroups
Docker images
Docker volumes
container networking

But another problem still remains.

How do we run hundreds or thousands of containers across multiple machines?

How are they scheduled, scaled, and monitored?

That is where Kubernetes comes in.

Modern applications rarely run as a single program anymore.

A typical backend system today might look like this:

API Service
Authentication Service
Payment Service
Notification Service
Database
Cache

Each component runs independently.

Sometimes even in different programming languages.

User service → Node.js
Payment service → Java
Analytics service → Python

This architecture is powerful.

But it introduces a different problem.

Not a coding problem.

A deployment problem.

A Simple Mental Model

Think of modern infrastructure like running a restaurant.

You don't just have one person doing everything.

You have specialists.

Chef
Cashier
Delivery
Inventory
Cleaning

Each person handles a specific task.

Now imagine managing this restaurant manually.

You would need to:

• hire people

• replace them if they leave

• add more during busy hours

• coordinate their work

Software systems face the same challenge.

Different services must run together.

They must scale when traffic increases.

And they must recover if something fails.

This is where containers and orchestration enter the picture.

The Problem That Started Everything

Before containers existed, applications were deployed directly on servers.

A typical situation looked like this.

Developer machine:

Node 18
PostgreSQL 14
Redis 6
Ubuntu

Production server:

Node 16
PostgreSQL 12
Redis 5
Amazon Linux

The result was predictable.

The application worked locally.

But failed in production.

This became such a common issue that developers turned it into a running joke:

"It works on my machine."

Applications depend heavily on their environment.

Change the environment, and things can break.

So the industry looked for a solution.

The First Attempt: Virtual Machines

The first major solution was Virtual Machines.

Instead of installing applications directly on servers, developers packaged them inside virtual machines.

A server might look like this:

Server
 ├ VM1 → Ubuntu + App1
 ├ VM2 → Ubuntu + App2
 └ VM3 → Ubuntu + App3

Each VM contained everything needed to run the application.

Operating System
System Libraries
Runtime
Application

This solved the environment mismatch problem.

But it created another issue.

Virtual machines were heavy.

Each VM included an entire operating system.

Typical VM images were several gigabytes in size.

Starting them could take minutes.

Running dozens of them quickly became inefficient.

So the industry looked for something lighter.

Enter Containers

Containers took a different approach.

Instead of packaging an entire operating system, containers package only what the application needs.

A container usually includes:

Application code
Runtime (Node, Python, etc.)
Libraries
Dependencies

But it does not include a full operating system.

This makes containers dramatically smaller.

And much faster to start.

But this raises an interesting question.

If containers don't have their own operating system…

how do they run?

The Host Kernel

To understand this, we need to talk about the kernel.

Every operating system has a kernel.

The kernel is the core part of the OS responsible for managing:

Processes
Memory
File systems
Networking
Hardware access

In a virtual machine, each VM runs its own kernel.

Hardware
 └ Hypervisor
     └ VM
         └ Guest OS Kernel
             └ Application

Containers work differently.

Instead of running their own kernels, containers share the kernel of the host operating system.

Hardware
 └ Host Operating System (Kernel)
     └ Container Runtime (Docker)
         ├ Container
         ├ Container
         └ Container

Each container still behaves like an isolated environment.

But under the hood, they are all using the same kernel.

This is what makes containers so lightweight.

They do not need to boot an entire operating system.

As a result:

VM size → several GB
Container size → often under a few hundred MB

Startup times also improve dramatically.

VM → minutes
Container → seconds

Containers solved the environment problem.

If a container runs on one machine, it will behave the same way on another.

But this introduced another challenge.

Running one container is easy.

Running hundreds of containers is not.

A Quick Comparison

Virtual Machines vs Containers

Virtual Machine
• Full operating system
• Large images (GBs)
• Slower startup
• Strong isolation

Container
• Share host kernel
• Small images (MBs)
• Start in seconds
• Lightweight

Containers were perfect for modern applications.

But they created a new operational challenge.

The Next Problem

Modern systems rarely run a single container.

A typical application might include several services:

API Service
User Service
Payment Service
Email Service
Database
Cache

Each service runs in its own container.

Now imagine managing this in production.

Questions start appearing quickly.

What happens if:

• a container crashes?

• traffic suddenly increases?

• a service needs more instances?

• a new version needs to be deployed?

Running a few containers manually is manageable.

Running dozens across multiple machines is not.

This is where orchestration comes in.

Orchestration

Orchestration is the automated management of containers.

Instead of manually starting and monitoring containers, an orchestration system handles it for you.

It takes care of things like:

Scaling containers
Restarting failed containers
Load balancing
Service discovery
Rolling deployments
Networking between services

In simple terms:

Containerization packages applications.

Orchestration runs and manages them at scale.

Kubernetes

The most widely used orchestration system today is Kubernetes.

Kubernetes manages clusters of machines and distributes containers across them.

A simplified cluster might look like this:

Cluster
 ├ Worker Node
 │   ├ Container
 │   └ Container
 ├ Worker Node
 │   ├ Container
 │   └ Container
 └ Worker Node
     ├ Container
     └ Container

Instead of manually controlling containers, you describe the desired state.

For example:

replicas: 3

This tells Kubernetes:

Always keep three instances of this container running.

If one container crashes, Kubernetes automatically creates a replacement.

If traffic increases, it can scale the system.

If you deploy a new version, Kubernetes can update containers gradually without downtime.

Containerization vs Orchestration

These two ideas solve different layers of the same problem.

Containerization focuses on packaging applications.

Example tool:

Docker

Orchestration focuses on managing containers at scale.

Example tool:

Kubernetes

A typical workflow looks like this:

Developer writes code
        ↓
Docker packages it into a container
        ↓
Image pushed to registry
        ↓
Kubernetes deploys containers
        ↓
Cluster runs and manages them

Containerization creates the building blocks.

Orchestration manages those blocks in production.

What Comes Next

This article introduced two core ideas behind modern infrastructure:

Containerization
Orchestration

But we have only scratched the surface.

In the upcoming articles, we will go deeper into:

• how Docker images actually work

• why containers start in seconds

• Linux namespaces and cgroups

• container networking

• how Kubernetes manages thousands of containers

Once these pieces start connecting together, modern infrastructure stops looking like magic.

And starts making a lot more sense.

• Server Side Rendering (SSR) does work during every request.

• Static Site Generation (SSG) does work once at build time.

• Incremental Static Regeneration (ISR) does work at build time and occasionally in the background.

In most real-world applications with dynamic data, these strategies aren’t used in isolation.

In reality, production code uses all three deliberately, based on data consistency requirements, performance goals, and user expectations.

This part is less about definitions and more about architectural thinking and practical usage.

Let’s dig in.

The E-Commerce Product Page That Broke My Brain

Imagine this route:

/products/airpods-pro

In Part 1 and Part 2, we treated these rendering modes in isolation.

But a real product page is not a textbook example.

In production, a product page typically contains:

• Static product metadata (title, description, images)

• Pricing that changes frequently

• Discounts or promotions

• Stock availability that can change in seconds

• Reviews that grow over time

• Personalisation (e.g., user-specific pricing)

Now ask yourself:

Should the entire product page be SSR?

Should it be SSG?

Should it be ISR?

If you answered one of the above, you’re still thinking in terms of knobs — not goals.

Let’s shift that.

Performance + Freshness = Partial Responsibility

In production, people care about:

• First Contentful Paint (FCP)

• Largest Contentful Paint (LCP)

• Data freshness

• Scalability

• Cost

• SEO

And any sane team will divide information based on how frequently it changes.

Some parts change once a month.

Others change every second.

Treating them the same is wasteful.

So the real architecture looks like this:

Product Page
├── Static Content (SSG/ISR)
├── Frequent Dynamic Data (Client Fetch / SSR API)
├── Personalised Content (Client Fetch / SSR API)

Let’s unpack this through a real sequence.

Static Layout — Pre-rendered for Speed and SEO

The parts that don’t change often — product title, description, images — go through:

• SSG if they’re truly static

• ISR if they need occasional refresh

• Build time or background regeneration

Example (App Router):

export const revalidate = 60  // only if product info changes periodically

async function fetchProductData(slug) {
  return await getProduct(slug)
}

export default async function Page({ params }) {
  const product = await fetchProductData(params.slug)

  return (
    <div>
      <h1>{product.name}</h1>
      <img src={product.image} />
      <p>{product.description}</p>
      {/* The rest will come later */}
    </div>
  )
}

This section benefits from:

• Static rendering → very fast initial HTML

• Improved SEO → search bots see full description

• Low cost → no work on every request

In DevTools:

• HTML loads with minimal TTFB

• No blocking work for static content

This alone increases perceived performance.

Behind the Scenes — Why Static Alone Is Not Enough

But in an e-commerce site, static content is never enough.

Because prices and stock change constantly.

If your static HTML says:

Price: ₹19,999
Stock: Available

But right now:

Price: ₹18,499
Stock: Sold out

Then you have technical SEO correctness issues, conversion loss, or worse — legal issues for incorrect pricing.

That’s when you stop generating HTML and start calling APIs.

Client-Side Fetching: Fresh Data, Fast Static

Once the static HTML is delivered, we fill in the dynamic pieces on the client:

"use client"

import { useEffect, useState } from "react"

function ProductDynamic({ slug }) {
  const [data, setData] = useState(null)
  const [loading, setLoading] = useState(true)

  useEffect(() => {
    async function fetchLiveData() {
      const res = await fetch(`/api/products/${slug}/live-data`)
      const json = await res.json()
      setData(json)
      setLoading(false)
    }

    fetchLiveData()
  }, [slug])

  if (loading) return <p>Loading latest price...</p>

  return (
    <>
      <p>Price: ₹{data.price}</p>
      <p>Stock: {data.stock}</p>
    </>
  )
}

export default ProductDynamic;

• Fresh data

• No blocking HTML generation

• Instant response

• Separation of concerns

And this fetch happens in the browser:

Browser → GET /api/products/airpods-pro/live-data

Which means:

• Price and stock are up to date

• API returns correct values from DB

• No server rendering needed for the entire page

• Only relevant data is fetched

You’ll see this in DevTools:

• HTML loads instantly

• Fetch/XHR calls fill in dynamic content after HTML

This is how hybrid actually feels.

The Revalidation API — The Missing Piece

Static content can become stale, and waiting for a timer is often not acceptable.

Imagine:

• A flash sale just started

• A discount just went live

• Inventory suddenly dropped

Waiting 60 seconds for ISR to regenerate is not great.

So production systems often use:

On-Demand Revalidation API

Next.js provides this for exactly this purpose.

Instead of waiting for a 60-second revalidate window, we tell Next.js exactly when to regenerate a page.

Here’s how it looks:

// app/api/revalidate/route.js
import { revalidatePath } from "next/cache"

export async function POST(req) {
  const { slug } = await req.json()

  revalidatePath(`/products/${slug}`)  // regenerate just that page

  return NextResponse.json({ revalidated: true })
}

Now when the admin updates the price:

1. The admin panel updates the DB

2. It calls:

   await fetch('/api/revalidate', {
     method: 'POST',
     body: JSON.stringify({ slug })
   })
   

3. Next.js runs the revalidation function, deletes the cached HTML for that path, and the next incoming request triggers regeneration of the page.

4. All future requests serve fresh static HTML

With this:

• No waiting for timer

• No stale pages for long windows

• Precise control over regeneration

This is how production sites keep static pages fresh without blocking users.

Why Production Sites Use This Hybrid Pattern

Let’s revisit the key trade-offs:

SSR

• Always fresh

• Expensive per request

• Higher TTFB

• Slow at scale

SSG

• Very fast

• Pre-rendered

• Great SEO

• Static until next build

ISR

• Static most of the time

• Fresh occasionally

• Low cost

• Good compromise

Hybrid (SSG/ISR + Client Fetch + Revalidation)

• Static for layout

• Fresh dynamic data

• On-demand regeneration

• Scales well

• Fast responses

This pattern aligns with production requirements:

• Fast initial load

• Correct content

• Scalable infrastructure

• SEO-friendly output

When a new price is set:

1. Layout was static

2. Dynamic fetch pulls in real pricing

3. Revalidate API regenerates static output

4. No stale content lives long

This is not hypothetical.

This is how teams actually build commerce platforms today.

Observability in DevTools

When exploring this hybrid pattern:

HTML (Doc)

• Built static

• Instant load

• Minimal TTFB

Fetch / XHR

• Client requests dynamic data

• Price and stock arrive separately

Revalidation Trigger

• Revalidate API call

• You won’t see it in Doc timing

• But you notice updated HTML next request

This separation is the architectural signature of hybrid systems.

Final Reflection

The real confusion around SSR, SSG, and ISR doesn’t come from the concepts themselves.

It comes from the fact that no real production system can be explained with only one strategy.

It’s not:

“This page is SSR”

or

“This page is SSG”

It’s:

“This page’s layout is static,
 this page’s dynamic content is fetched,
 and we regenerate only when needed.”

That is the hybrid reality.

And it’s only visible when you stop thinking in definitions,

and start thinking about:

• timelines

• execution models

• when work happens

• how content stays fresh

Which is exactly why we built this series.

The End.

Every refresh cost ~800ms.
The browser waited.
The server worked.
The timestamp changed.

It was obvious what was happening.

The expensive work was happening during the request.

So for Part 2, I wanted to answer a different question:

What happens if we move that work somewhere else?

Moving the Work to the Build

For SSG, I created two routes:

/pages-ssg
/app-ssg

They look exactly like the SSR example.

Same artificial 800ms delay.

Same Generated At timestamp.

Same UI.

The only difference is when the data is fetched.

In the Pages Router, I used getStaticProps.

In the App Router, I didn’t add anything special.

And that part surprised me.

Because in the App Router, static rendering is the default.

You don’t opt into SSG.

You opt out of it.

If your route doesn’t use dynamic APIs like cookies() or headers(),

and you don’t force dynamic rendering,

Next.js quietly pre-renders it at build time.

That’s the baseline.

Something Broke — And That’s When It Clicked

Initially, I reused the same fetch call from the SSR example:

await fetch("http://localhost:3000/api/product")

It worked perfectly in SSR.

Then I ran:

npm run build

And it failed.

It wasn’t a subtle failure either.

It just couldn’t connect.

At first, that felt strange.

But then it became obvious.

During build time, there is no server running at localhost:3000.

There are no API routes listening.

There is nothing to respond.

SSG doesn’t execute inside a running Next.js server.

It executes during compilation.

That’s a completely different phase.

So I removed the API call and extracted the logic into a function:

const getProduct = async () => {
  await new Promise((resolve) => setTimeout(resolve, 800));
  return {
    name: "Sample Product",
    price: Math.floor(Math.random() * 1000),
    generatedAt: new Date().toISOString(),
  };
};

Now the same function runs:

• During request time in SSR

• During build time in SSG

• During regeneration in ISR

Same logic.

Different execution phase.

That distinction matters more than any definition.

Observing SSG in Production

After building:

npm run build
npm start

I opened DevTools again.

Network → Doc → Timing.

Then refreshed /pages-ssg.

And this is what I saw:

There was no 800ms wait.

The timestamp didn’t change.

The server wasn’t doing anything during the request.

The expensive work had already happened.

SSG doesn’t make your request faster.

It removes work from the request entirely.

The browser just downloads a pre-generated HTML file.

That’s it.

Dev Mode Lies

If you test SSG in development mode, it won’t look like this.

In development, Next.js prioritises fast refresh and developer experience.

It doesn’t aggressively optimise static output.

So if you want to understand how SSG really behaves:

Always test in production mode.

That was one of the biggest sources of confusion for me.

Then Comes ISR

ISR felt like a compromise.

Not fully static.
Not fully dynamic.

In Pages Router:

export async function getStaticProps() {
  console.log("ISR: Generating static props...");
  return {
    props: {
      product: {
        name: "Sample ISR Product",
        price: Math.floor(Math.random() * 1000),
        generatedAt: new Date().toISOString(),
      },
    },
    revalidate: 10, 
  };
}

In App Router:

export const revalidate = 10

That’s it.

No force-static.

No force-dynamic.

Just a revalidation window.

And again, no call to localhost:3000/api/product.

Because the initial render still happens at build time.

If there’s no server running during build, there’s nothing to call.

That constraint forces you to think differently about where your data comes from.

What ISR Actually Does

Right after build, ISR behaves exactly like SSG.

Fast.

Static.

Stable timestamp.

Then I waited 10 seconds.

Refreshed.

And something interesting happened.

The first request after the revalidate window did not block for 800ms.

It still served the old HTML immediately.

But in the background, regeneration started.

Only after regeneration completed did the timestamp and price update on subsequent requests.

That’s the subtle but powerful difference.

ISR does not render per request.

It renders per interval.

And during regeneration, it serves stale content instead of blocking.

It shifts compute away from users most of the time.

Reframing Everything

At this point, the terminology stopped mattering to me.

What mattered was this:

• SSR → Work happens during request.

• SSG → Work happens during build.

• ISR → Work happens during build and occasionally in the background.

That’s the entire model.

Everything else — performance, scalability, freshness — flows from that decision.

Once you see it in the Network tab,

it stops being abstract.

You can measure it.

You can reason about it.

And most importantly —

You can choose intentionally.

In Part 3, we’ll leave the controlled experiment and look at real applications.

Because in production, almost nothing is purely SSR or purely SSG.

And that’s where the real architectural decisions begin.

“SSR renders on every request.”

But when I tried to observe it in practice, something clicked:

All the diagrams in blogs and docs tell you what,
but none tell you why it feels slow or what the browser actually waits for.

So I set up a simple route in my test project:

/pages-ssr   // For Pages Router SSR
/app-ssr     // For App Router SSR

Both do the same thing:

• simulate an 800 ms delay

• fetch “data”

• return a timestamp

• render a simple UI

Everything else remains constant.

Same UI.
Same data.
Same delay.

Only the rendering strategy changes.

SSR — Not Theory, But What Happens

Here’s what I observed in DevTools:

1. Open Chrome DevTools → Network

2. Filter by Doc

3. Reload /pages-ssr

4. Click the document request

5. Go to the Timing tab

6. Look at Waiting for server response

This is the important part:

You’ll see:

• Waiting ~800 ms

• Content download ~negligible

• Timestamp changes on every refresh

The browser waits until the server is done doing everything — data fetch, render, HTML generation — before it ever gets a byte of HTML.

That’s what SSR really means.

The server is doing work synchronously before responding.
No pre-rendered file.
No caching.
Just work on every request.

In the old blog posts you’d hear:

“SSR increases TTFB.”

But Time to First Byte (TTFB) didn’t become meaningful to me until I saw it in the timing breakdown:

📌 The server doesn’t send HTML until rendering completes.
📌 The browser genuinely waits.
📌 Most of that wait is server compute.

That’s the real mechanism.

Why SSR Isn’t Just a Buzzword

To understand why this matters, consider what SSR promises:

• Fresh data on every request

And what it costs:

• You pay the rendering cost each time

• You pay it before the browser gets HTML

• That cost shows up as TTFB

In my experiment:

Waiting (TTFB): ~800 ms
Content Download: ~0.5 ms

Look at that green bar in the timing tab. That is total server compute.

No network, no JS. Just server work before response.

That’s SSR.

If you refresh 10 times, the timestamp and timing stay consistent — because every request triggers a new render.

Pages Router vs App Router — Same Outcome, Different API

In the Pages Router, we force SSR using:

export async function getServerSideProps() { … }

In the App Router, we achieve SSR using:

export const dynamic = "force-dynamic";

Different syntax.

Same real behavior.

From the browser’s perspective:

• HTML is generated per request

• The timing breakdown is the same

• TTFB reflects server work before response

The difference is just how Next.js expresses it.

What I Learned About SSR

Here’s the important insight:

SSR is not about React.

SSR is about when HTML is generated.

You can use it when:

• You must guarantee fresh data every time

• You cannot cache at any level

• Every user needs up-to-the-millisecond correctness

But you pay for it by:

• Blocking the request

• Increasing TTFB

• Executing server compute per request

That’s the real SSR execution model — and now we can measure it.

In the next Part, we’ll flip the model completely.

We’ll move the rendering cost out of the request and into the build.

And that change — from per-request to pre-generated — will change everything.

I’ve read the official documentation.
I’ve read blog posts.
I’ve seen the diagrams:

• SSR → renders on every request

• SSG → renders at build time

• ISR → static but revalidates

I understood the definitions.

But I still had confusion.

Not about what they are called —
but about how they actually work and when to choose one over the other.

Questions like:

• Why exactly does SSR increase TTFB?

• Why does SSG feel instant?

• What is ISR really doing behind the scenes?

• What does Next.js use by default?

Instead of reading more explanations, I decided to observe the behaviour directly.

So I built a small controlled experiment.

Link to Repository

What This Project Actually Is

This repository is not a real application.

It is a simple demo web app designed to demonstrate the differences between SSR, SSG, and ISR in a measurable way.

Each route in the project:

• Simulates an 800ms data fetch

• Displays a Generated At timestamp

• Uses exactly one rendering strategy

Everything else remains constant.

• Same UI

• Same data

• Same artificial delay

The only variable that changes is the rendering model.

This allows us to observe the impact of each strategy purely at the network and execution level.

For the best understanding, I recommend cloning the repository and running it locally.
If you prefer not to, I will include screenshots throughout the series so you can still follow the analysis.

What We Are Actually Comparing

We are not comparing APIs.

We are not comparing router styles.

We are comparing one fundamental question:

When is the HTML generated?

That is the only axis that truly matters.

Everything else — performance, freshness, scalability — flows from that decision.

For deeper clarity, the examples in this project are implemented using both the Pages Router and the App Router.
This helps separate rendering strategy from router implementation details.

How to Explore the Repository

To properly understand what is happening, do not just read the code.

Open DevTools.

For each route:

1. Go to Network

2. Filter by Doc

3. Click the document request

4. Open the Timing tab

Observe:

• Waiting for server response (TTFB)

• Content download time

• Total request duration

• Timestamp behaviour across refreshes

Do not rely only on the UI output.

Observe the network waterfall.

That is where the execution model becomes clear.

The Structure of This Series

We will start from the definition level and progressively go deeper.

This series is divided into three focused parts.

Part 1 — The Request (SSR)

We will analyze:

• Why every refresh costs ~800ms

• Why TTFB increases

• What “render per request” truly means

• What the Network tab reveals about server blocking

Part 2 — The Build (SSG & ISR)

We will examine:

• Why SSG appears instant

• Why development mode can mislead you

• How ISR regeneration actually works

• What happens after the revalidation window expires

Part 3 — The Hybrid Reality

Finally, we connect everything to real-world architecture:

• Why most production apps use hybrid rendering

• Why confusion happens in real projects

• How to choose the correct strategy intentionally

There was a time when sleeping at 2AM felt super cool.

School days.
Early college days.

If you slept at 10PM, you were “uncle”.
If you slept at 2AM, you were elite.

Late night movies.
Random YouTube.
Scrolling for no reason.
Thinking about the startup I built perfectly in my mind… but nowhere else.

Important clarification:
I didn’t even code till I was 22.

So this wasn’t “hustle”.
It was just vibes.

But the brain doesn’t care about vibes.
It builds habits.

Chapter 2: The Side Effects

Years passed.

2AM became default.

Then something weird started happening.

Even if I slept 9–10 hours…
I woke up tired.

Heavy head.
Low energy.
Morning irritation.

It felt like my body booted up in safe mode.

Chapter 3: The Science (Very Light)

I honestly wasn’t planning to explain the science part.

How can someone who hasn’t properly opened a biology textbook after 10th standard suddenly start talking about hormones and brain systems?

But since this is a tech blog — and we like understanding how things work under the hood — I’ll try.

Inside our body, there’s something called the circadian rhythm.

Think of it like an internal scheduler.
A biological clock that runs on roughly a 24-hour cycle.

It regulates when you feel sleepy, when you feel alert, when your body temperature drops, when hormones are released — almost everything related to your daily energy.

At the center of this system is a tiny part of the brain that responds mainly to light and darkness.

When it gets dark, your brain starts releasing melatonin — the hormone responsible for making you feel sleepy. Your alertness decreases, body temperature drops slightly, and your system begins preparing for rest.

Now here’s the part most of us ignore.

Your brain doesn’t know the difference between sunlight and your bedroom LED light.

Light is light.

Especially blue light — the kind emitted from:

• Phone screens

• Laptop screens

• TVs

• White LED bulbs

When you sit under bright light at 11:45PM scrolling or watching something, your brain interprets that as daytime.

So melatonin release gets delayed.

Which means:

• You don’t feel sleepy at the right time.

• You stay awake longer without realising it.

• You go to bed but your brain is still active.

Even normal room lighting can reduce melatonin levels slightly. Bright LED lighting can suppress it more significantly.

It’s like shifting your system clock every night and expecting all scheduled processes to run properly.

Morning works in the opposite way.

When sunlight hits your eyes, melatonin drops and cortisol rises — helping you feel awake and alert. If you wake up late and avoid natural light, that signal also gets delayed.

So when I was sleeping at 2AM one day, 12:30AM the next, 3AM on weekends — my internal clock was constantly adjusting.

Even if I slept 9–10 hours, the timing was misaligned.

Sleep isn’t just about how long you sleep.
It’s about when you sleep.

Your body prefers consistency over chaos.

Once I fixed my sleep time and wake-up time — and reduced late-night light exposure — things slowly started syncing again.

No hacks.
No extreme routines.

Just alignment.

Chapter 4: Operation Reset

No 5AM challenge.
No motivational reels.
No ice bath nonsense.

Just one rule:

Sleep at the same time.
Wake up at the same time.
Every single day.

Even Sunday.

Day 1?
Hard.

After that?
Smooth.

Surprisingly, I never struggled to wake up after the first day.

That shocked me.

The body adjusts faster than the ego.

Chapter 5: The Upgrade

Now I wake up fresh.

Not because I sleep 10 hours.
But because I sleep consistently.

Brain feels clear.
Energy is stable.
Mornings feel calm.

Kerala mornings are underrated by the way.
That quiet air.
That slow sunlight.
Peaceful.

Earlier I used to miss all that because I was sleeping through it.

Chapter 6: Final Dialogue

I’m not saying wake up at 5AM.
I’m not saying night life is evil.

I’m just saying this:

Don’t romanticize 2AM like I did.

Discipline feels boring.
But boring things build strong systems.

And as a 25-year-old tech guy trying to build a life,
stable energy is more powerful than late night drama.

If you’re reading this at 1:38AM…

Close this tab.

Sleep brother.

The Challenge: Location-Based Content Without the Routing Mess

My application needed to display similar content for multiple locations, using URLs like:

• /sell-your-car-in-kochi

• /sell-your-car-in-tvm

• /sell-your-car-in-kollam

The conventional approach would require creating separate pages for each location, leading to duplicated code and maintenance headaches. This is where Next.js rewrites come to the rescue.

Understanding Rewrites in Next.js 15

Rewrites allow you to map an incoming request path to a different destination path. Unlike redirects, rewrites don't change the URL in the browser, making them perfect for serving the same content under different URLs while preserving the original URL for SEO and user experience.

Implementing a Location-Based Content Solution

Step 1: Create Your Base Page

First, I created a single page component at app/sell-your-car/page.tsx that would serve as the template for all location variants:

// app/sell-your-car/page.tsx
import { NextPage } from 'next';

interface PageProps {
  params: Record<string, string>;
  searchParams: {
    location?: string;
  };
}

const SellYourCar: NextPage<PageProps> = ({ params, searchParams }) => {
  // Extract location from search params (passed through rewrites)
  const location: string = searchParams.location || 'your area';

  return (
    <div className="container mx-auto py-8">
      <h1 className="text-3xl font-bold mb-6">Sell Your Car in {location}</h1>

      <section className="mb-8">
        <h2 className="text-2xl font-semibold mb-4">Why Sell Your Car With Us in {location}?</h2>
        <p>
          We offer the best prices for your used car in {location}. Our network of buyers 
          ensures you get competitive offers quickly and hassle-free.
        </p>
      </section>

      <section>
        <h2 className="text-2xl font-semibold mb-4">How It Works in {location}</h2>
        <ol className="list-decimal pl-5">
          <li className="mb-2">Fill out our simple online form with your car details</li>
          <li className="mb-2">Receive instant estimated value for your car</li>
          <li className="mb-2">Schedule an inspection at our {location} center</li>
          <li className="mb-2">Get paid on the spot after inspection approval</li>
        </ol>
      </section>
    </div>
  );
};

export default SellYourCar;

Step 2: Configure Rewrites in next.config.js

Next, I set up the rewrites in my next.config.js file:

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  async rewrites() {
    return [
      {
        source: '/sell-your-car-in-:location',
        destination: '/sell-your-car?location=:location',
      },
    ];
  },
};

module.exports = nextConfig;

Conclusion

This simple yet powerful implementation solves our routing challenge elegantly. With just two files, we've created a system that can handle an unlimited number of location-based URLs without creating separate pages for each one.

The key benefits of this approach include:

1. DRY Code: One component serves multiple URLs, reducing duplication

2. Maintainability: Updates to the page structure only need to be made in one place

3. SEO-Friendly: Each URL preserves its unique path for search engines

4. Performance: Only one page component needs to be loaded and cached

5. Scalability: Adding new locations doesn't require code changes

Next.js 15's rewrites feature provides the perfect solution for handling dynamic, parameter-based URLs while maintaining clean code architecture. This pattern can be applied to many other scenarios beyond location-based content – product categories, service areas, or any situation where you need similar content with different parameters.

By leveraging TypeScript, we also gain the benefits of type safety and better developer experience, making our implementation both robust and maintainable.

The best part? It's incredibly simple to implement, requiring minimal code changes to achieve powerful URL handling capabilities.