In a recent article, we talked about the important role of server components in modern web development, particularly focusing on their integration with client components in NextJS. Building on that foundation, this article aims to dive deeper into the practical applications of these concepts. Within the NextJS framework, we’ll explore the different roles of:

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

and how they can be leveraged to enhance both rendering efficiency and overall performance.

To illustrate these concepts, we’ll be working with a NextJS setup, as shown in the following image:

Additionally, our examples will incorporate mockAPI and we will learn how we can use it throughout this article.

Let’s begin with Static Site Generation (SSG) in NextJS.

SSG

SSG, which stands for Static Site Generation, is the process of pre-rendering pages at build time, generating static HTML files. This approach offers several advantages, particularly in terms of performance and SEO.

In NextJS, we can build the application with:

yarn build

When we build the NextJS application, each page using SSG is pre-rendered into static HTML, including the data fetched from the server. This results in a series of HTML files that can be served directly from a CDN, leading to faster page load times since the server-side computation is eliminated on each request.

Once the build is complete, we can run the application with:

yarn start

To demonstrate it, let’s create a simple ‘About’ page. Begin by creating an about folder within the app directory, and then add a file named page.tsx in this folder.

The page.tsx file might look something like this:

// src/app/about/page.tsx
const AboutPage = () => {
  return This is about page;
};

export default AboutPage;

Now, let’s proceed to build this page using yarn build.

Following this process, you’ll notice that the ‘About’ page is constructed as a static page (indicated with the circle symbol). While this example is relatively simple, it effectively demonstrates the core concept of SSG in NextJS. To make it more interesting, let’s look at another example where the page content is fetched from a server. For this purpose, we’ll integrate mockAPI to fetch some data.

mockAPI

MockAPI is a tool designed to simulate backend services by providing customisable mock APIs. It enables developers to create fake APIs that mimic the behaviour of real backend services. For our demonstration, we’ll use the the free plan.

After logging into MockAPI, create new project by providing a name for the project and an API Prefix, as shown in the screenshot below:

Once the project is created, click on its title which will reveal the API endpoint and we will use it to fetch data from our NextJS application:

To test our ‘About’ page, let’s create some mock posts. For us to test the About page, I created as the the following screenshot:

Once created, you will see the about is now created. To control the number of posts created, hover over the number 0 and click to set the desired quantity. For our example, we’ll generate two posts (as we cannot create only one post) and we’ll use the first post from the array for our ‘About’ page test.

Click on the Data button to view the content of your generated posts. With the mock data set up in MockAPI, let’s fetch content into our NextJS application and see how SSG works with fetching data.

SSG – Fetching Data

Let’s fetch the data. Here is the example code.

As discussed in the Server and Client Components article, we can make the AboutPage component async for data fetching. For this testing, we will only show the first content in the returned data (line 12).

Now let’s build and start the server again, and when you access http://localhost/about in your local machine, you will see the content generated , almost instantly.

NextJS extends the native web fetch() API and it automatically applies force-cache for fetch method as the default option (optional so we don’t need to add it manually) when fetching data (we’ll explore other options later). This means that the About page is generated as a static site (SSG) by default.

The data is fetched and used to create a static About page at build time and as all content is pre-built and ready as static pages, the page renders very quickly.

Refreshing content

Now let’s see an interesting part. Let’s go to MockAPI and click on the “Generate All” button, which will regenerate the content. However, when you return to the About page and refresh it, you’ll notice the content remains unchanged. This is a result of NextJS’s default behaviour of caching fetched data. Consequently, there won’t be any updates to the data once it has been built.

To update the content on static pages, the site must be rebuilt and this is the limitation of SSG. Although SSG offers rapid access to pages without server requests, updating even a small portion of the content requires rebuilding the entire application. We will discuss how we can solve this problem with SSR and ISR in the following sections.

Testing in prod vs dev env

Now the most effective way to test this is in a production environment, and let me explain why.

When you halt the server and rebuild it using yarn build, then restart your local server, you might not see the content updating, even though it should after a rebuild. This often causes confusion in the community, as NextJS’s internal cache management can be somewhat misleading.

During data fetching, the results of these fetch requests are cached in the local .next/cache/fetch-cache directory of your project.

In a local dev environment, this directory will accumulate cached requests and if you perform the build process locally, this stale, cached data is used.

However, when building and deploying projects (on prod), this cache folder typically doesn’t exist in those prod environments as it’s usually ignored by Git.

// .gitignore

...

