Coder Legion - Recent posts tagged ssg

Next.js Rendering Strategies Explained: SSR, SSG, CSR, ISR & Cache Components (2026)

Tue, 28 Jul 2026 10:32:23 +0000

Ever opened the Next.js docs and seen acronyms like SSR, SSG, CSR, and ISR thrown around like everyone's supposed to just know what they mean? You're not alone. Half the confusion around Next.js performance comes down to one simple question nobody explains clearly enough: when does your page actually get built — and where?

Once you understand that one question, every rendering strategy in Next.js suddenly makes sense. By the end of this guide, you'll know exactly what SSR, SSG, CSR, and ISR mean, how the newer Cache Components model (powered by Partial Prerendering, or PPR) ties it all together, and which one to reach for in your own projects.

Why This Matters

Every page you build has to answer one question: "When should the HTML for this page get generated?"

There are really only three possible answers:

Ahead of time, during next build — before any user even visits the site.
On request, every time a user visits — generated fresh on the server.
In the browser, after the page loads — generated by JavaScript running on the user's device.

Next.js gives you a strategy for each answer, plus a smart hybrid (Cache Components) that mixes them on the same page. Here's the whole picture at a glance before we go through each one:

What Is SSR (Server-Side Rendering)?

💡 Think of it like: ordering food at a restaurant — you ask, the kitchen cooks it fresh, then it's served to you. Every single time.

SSR means the HTML for a page is generated on the server, for every single request. The user always gets fresh data, but the server has to do work on every visit.

In the Next.js App Router, you get SSR automatically whenever a page reads something that can only be known at request time — like cookies, headers, or search params — or when you explicitly opt a page into dynamic rendering.

// app/dashboard/page.tsx
import { cookies } from "next/headers";

export default async function DashboardPage() {
  const cookieStore = await cookies();
  const userId = cookieStore.get("userId")?.value;

  const res = await fetch(`https://api.example.com/users/${userId}`, {
    cache: "no-store", // tells Next.js: never cache this, always fetch fresh
  });
  const user = await res.json();

  return <h1>Welcome back, {user.name}</h1>;
}

What's happening here: because we read cookies() and pass cache: "no-store" to fetch, Next.js knows this page depends on request-specific data. It renders the page on the server every time someone visits, instead of reusing a cached copy.

Use SSR when:

The content is personalized per user (dashboards, account pages).
Data changes frequently and must always be fresh (stock prices, live order status).

⚠️ Common Mistake: Using SSR for content that rarely changes (like a blog post) wastes server resources. If the data isn't user-specific or constantly changing, you probably want SSG or ISR instead.

What Is SSG (Static Site Generation)?

💡 Think of it like: a printed menu — it's made once, in advance, and handed to every customer exactly the same.

SSG means the HTML is generated once, at build time, and then reused for every visitor. No server work happens per request — Next.js just serves the same pre-built HTML file.

// app/blog/[slug]/page.tsx
import { getPostBySlug, getAllPosts } from "@/lib/posts";

// This tells Next.js which pages to pre-build at build time
export async function generateStaticParams() {
  const posts = getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

export default async function BlogPostPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const post = getPostBySlug(slug);

  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.description}</p>
    </article>
  );
}

What's happening here: generateStaticParams() tells Next.js exactly which blog post pages exist. At build time, Next.js renders each one into static HTML. When a real visitor requests /blog/my-post, the server just hands over the already-built file — no rendering work, no database hit, nothing. It's instant.

Use SSG when:

Content doesn't change often (blog posts, marketing pages, documentation).
You want the fastest possible load times and lowest server cost.

⚠️ Common Mistake: If your content updates frequently but you're using pure SSG, visitors will keep seeing stale data until you rebuild and redeploy the entire site. That's exactly the problem ISR solves — keep reading.

What Is CSR (Client-Side Rendering)?

💡 Think of it like: ordering a build-it-yourself meal kit — the server hands you the box and instructions (a minimal HTML shell), but your browser does the actual cooking (fetching data and rendering the final content).

A common misconception is that CSR means the server does nothing. It doesn't — Next.js still renders and sends a minimal HTML shell from the server for Client Components (usually the loading/empty state). What makes it "client-side" is that the data fetching and the final content render happen in the browser, after JavaScript downloads and runs. The browser then "hydrates" that HTML — attaching event listeners and making it interactive — before fetching data and re-rendering with the real content.

In Next.js, you get CSR by using Client Components with hooks like useState and useEffect (or a data-fetching library like React Query).

// components/live-notifications.tsx
"use client";

import { useEffect, useState } from "react";

