RIPPLE : RUBEK MAHARJAN

Next.js is a powerful React-based framework developed by Vercel that simplifies building production-grade web applications. It offers built-in support for routing, server-side rendering, static site generation, and even API routes — making it a flexible tool for both frontend and fullstack developers.

One of the most powerful aspects of Next.js is its flexible rendering strategies, which determine when and where a page’s content is rendered — whether on the server, client, or at build time. Choosing the right strategy can impact performance, cost, and SEO.

Let’s take a closer look at the four main rendering strategies in Next.js:

1. SSR (Server Side Rendering)

In this rendering strategy, the content of a webpage is rendered on the server at the time of the request. This means that every time a user visits the page, the server generates the HTML with the latest data and sends it to the browser. As a result, users always get real-time content.

This approach is beneficial for SEO, as search engine crawlers receive fully-rendered HTML content. However, it puts a heavier load on the server because rendering happens on every request, which can lead to increased server costs. It may also be slower than other strategies since the server must fetch data and build the page on demand.

SSR is commonly used for websites that are highly dynamic and require frequent content updates. For example, social media platforms, real-time dashboards, and SaaS applications often use SSR to keep their data current.

2. CSR (Client Side Rendering)

In CSR, the content of a webpage is rendered entirely on the client-side, in the user’s browser. When a user visits the page, the server sends a minimal HTML shell along with JavaScript. Once the JavaScript is loaded and executed, it fetches the data needed to render the actual content.

Compared to SSR, CSR is more cost-effective since the server doesn’t need to do any rendering — it just delivers static files. However, CSR can negatively affect SEO because search engine crawlers may not see the actual content immediately. While modern crawlers can execute JavaScript, this adds friction and may result in slower indexing or missed content.

CSR is ideal for highly interactive web applications where real-time data and dynamic UI interactions are more important than SEO. Examples include tools like Google Docs, shopping cart UIs, live chat apps, and map-based applications.

3. ISR (Incremental Site Regeneration)

ISR is a hybrid approach first introduced by Next.js. It allows static pages to be generated at build time, with the ability to regenerate them in the background after a certain time (called the revalidate period). This means you get the speed and performance of static pages, while still being able to update content without rebuilding the whole site.

At build time, only the available or known paths are generated and cached. If a user requests a path that wasn’t built during the initial build, it is generated on-demand at the server. Depending on the fallback setting, the behavior differs: if fallback is set to 'true', the user sees a temporary fallback page while the actual page is being built in the background. If it’s set to 'blocking', the user waits until the page is ready and then receives the full content.

The key part is that regeneration happens only when a request is made, even if the revalidate time has expired. This means content won’t update until someone visits that page. The first user after expiry gets the stale content, while the page is regenerated in the background. Subsequent users then receive the updated content.

ISR is SEO-friendly since the generated pages are served as full HTML. It’s also cost-effective compared to SSR, as pages are cached and don’t need to be rebuilt on every request.

It’s commonly used in e-commerce sites where product inventory, prices, and descriptions might change often; news websites that publish content frequently but not in real-time; and user-generated content platforms where content is mostly static but new items are added regularly.

4. SSG (Static Site Generation)

In SSG, pages are generated at build time and served as static HTML files. This makes it one of the fastest and most cost-effective rendering strategies. Since pages are pre-rendered and stored on the CDN, they can be served instantly to users with minimal server load.

SSG is also great for SEO because web crawlers get fully rendered HTML immediately, and the pages load very quickly. In addition, static sites can be deployed for free on platforms like GitHub Pages, Netlify, or Vercel, making it ideal for small projects or content that doesn’t change often.

However, the main limitation is that content updates require a rebuild and redeployment. So it’s not suitable for content that needs to change frequently or in real-time.

SSG is best suited for blogs and articles (especially when updates are rare), documentation sites, landing pages, and static company websites such as “About Us” and “Contact” pages.

Best choice for SEO (SSG > ISR > SSR > CSR)

When it comes to SEO, the best choice is SSG, since it delivers fully rendered HTML instantly to both users and search engine crawlers. ISR follows closely by serving static pages that update periodically, making it both fast and crawlable. SSR also provides full HTML but may be slightly slower, which can affect SEO performance. CSR ranks the lowest because content is rendered in the browser, and crawlers may miss or delay indexing it due to JavaScript execution.

Best choice for cost friendliness (SSG > CSR > ISR > SSR)

For cost efficiency, SSG again comes out on top as it generates pages at build time and requires no server for rendering. CSR is also budget-friendly since it only serves static assets. ISR is reasonably cost-effective but involves occasional server-side regeneration. SSR is the most expensive, as it renders pages on every request, putting continuous load on the server.

Data freshness (SSR > CSR > ISR > SSG)

In terms of data freshness, SSR is the most up-to-date, as it fetches new data with every request. CSR also provides fresh data but only after the page loads in the browser. ISR offers a middle ground — content is regenerated after a set interval, so it may be slightly outdated. SSG is the least fresh, as content stays the same until the site is rebuilt and redeployed.

Sample code example in NextJs App router:

1. SSR

async function getData() {
  const res = await fetch('https://api.example.com/posts/1', { 
    cache: 'no-store' 
  });
  return res.json();
}

export default async function Page() {
  const data = await getData();

  return <div>Post title: {data.title}</div>;
}

2. CSR

'use client';

import { useEffect, useState } from 'react';

export default function Page() {
  const [data, setData] = useState<any>(null);

  useEffect(() => {
    fetch('https://api.example.com/posts/1')
      .then((res) => res.json())
      .then(setData);
  }, []);

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

  return <div>Post title: {data.title}</div>;
}

3. ISR

async function getData() {
  const res = await fetch('https://api.example.com/posts/1', {
    next: { revalidate: 60 }, // Regenerate every 60 seconds
  });
  return res.json();
}

export default async function Page() {
  const data = await getData();

  return <div>Post title: {data.title}</div>;
}

4. SSG

async function getData() {
  const res = await fetch('https://api.example.com/posts/1', {
    cache: 'force-cache', // default behavior (static)
  });
  return res.json();
}

export default async function Page() {
  const data = await getData();

  return <div>Post title: {data.title}</div>;
}

Conclusion

Each rendering strategy in Next.js serves a different purpose, and choosing the right one depends on factors like SEO, performance, cost, and how frequently the content changes. SSG works well for static content with great SEO benefits, CSR fits interactive apps but comes with SEO limitations, SSR provides real-time data but is more resource-intensive, and ISR offers a smart middle ground between static speed and dynamic updates.

I haven’t yet tried ISR in a real project, I’m still exploring how it works. This is a learning in progress, and there may be small mistakes or things I understand better over time. But exploring these concepts through documentation, examples, and hands-on coding has helped me grasp how powerful and flexible Next.js really is when it comes to rendering strategies.