# next.js
/.next/
/out/

...

This means that while your local machine uses cached data, your prod environment fetches fresh data with each build.

Therefore, if you notice that rebuilding updates data in the production environment but not in your local environment, this discrepancy is the cause.

Alright, now we had a look at how SSG works and how we can generate the static pages. Next, let’s dive into how SSR works.

SSR

SSR, or Server-Side Rendering, is a process where pages are rendered on the server at runtime, as opposed to SSG which involves pre-rendering pages during the build time.

When a user requests a page, the server dynamically generates the HTML content at that very moment, or runtime. This approach ensures that users always receive the most current content, made to their specific request. It’s particularly beneficial for pages requiring real-time data or user-specific content.

Comparatively, in SSG as discussed above, pages are pre-rendered during the build phase. This means any updates in the data requires rebuilding the application to reflect these changes. However, SSR overcomes this limitation by rendering pages on-demand, ensuring immediate access to the latest data.

As we saw above, when fetching the about page using SSG, the code might look like:

const aboutResponse = await fetch(
  `${process.env.NEXT_PUBLIC_API_ENDPOINT}/about`
);

For SSR, we add a cache control option to the fetch request:

const aboutResponse = await fetch(
  `${process.env.NEXT_PUBLIC_API_ENDPOINT}/about`,
  { cache: 'no-store' }
);

After adding the option, let’s start the server by yarn dev.

Now when we regenerate the content in MockAPI, the updates will be reflected immediately upon refreshing the page. And in practice, this means that each page refresh triggers a new request to the server.

While this ensures up-to-date content, it also implies a higher server load compared to SSG.

To balance the need for fresh data with server performance, Incremental Static Regeneration (ISR) can be employed.

ISR

ISR (Incremental Static Regeneration) offers a unique approach to satisfy the both world: the speed and reliability of Static Site Generation (SSG) and the flexibility and up-to-dateness of Server-Side Rendering (SSR).

Benefits

One of the primary benefits of ISR is its ability to keep content fresh. Unlike traditional SSG, where content can become outdated between rebuilds, ISR ensures that the website remains as dynamic and current as needed. It’s particularly useful for sites that have content which doesn’t change every minute but still needs regular updates, like e-commerce product listings or news articles.

Additionally, ISR enhances user experience by improving site speed. Since most of the content is pre-generated and served statically, users experience faster load times, which is crucial for retaining visitors and improving SEO rankings.

Flow

ISR operates on the principle that once a page is generated, it doesn’t need to be rebuilt with every request. Instead, the page can be regenerated at predefined intervals or when specific conditions are met.

Let’s take a look at the real world scenario, having two users, User A and User B with the revalidation interval set to 60 seconds (we will dive into the revalidation below).

Initial State (Time = 0 seconds)

User A visits a webpage for the first time. The ISR mechanism kicks in, generating the page statically as it’s not yet cached. The generated page is served to User A and simultaneously cached for future requests.

First Subsequent Visit (Time = 30 seconds)

User B visits the same page. Since this visit occurs before the 60-second revalidation period, User B is served the cached version of the page that was generated for User A. The page loads quickly for User B, as it is served from the cache.

Revalidation Trigger (Time = 61 seconds)

The 60-second revalidation period is now complete.

When User A visits the page at this time, it triggers the ISR process. While User A is served the current cached version of the page, ISR simultaneously initiates content revalidation in the background.

This ensures that any subsequent visits (whether by User A, User B, or a new visitor) will receive the freshest content, as the page would have been revalidated and cached for future requests.

Further Visits (Post-Revalidation)

Any subsequent visitors, including User A if they revisit, will now be served the updated version of the page from the cache.

This process continues, with the page being revalidated and potentially updated at every 60-second interval.

Key Point

If, since the initial visit at Time = 0 seconds, there are no further visits to the page, then there’s no need to make any additional requests to the server. This approach conserves resources by avoiding unnecessary server requests and revalidate when there’s no traffic to that specific page.

Implementation

To enable the revalidation:

const aboutResponse = await fetch(
  `${process.env.NEXT_PUBLIC_API_ENDPOINT}/about`,
  { next: { revalidate: 6000 }}
);

First, we’ll regenerate the content in MockAPI to trigger a change. Now if you refresh the About page before the 60-second revalidation interval elapses, it will continue displaying the previously cached content.

However, once the 60 seconds have passed and you refresh the page again, you’ll still see the cached content initially, but this action will activate the revalidation process in the background. After this revalidation completes, any subsequent refresh will reveal the updated, fresh content on the About page.