type Notification = { id: string; message: string };

export function LiveNotifications() {
  const [notifications, setNotifications] = useState<Notification[]>([]);

  useEffect(() => {
    fetch("/api/notifications")
      .then((res) => res.json())
      .then(setNotifications);
  }, []);

  return (
    <ul>
      {notifications.map((n) => (
        <li key={n.id}>{n.message}</li>
      ))}
    </ul>
  );
}

What's happening here: the "use client" directive tells Next.js this component should be interactive in the browser. The server sends an initial HTML shell (which may contain little or no real data), then the browser fetches data and renders the final UI after hydration. Once JavaScript loads and hydrates that HTML, useEffect fires, fetches data from /api/notifications, and re-renders the list with real content — all in the browser.

Use CSR when:

The content is highly interactive and user-specific (notification feeds, live chat, dashboards that update constantly).
SEO doesn't matter for that specific piece of UI (search engines don't need to see it).

⚠️ Common Mistake: Making your entire page a Client Component "just to be safe." This kills SEO and slows down the initial load. Only mark the interactive parts as client components — let everything else stay on the server.

What Is ISR (Incremental Static Regeneration)?

💡 Think of it like: a printed menu that quietly reprints itself in the background every hour — customers always get a menu instantly, and it's rarely more than an hour out of date.

ISR is SSG's smarter sibling. Pages are still pre-built and served instantly like static pages, but Next.js automatically regenerates them in the background after a set amount of time, without you needing to rebuild and redeploy your whole app.

// app/products/[id]/page.tsx
async function getProduct(id: string) {
  const res = await fetch(`https://api.example.com/products/${id}`, {
    next: { revalidate: 3600 }, // regenerate this page at most once every hour
  });
  return res.json();
}

export default async function ProductPage({
  params,
}: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await params;
  const product = await getProduct(id);

  return (
    <div>
      <h1>{product.name}</h1>
      <p>${product.price}</p>
    </div>
  );
}

What's happening here: revalidate: 3600 tells Next.js "this page can be served from cache for up to 3,600 seconds (1 hour)." The first visitor after that hour expires still gets the old cached page instantly — but Next.js triggers a regeneration in the background, so the next visitor gets the updated version. Nobody ever waits for a rebuild.

Use ISR when:

Content changes occasionally, but not so often that it needs to be SSR (product pages, pricing pages, news listings).
You want the speed of static pages without manually rebuilding every time data changes.

What Are Cache Components (and PPR)?

This is where things get genuinely exciting — and where most beginner tutorials stop short.

💡 Think of it like: a restaurant table that's already set, with bread on it the moment you sit down (static shell) — while your actual hot meal (dynamic content) is still being cooked and gets brought out the second it's ready.

Cache Components is Next.js's newer model for controlling caching explicitly, and it's what powers Partial Prerendering (PPR) under the hood. Instead of choosing one rendering strategy for an entire page, PPR lets a single page mix static and dynamic content together.

Here's the key idea: Next.js pre-renders a static "shell" of your page instantly (the parts that don't depend on the current request), and then streams in the dynamic parts as soon as they're ready — all without making the visitor wait for the slowest piece of data.

Step 1: Enable Cache Components

// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  cacheComponents: true, // turns on the Cache Components / PPR model
};

export default nextConfig;

💡 Tip: Once cacheComponents is enabled, Next.js stops caching things implicitly. You now have to explicitly mark what should be cached using "use cache" — this makes caching predictable instead of "magic."

Step 2: Mark cacheable parts with `"use cache"`

// app/store/page.tsx
import { Suspense } from "react";
import { CartStatus } from "@/components/cart-status";

async function FeaturedProducts() {
  "use cache"; // this function's result gets cached and reused

  const res = await fetch("https://api.example.com/products/featured");
  const products = await res.json();

  return (
    <ul>
      {products.map((p: { id: string; name: string }) => (
        <li key={p.id}>{p.name}</li>
      ))}
    </ul>
  );
}

export default function StorePage() {
  return (
    <div>
      <h1>Welcome to the Store</h1>

      {/* Static shell — cached, renders instantly */}
      <FeaturedProducts />

      {/* Dynamic hole — depends on the current user, streams in separately */}
      <Suspense fallback={<p>Loading your cart...</p>}>
        <CartStatus />
      </Suspense>
    </div>
  );
}

What's happening here: FeaturedProducts has "use cache" at the top, so Next.js treats it as part of the static shell — it's pre-rendered and reused across visitors, just like SSG. CartStatus, on the other hand, depends on who's visiting (their cart), so it's wrapped in <Suspense>. Next.js sends the static shell (heading + featured products) instantly, then streams in the cart status the moment it's ready — without blocking the rest of the page.

