After months of pushing production builds, debugging late-night issues, and endless Jira tickets, four developers decided it was time for a break.

It wasn’t just burnout—they were chasing a phantom. For months, their website had been the source of mounting frustration. No matter how many optimizations they shipped, the homepage crawled. Customers left before it finished loading. Leadership pointed fingers: Was it the APIs? The bloated JavaScript bundles? Nobody knew for sure.

A road trip to Render Valley, known for its scenic views and patchy internet, felt perfect.

• Leo – Co-founder & backend veteran who hadn’t touched frontend in a while.
• Sage – UX expert who sketched ideas faster than code could render.
• David – The full-stack philosopher of the group, fluent in metaphors.
• Phoebe – The curious new frontend dev, hungry to understand rendering better.

None of them anticipated that a casual trip would solve their company’s biggest performance mystery.

---

Act 1: The Ghost Town Diner

The team’s first pit stop was an oddly deserted town. A diner called ByteBite had one promise: “A digital dining experience.”

A kiosk greeted them:

“Welcome! Please wait while we load your meal experience…”

It took seconds for anything to happen. Eventually, a robotic waiter brought out… an empty plate and a QR code.

“Why serve nothing at first?” Phoebe asked.

David sipped water and smiled:

“It’s like Client-Side Rendering (CSR). The entire app loads in the browser. Until the JavaScript bundles download and run, there’s nothing usable.”

Let’s discover how it all works technically:

What is CSR?

• The server sends a bare HTML file with a <div id="root"></div> and some bundled JavaScript.
• The browser downloads JS, then renders the content dynamically on the client side using frameworks like React or Vue.

Pros:

• Ideal for highly interactive single-page apps (SPAs).
• Fast navigation after the initial load.
• Minimal server resource usage after deployment.

Cons:

• Slow first load; user sees a blank screen while JS loads.
• Poor SEO unless using workarounds (e.g., pre-rendering).
• Heavy reliance on JavaScript execution.

---

Act 2: The Wedding Feast

The next day, a wrong turn led them to a bustling village. They crashed a local village wedding by accident — and were instantly invited to feast. Tables were full, dishes were steaming hot, and everyone was already eating. The food was ready. No waiting. Just sit, and enjoy.

Sage’s eyes lit up.

“This is amazing! This is how our sites should feel.”

Leo nodded,

“Exactly. Server-Side Rendering (SSR). The server pre-cooks everything and sends it all at once. It feels instant.”

Let’s understand technically:

What is SSR?

• Every time a user requests a page, the server generates the HTML dynamically.
• HTML is generated per request using frameworks like Next.js (getServerSideProps), Nuxt.js, or NestJS + React SSR.
• The client receives ready-to-render HTML, making the content visible immediately.
• JS then hydrates the page for interactivity — converting the static HTML into a live React app by attaching event listeners, restoring component state, and enabling updates.

Pros:

• Better for SEO and bots – search engines get full HTML content.
• Faster initial load, especially on slower devices.
• Fine-grained data fetching per route.
• Faster Time-to-First-Byte (TTFB) and First Contentful Paint (FCP).

Cons:

• Slower response time under high traffic (every request is rendered on demand).
• More server load and infrastructure complexity.
• Slight delay in making the page interactive (hydration).
• Server has to re-render on every request, potentially costly under heavy load.

Phoebe noted,

“But imagine if 1,000 guests arrived at once. Wouldn’t the servers — I mean chefs — get overloaded?”

David said,

“True, It doesn’t scale well unless you optimize.”

---

Act 3: The Magical Tea Stall

On the final day, while driving back through the hills, they stopped at a quirky roadside tea stall. Each customer ordered from a shelf full of thermos flasks — already brewed teas with labels: “Masala (fresh)”, “Lemon (5 mins old)”, “Ginger (expires in 10)”.

The old vendor smiled,

“I brew some fresh teas every few minutes. If one runs low, I make a new batch quietly behind the stall.”

Phoebe grinned,

“This is genius. It’s like… everything feels static and fast, but still fresh.”

Sage high-fived her,

“Incremental Static Regeneration (ISR). Pages are pre-built, cached, and updated in the background as needed.”

Let’s unpack the technology behind this:

What is ISR?