CSR

CSR, Client-Side Rendering, is a web rendering approach where the bulk of the webpage’s rendering process occurs in the user’s browser, rather than on the server. When a user visits a CSR-powered pages, they initially receive a minimal HTML document. The browser then fetches JavaScript files that contain the logic to render the complete page. This process happens entirely on the client side (i.e., in the user’s browser).

Difference from Server-Side Rendering(SSR)

As already discussed in the Server and Client Component article, unlike SSR, where pages are fully rendered on the server before being sent to the client, CSR defers most of the rendering work to the client. In SSR, each page request results in a fully rendered page from the server, ensuring immediate content visibility but potentially increasing server load. CSR, on the other hand, initially serves a bare-bones HTML document, with content and interactivity being added dynamically through JavaScript.

Why We Need CSR

CSR is particularly beneficial for applications that require dynamic user interactions and frequent content updates without reloading the entire page. It enhances user experience with faster page transitions and allows for rich, interactive web applications, akin to native apps. Additionally, since the server only sends minimal initial content, CSR can potentially reduce the server’s load and bandwidth usage (depending on the scenarios and component structure).

Implementation

For CSR, we need to make it to client component by adding ‘use client’ keyword at the top of the page.

To fetch the data, we could use useEffect for the side effect, SWR or TanStack.

Let’s see how we can fetch with useEffect example. We will also add the link so we can test going to another page.

Home

About

Now when we go to home and come back to About page, as you will notice, we will see the Loading… text first and then the About content will show up every time.

This is because the client component should use useEffect to create the side effect meaning it has to wait until the rendering has painted. We will deep dive in to useEffect in the future article, so stay turned.

And as we can see in the Network tab in your DevTool, each new request is made to the server.

Regarding the cache setting, it decides the interaction with Next.js Data Cache, “persists the result of data fetches across incoming server requests and deployments”, but it doesn’t change the rending behaviour.

For improved handling of client-side data fetching, I strongly suggest exploring TanStack or SWR. These libraries offer enhanced caching, revalidation, and additional fetching capabilities that are more suited for client-side data management. Frontendly is using TanStack and I am going to dive into TanStack in the future article.

Route Segment Config

While using the fetch() function’s cache option offers one approach, there are alternative methods available with the Route Segment Config.

Route Segment Config provides flexibility in handling cache and page generation strategies in NextJS, especially when tools like Apollo Client are used, making the traditional fetch() function’s cache option less relevant. Frontendly, for example, utilises GraphQL along with Apollo Client and use the Rout Segment Config.

The default setting for this config is auto, which optimises caching as much as possible while still allowing components to have dynamic behaviour.

export const dynamic = 'auto';

Here’s a quick guide on configuring different types of page rendering in NextJS using Route Segment Config.

SSG

export const dynamic = 'force-static';

SSR

export const dynamic = 'force-dynamic';

ISR

export const revalidate = 6000;

For additional configuration options and more detailed explanations, please refer to the doc page here.

Fetching Blog Pages

So far we had a look at the example with About page, but now let’s take a look at the Blog pages and how each data fetching method works based on what we have learnt so far.

For the blog pages, we will create two routes, /blog and /blog/[blogId]. The /blog page will list the blog pages and /blog/[blogId] which is using the dynamic routes, will show each blog post.

First, let’s create blog data.

Blog Data in MockAPI

To create the blog data, click the New resource button and add the schema.

Once created, update the number of blog posts like 50.

You can now fetch the blog data by accessing the URL https://[project-secret-key].mockapi.io/api/v1/blog

/blog

Let’s create a blog folder and page.tsx file.

Below is the code snippet that lists blog titles with their corresponding links. Given our frequent publication of new posts, this page utilises ISR with a revalidation period set to 60 seconds.

As a result, the blog list will be displayed, having links to each blog article.

/blog/[blogId]

Now let’s create a page for blog content. For this purpose, we’ll use the Dynamic Routes to construct routes based on the blog data.

To achieve this, we establish a dynamic segment by placing a name within square brackets, located within the blog folder.

This dynamic segment enables us to accept a value, facilitating the retrieval of the appropriate data.

For example, accessing a blog item with the blog id of 1 would appear as /blog/1, from which we can extract the ID value of 1. Let’s explore how this works.

From the above code, blogId is obtained from the URL’s dynamic segment through the dynamic routing feature, passed into the BlogContentPage component as part of its props, and then used to fetch and display specific blog content.