This is the best of every world: the instant load of SSG, the freshness of SSR, all on the same page, without you manually choosing one strategy for the whole route.

💡 Tip: You can control how long cached content lives using cacheLife() (time-based expiry) and invalidate it on demand using cacheTag() + revalidateTag() — similar in spirit to ISR's revalidate, but with much finer control over what gets invalidated and when.

⚠️ Common Mistake: Don't put "use cache" on a function that returns data specific to the logged-in user with the default (shared) cache — that data could end up served to other users. Use "use cache: private" for personalized cached content instead.

Quick Comparison

Strategy	When HTML is built	Best for	Server load per request	SEO
SSR	On every request	Personalized, frequently changing data	High	Excellent
SSG	Once, at build time	Content that rarely changes	None	Excellent
CSR	Minimal shell on server, content rendered in browser after hydration	Highly interactive, non-SEO UI	Low (just the shell)	Depends
ISR	At build time + periodic background refresh	Content that changes occasionally	Low	Excellent
Cache Components (PPR)	Mixed — static shell instantly, dynamic parts streamed	Pages with both static and personalized sections	Only for the dynamic parts	Excellent

Frequently Asked Questions

Do I have to pick one strategy for my whole app?

No — and that's the whole point of Cache Components. You can mix strategies per page, and with PPR, even within the same page. Most real-world Next.js apps use a combination of all of these depending on the route.

Is ISR the same as Cache Components?

Not quite. ISR revalidates an entire page on a timer. Cache Components give you finer control — you choose exactly which functions or components get cached, for how long, and how they get invalidated, all while letting other parts of the same page stay dynamic.

Will Cache Components replace ISR completely?

For new projects using cacheComponents: true, yes — "use cache" with cacheLife() covers what revalidate used to do, plus more. Existing apps using the older caching model can keep working as-is, but new apps are encouraged to adopt Cache Components.

Does SSR hurt my SEO?

No — search engines see fully rendered HTML either way with SSR, SSG, or ISR. CSR is the one to watch, since content rendered purely in the browser can be harder for some crawlers to index reliably.

How do I know which strategy a page is using?

Run next build and check the build output — Next.js labels each route as Static, Dynamic, or Partial Prerendered (when Cache Components is enabled), so you can see exactly how each page will behave in production.

💡 Tip: Always test caching behavior with next build && next start rather than next dev — caching behaves differently in development mode and can be misleading.

Wrapping Up

Rendering strategy isn't a one-time architectural decision anymore — it's a per-component choice. SSR gives you freshness, SSG gives you speed, CSR gives you interactivity, ISR gives you a balance between the two static options, and Cache Components (powered by PPR) let you combine all of it on a single page without compromise.

Start simple: default to SSG/ISR for content-heavy pages, reach for SSR only when you genuinely need per-request freshness, and once you're comfortable, experiment with Cache Components to squeeze instant load times out of pages that still need personalized data.

Decision Tree

Is content personalized?
→ SSR

Is content mostly static?
→ SSG

Does it update occasionally?
→ ISR

Is it highly interactive UI?
→ CSR

Need static + dynamic on same page?
→ Cache Components / PPR

Useful Resources

Continue Learning

DriftNotes — A Minimal Journaling System

Wed, 10 Dec 2025 21:19:41 +0000

Note: published initially at: https://rohitfarmer.com/posts/2025/driftnotes/

For the past several years, I’ve been experimenting with different ways of maintaining a personal journal. I tried everything: paper notebooks, digital notes, blogging platforms, custom Markdown workflows, and even small private CMS-like systems. All of them worked to some extent, but none of them struck the balance I wanted.

Most tools fall into one of two extremes:

Social media, which encourages short, impulsive posts that disappear into a timeline.
Blogging platforms, which feel too formal for quick daily notes or reflections.

I wanted something in between — a space for small but meaningful entries, longer than a tweet but far less structured than a blog post. A place where I could drop thoughts, observations, or moments from each day without turning it into an essay.

That search eventually led me to build something for myself: DriftNotes. That I now use to generate my online journal at https://journal.rohitfarmer.com/.

Why I Created DriftNotes

Over time, my journaling style became more fragmented. Some days I’d write paragraphs; other days, just a few lines and an image. But I still wanted:

a clean, minimalist reading experience
local files I fully control
a private-first workflow
the ability to publish selected entries on my website
less dependencies on centralized services
fast builds, simple HTML, and complete portability

No existing tool truly matched this philosophy. So I built one.

DriftNotes grew out of a simple idea:

