8 min read

Next.js is a React framework that supports pre-rendering. Instead of having the browser render everything from scratch, Next.js can serve pre-rendered HTML in two different ways.

With Server-side Rendering (SSR), Next.js pre-renders the page into HTML on the server on every request. TTFB (Time to first byte) is slower, but your data is always up-to-date.

With Static Generation (SSG), Next.js pre-renders the page into HTML on the server ahead of each request, such as at build time. The HTML can be globally cached by a CDN and served instantly.

Static Generation is more performant, but because pre-rendering happens ahead of time, the data could become stale at request time.

Fortunately, there are ways to work around this issue without rebuilding the entire app when the data is updated. With Next.js, you can use Static Generation for maximum performance without sacrificing the benefits of Server-side Rendering.

In particular, you can use:

Incremental Static Generation: Add and update statically pre-rendered pages incrementally after build time.

Client-side Fetching: Statically generate parts of the page without data, and fetch the data on the client-side.

To demonstrate, let’s use a hypothetical e-commerce Next.js app as an example.

An e-commerce app might have the following pages, each with different data requirements.

About Us: This page shows the company information, which will be written directly in the app’s source code. No need to fetch data.

All Products: This page shows the list of all products. The data will be fetched from a database. This page will look the same for all users.

Individual Product: This page shows each individual product. Like the All Products page, the data will be fetched from a database, and each page will look the same for all users.

Shopping Cart: This page shows a user’s shopping cart. The data will be fetched from a database. This page will look different for each user.

One of my favorite features of Next.js is per-page configuration for pre-rendering. You can choose a different data fetching strategy for each page.

For our e-commerce app example, we’ll use the following strategy for each page. We’ll explain how they work shortly.

About Us: Static Generation without data.

All Products / Individual Product: Static Generation with data, and then improve upon it using Incremental Static Generation.

Shopping Cart: Static Generation without data, combined with Client-side Fetching.

If a page does not require fetching external data, it will automatically pre-render into HTML at build time. This is the default for Next.js pages. Let’s use this for the about page, which has no data requirements.

Create a file under the pages directory and export only the component.

Next, let’s create a page showing all products. We want to fetch from our database at build time, so we’ll use Static Generation.

Create a page component that exports a getStaticProps function. This function will be called at build time to fetch external data, and the data will be used to pre-render the page component.

getStaticProps is run on our build server (Node.js environment), so the code will not be included in the client-side JavaScript bundle. This means you can directly query your database.

Your e-commerce app needs a page for each product with a route based on its id (for example, /products/[id]).

In Next.js, this can be done at build time using dynamic routes and getStaticPaths. By creating a file called products/[id].js and having getStaticPaths return all possible ids, you can pre-render all individual product pages at build time.

Then, you can fetch data for the individual product from the database. We can use getStaticProps again by providing the id at build time.

Now, suppose your e-commerce app has grown significantly. Instead of 100 products, you now have 100,000. Products get updated frequently. This poses two problems:

Pre-rendering 100,000 pages at build time can be very slow.

When product data is updated, you’d only want to modify the affected pages. We can't have a full app rebuild every time a product is modified.

Both of these problems can be solved by Incremental Static Generation. Incremental Static Generation allows you to pre-render a subset of pages incrementally after build time. It can be used to add pages or update existing pre-rendered pages.

This allows you to use Static Generation for maximum performance without sacrificing the benefits of Server-side Rendering.

If you have 100,000 products and pre-rendering all pages at build time is too slow, you can lazily pre-render the pages.

For example, suppose that one of those 100,000 products is called product X. Using Next.js, we can pre-render this page when a user requests the page for product X. Here’s how it works:

A user requests the page for product X.

But we haven’t pre-rendered this page yet. Instead of rendering 404, Next.js can serve a "fallback" version of this page (for example, show a loading indicator).

In the background, Next.js will render the product X page. When that’s done, the loading page will be swapped to the product X page.

The next time someone else requests the page for product X, the pre-rendered product X page will be served instantly, just like regular static generation.

To enable this behavior, you can specify fallback: true in getStaticPaths. Then, in the page itself, you can use router.isFallback to see if the loading indicator should be displayed.

We’ve created a demo of this behavior here using Twitter as the data source.

When product data is updated, you don’t want to rebuild the entire app. You only want the affected pages to change.

For example, suppose that at build time, we’ve pre-rendered the page for product Y. At some point, the data for product Y gets updated.

Using Next.js, we can pre-render this page again after some interval. Here’s how it works:

Next.js can define a "timeout" for this page — let’s set it at 60 seconds.

The data for product Y is updated.

When the page for product Y is requested, the user will see the existing (out of date) page.

When another request comes in 60 seconds after the previous request, the user will see the existing (out of date) page. In the background, Next.js pre-renders this page again.

Once the pre-rendering has finished, Next.js will serve the updated page for product Y.

This approach is called Incremental Static Regeneration. To enable this, you can specify revalidate: 60 in getStaticProps.

Inspired by stale-while-revalidate, this ensures traffic is served statically, and new pages are pushed only after generating successfully. A small number of users may get stale content, but most will get the latest content, and every request will be fast because Next.js always serves static content.

Both adding and updating pages are fully supported by both next start and the Vercel Edge Network out of the box.

Some pages, like the shopping cart page, can only be partially pre-rendered ahead of a request. Because the items on a shopping cart are unique to each user, you must always render them at request time.

You might think this is when you opt for Server-side Rendering, but that’s not necessarily the case. Instead, for better performance, you can do Client-side Fetching on top of Static Generation without data:

Pre-render the page without data and show a loading state. (Static Generation)

Then, fetch and display the data client-side. (Client-side Fetching)

For fetching data on the client-side, I recommend using the data fetching library called SWR. It handles caching, revalidation, focus tracking, and more.

Using one of the Static Generation strategies we’ve discussed, you can gain the following benefits:

Static is consistently and predictably fast.

Pre-rendered HTML files can be cached and served by a global CDN.

Static is always online.

Even if your backend or data source (e.g. database) goes down, your existing pre-rendered page will still be available.

Static minimizes backend load.

With Static Generation, the database or API wouldn’t need to be hit on every request. Page-rendering code wouldn’t have to run on every request.

If you want to use Server-side Rendering (pre-render a page on the server on every request) with Next.js, you can. To use this feature, you can export a function called getServerSideProps from a page, just like getStaticProps. Server-side Rendering is also supported when deployed to Vercel.

However, by using Server-side Rendering, you’ll give up on the benefits of Static as mentioned above. We suggest trying Incremental Static Generation or Client-side Fetching and see if they fit your needs.

Fetching data is only half the equation. Your app might need to write data back to your data source. For our e-commerce app, adding an item to the shopping cart is a good example of this.

Next.js has a feature called API Routes for this purpose. To use this feature, you can create a file inside the pages/api directory, which creates an API endpoint we can use to mutate our data source. For example, we can create pages/api/cart.js, which accepts a productId query parameter and adds that item to our cart.

Inside our API route, we export a request handler, which receives a request and returns a json response.

API routes allow us to write to external data sources securely. Using environment variables, we can include secrets for authentication without exposing the values client-side.

API routes can be deployed as Serverless Functions (which is the default when you deploy to Vercel).

With Next.js, you can use Static Generation for maximum performance without sacrificing the benefits of Server-side Rendering. For more information, please refer to the Next.js documentation.

Learn Next.js

Pre-Rendering

Data Fetching

API Routes