• Pages are pre-rendered at build time like static sites (getStaticProps).
• You can set a revalidation time (revalidate: 60), so after that time, a request will trigger a background regeneration.
• The user still sees the existing static page while regeneration happens.
• The speed of static site generation (SSG) with the flexibility of server-side rendering (SSR).

Before ISR, sites used Static Site Generation (SSG)—where pages are pre-rendered at build time and served instantly as static files. While SSG is extremely fast and cost-effective, it requires a full rebuild every time content changes. ISR extends this model by letting you update static pages incrementally in the background, without rebuilding the whole site.

Pros:

• Performance of static with the freshness of dynamic.
• Scales well with CDN delivery.
• Reduced build time compared to full static generation.
• SEO-friendly and cost-efficient

Cons:

• More complex setup for edge cases (e.g., fallback states).
• Not suitable for highly personalized or real-time content.
• Delayed content freshness (based on revalidate)

---

Rendering Strategies with Next.js

Next.js is a powerful React framework that supports multiple rendering strategies—CSR, SSR, SSG, and ISR—in one project.

• You can pick the right strategy per page instead of committing to just one approach for the entire app.
• Next.js optimizes performance, SEO, and developer experience out of the box.
• It provides clear conventions and APIs that make switching strategies simple.

Technical Implementation: Next.js Example

Crisp and clear code examples for CSR, SSR, and ISR using Next.js, which supports all three.

Each rendering strategy applies to a separate page (e.g., /csr.js, /ssr.js, /isr.js).

1. Client-Side Rendering (CSR)

With CSR in Next.js, the rendering happens completely on the client, typically using useEffect to fetch data.

// pages/csr.js
import { useEffect, useState } from "react";

export default function CSRPage() {
  const [data, setData] = useState(null);
  const [isClient, setIsClient] = useState(false);

  useEffect(() => {
    setIsClient(true);
    fetch("https://jsonplaceholder.typicode.com/posts/1")
      .then((res) => res.json())
      .then((json) => setData(json));
  }, []);

  if (!isClient) return null;
  if (!data) return <p>Loading...</p>;

  return (
    <div>
      <h1>Client-Side Rendering (CSR)</h1>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
}

2. Server-Side Rendering (SSR)

With SSR, the data is fetched on every request using getServerSideProps.

// pages/ssr.js
export async function getServerSideProps() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts/1");
  const data = await res.json();

  return {
    props: {
      data,
    },
  };
}

export default function SSRPage({ data }) {
  return (
    <div>
      <h1>Server-Side Rendering (SSR)</h1>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
}

3. Incremental Static Regeneration (ISR)

With ISR, the page is pre-rendered at build time, but can be regenerated in the background at intervals (e.g., every 10 seconds).

// pages/isr.js
export async function getStaticProps() {
  const res = await fetch('https://jsonplaceholder.typicode.com/posts/1');
  const data = await res.json();

  return {
    props: {
      data,
      generatedAt: new Date().toISOString(),
    },
    revalidate: 10,
  };
}

export default function ISRPage({ data, generatedAt }) {
  return (
    <div>
      <h1>Incremental Static Regeneration</h1>
      <p><strong>Page generated at:</strong> {generatedAt}</p>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
}

---

Rendering Models at a Glance

Choosing the Right Strategy

---

Epilogue: Back on Monday after the Weekend Trip

Refreshed and inspired, the team did a full audit of their projects and rewrote their rendering stack. And the results were: Load times down significantly, SEO scores up, Bounce Rates reduced, and thrilled clients.

The lesson from Render Valley stayed with them forever:

“Don’t just design the experience. Think about how it’s served.”

---

Conclusion

Rendering isn’t just a tech choice. It’s an experience strategy. Choosing between CSR, SSR, and ISR can make or break your product’s performance, discoverability, and user engagement.

Modern frameworks like Next.js empower you to combine SSR, CSR, and ISR in the same application. Instead of picking one globally, you can adopt a hybrid rendering strategy — delivering SEO-critical pages via SSR, high-traffic static pages via ISR, and admin tools via CSR.

So next time you plan your app architecture, remember to:

Match your rendering approach to the use case, not just the tech trend.

---

✍️ Author’s Note

Thanks for riding along through Render Valley.

If it helped clarify when to reach for CSR, SSR, or ISR — or if Phoebe’s curiosity felt a little too relatable — I’d love to hear your thoughts.

Let’s build beautiful and discoverable experiences.

— Hasti Sutaria