Write your daily entries in plain Markdown, organized by month and year, and let a minimal static site generator turn them into a beautiful, searchable journal.

That’s all.

No database.
No logins.
No frameworks.
No “rich text editors.”
Just Markdown → HTML.

Initially, this started as a handful of scripts I wrote for my personal journaling site. Over time, I kept adding features that made sense for daily use — nothing more, nothing less.

Eventually, I realized I had built something I wanted to share.

How DriftNotes Works

DriftNotes is intentionally simple to understand and use.

Every year gets its own folder (like 2025/).
Every month is a Markdown file (2025-11.md, 2025-12.md, etc.).
Each entry starts with a heading that contains the date.
You can optionally add tags or mark an entry as a draft (to not include in the HTML output).

The build script — just a single Python file — processes everything and generates a static website with:

Clean HTML pages for each year

Entries appear in reverse chronological order.

Tag support

Add tags to entries and DriftNotes automatically creates:

tag pages
a tag index
tag pills under each entry

“On This Day” page

A fun way to revisit past moments from different years.

Dark mode toggle

No frameworks, no heavyweight UI — just clean CSS + a tiny JS file.

Offline search with Lunr.js

Search your entire journal instantly, without sending anything to a server.

RSS feed for the latest year

Useful if you or others want to follow your journal via an RSS reader.

Fully static output

Everything goes into a _site/ folder (or wherever you choose).
You can publish it anywhere: Nginx, GitHub Pages, Netlify (which I use), a pubnix, or even on a USB drive.

How I Use DriftNotes

On my local machine, I keep a folder structure like:

content/
  2024/
    2024-01.md
    2024-02.md
  2025/
    2025-12.md
    2025-11.md
config.yml
driftnotes

Every day, I add a new entry under the appropriate month’s file. Some days it’s a paragraph; some days it’s several. I include images, tags, and small reflections.

# December 2025

## 2025-12-05
tags: snowday

We experienced our first snow day today here in North Bethesda, Maryland. It wasn't bad, and schools did not close, but when my kids left for school, it was still snowing. We talked about playing in the snow once they return from school, but I don't think there will be enough snow left in our courtyard by then.

![First snow of the season - 2025](https://files.mastodon.social/media_attachments/files/115/667/411/648/050/953/original/90e4a73e475de44e.jpg)

When I run:

python3 driftnotes/build.py config.yml

the system generates a complete journal site in _site folder which I then serve through Netlify.

I use it for:

my daily personal notes
short reflections that don’t belong on my main blog
photo + text entries about family moments
capturing ideas, inspirations, and small insights
documenting hikes, trips, and things I learn along the way

Some entries I publish publicly. Some remain private.
The beauty of DriftNotes is that the source files are yours — portable, readable, and future-proof.

Now Available for Others to Use

DriftNotes was originally designed just for me, but I realized that others might appreciate a minimal tool that sits between social media and a traditional blog.

So I’ve cleaned it up, documented it, added a proper structure, and released it publicly.

If you like:

small tools
plain text
journaling
static site generators
privacy and simplicity

…then you might enjoy using DriftNotes.

You can explore the repository here: https://github.com/rohitfarmer/driftnotes

It’s released under the MIT license, and the GitHub repository can be dropped directly into your own project. You only maintain your Markdown files and a simple config.yml — DriftNotes handles the rest.

If there’s community interest, I may extend it with more features. For now, it’s intentionally focused and minimal.

Closing Thoughts

DriftNotes reflects a philosophy that has increasingly shaped my online writing:

Not everything needs to be a blog post, and not everything should be a tweet.
There’s value in the quiet, steady space in between.

If you try DriftNotes, or build something with it, I’d love to hear from you.
This little project already brings joy to my own journaling routine — I hope it can do the same for someone else.

GhostCMS + Astro + Cloudflare for writing content

Thu, 16 Oct 2025 03:18:59 +0000

Just finished setting up GhostCMS and Astro integration!
This feature will eventually replace the /blog section on my website, making it much easier for me to write and manage articles

One of the most important things before releasing it to production is testing scheduled backups and restoring them.
Since I’m using Dokploy, the backup setup is much easier, especially for the database.

For the database, I’ve set up daily backups stored on Cloudflare R2. In the future, I plan to add more redundancy to make the backups safer and more reliable.

Next, I’ll be running a few more test cases before officially releasing the GhostCMS and Astro integration.
Of course, users won’t notice any difference, it’ll still be SSG (Static Site Generation) on the frontend

Is anyone else here also using GhostCMS with Astro.js, or maybe GhostCMS with a Jamstack setup?