Great, now we can fetch and display the blog content with ISR. However, up until here, NextJS doesn’t know how many blog articles are, so when you visit each blog post for the first time which hasn’t kicked in ISR so no cached version yet, we will see it has to fetch first and display the content.

Now when we build, we will see the blog content page is SSR – server side rendered.

To improve this by providing the pages as cached version (SSG), we will utilise generateStaticParams.

generateStaticParams()

The generateStaticParams statically creates routes at application build time, which means when the application runs, it will be called first.

The main benefit it provides is its efficient data fetching capability. When data is fetched (by fetch request) within this function, these requests are automatically memorised. As a result, any fetch request repeated across various generateStaticParams, Layouts, and Pages with identical arguments is executed just once, leading to reduced build time.

Let’s take a look at the code example and dive into how to use generateStaticParams().

First, let’s add generateStaticParams() as async function and also export it.

export async function generateStaticParams() {

}

Next, we’ll fetch the list of blogs. Later we’ll return an array of objects from this response, with each object representing the dynamic segments populated for a specific route. Then the response is converted to a JSON object using response.json(). This operation is also awaited, so the execution pauses until the conversion is complete.

export async function generateStaticParams() {
  const blogListResponse = await fetch(
    `${process.env.NEXT_PUBLIC_API_ENDPOINT}/blog`
  );

  const blogList = await blogListResponse.json();
}

Now, for testing purposes, we’ll limit our scope to the first 10 blog entries. Our goal is to verify if we can apply SSG to these initial 10 blogs specified in the generateStaticParams().

export async function generateStaticParams() {
  const blogListResponse = await fetch(
    `${process.env.NEXT_PUBLIC_API_ENDPOINT}/blog`
  );

  const blogList = await blogListResponse.json();

  const firstTenBlog = blogList.splice(0, 10); // For testing purpose only
}

Lastly let’s return an array of object which contains the blogId. This blogId is also used as the dynamic segment for the blog page (/blog/[blogId]).

export async function generateStaticParams() {
  const blogListResponse = await fetch(
    `${process.env.NEXT_PUBLIC_API_ENDPOINT}/blog`
  );

  const blogList = await blogListResponse.json();

  const firstTenBlog = blogList.splice(0, 10); // For testing purpose only

  return firstTenBlog.map((blog: { id: string }) => ({
    blogId: blog.id.toString(), // this has to be string
  }));
}

Now, when we build it again, the first 10 blog posts are statically generated (SSG), providing us with cached versions. Therefore, when you run yarn start, you’ll notice immediate access to these pages.

Now, considering we have 50 blog pages numbered from 1 to 50, let’s explore what occurs when we access a page beyond the first 10, say page 25. In this scenario, the page will be rendered using SSR, fetching and caching the data on the first visit. On subsequent visits, the page loads from the cache, significantly speeding up access. This functionality is facilitated through the use of dynamicParams.

dynamicParams

The dynamicParams controls what happens when a dynamic segment is visited that was not generated with generateStaticParams. By default, it’s true meaning dynamic segments not included in generateStaticParams are generated on demand. The false means dynamic segments not included in generateStaticParams will return a 404.

export const dynamicParams = true // true | false;

Now what happens if we try to access the page outside the 50 blog range, such as /blog/100?

It will return an empty data. To better handle this, we could show not-found message. To do that, we will first check if we received the blog.

import { notFound } from 'next/navigation';

...

const BlogContentPage = async ({ params }: BlogContentProps) => {
  const blogId = params.blogId;
  const blogArticle = await fetchBlogById(blogId);
  
  if (!blogArticle.id) return notFound();
  
  return (
    ...
  );
};

export default BlogContentPage;

export async function generateStaticParams() {
  ...
}

If no id is found from the blogArticle, then we will return notFound function.

This is the default NextJS 404 design. Let’s customise it.

To do that, we will create new file called not-found.tsx under the [blogId] folder.

And here is an example code.

const NotFound = () => {
  return Oh no, we couldn't find the blog article.;
};

export default NotFound;

In conclusion

In this article, we learned about the various rendering strategies in Next.js, including SSG, SSR, ISR and CSR, along with their respective data fetching techniques. Understanding and applying the right strategy ensures the creation of fast, scalable, and engaging web applications that meet modern web development standards.

I hope this article’s helpful in guiding you to choose the right rendering strategies for your NextJS projects. If you have any questions, please don’t hesitate to contact me on LinkedIn here.