Tari Wiencke Logo
← Back to articles
Next.jsWeb DevelopmentFrontend

Next.js Rendering Strategies

February 14, 2024

Next.js Rendering Strategies

Introduction

In this essay, I want to look at all rendering strategies from Next.js and put them into comparison. Recently, I looked at the history of frontend web development and learned the basic concepts of server and client-side rendering. Both design patterns come with many applications but also have disadvantages. Modern frameworks like Next.js bring together those strategies and let the programmer choose what to use. Each approach has its place and best practices to implement.

Let's start with the basics by defining what rendering is: Rendering is turning code into content users can see and interact with. Rendering strategies are different approaches to this challenge. They differ in when this rendering happens and where.

Where

Rendering can happen on the server machine and then be sent to the client. That is called Server-Side Rendering (SSR). With this approach, the server does the work and database requests, and the like are made on the server side. The client receives a static HTML file.

The other option is Client-Side Rendering (CSR). Here, the content gets rendered in the browser with the help of JavaScript. That makes interactivity and responsiveness possible but can lead to slower initial load times because of multiple round trips to fetch necessary JavaScript files and make database calls.

When

When it comes to Server-Side Rendering, you can either do the rendering at build time or at request time (or in-between). When doing it at build time, it refers to Static Site Generation (SSG), which pre-renders the pages and stores them as static HTML files on the server.

When generating the HTML file at request time on the server, we call that Server-Side Rendering (SSR), though SSG gets rendered on the server as well. The difference lies in the time of rendering.

Matrix

Choosing between rendering strategies is about answering those two questions: Should this process happen on the server side or on the client's machine? If we do it on the server, when should it happen? This can be laid out in a matrix:

Rendering Strategies Matrix

So let us explore those strategies in detail to find out about their use cases. They all have their pros and cons, and modern web development is about choosing to optimize SEO, performance, and user experience.

Static Site Generation (SSG)

SSG pre-renders pages at build time and stores plain HTML files on the server. It is the classic approach of serving webpages to the user. Database calls and the like are made at build time and do not refresh until a rebuild occurs.

It is ideal for pages that don't change frequently. It builds just once and lives as optimized HTML files on the server. Hence, it reduces server load and infrastructure costs. It doesn't require a runtime and can be hosted with simple web hosting solutions. It has excellent SEO performance.

Content updates require a new build and deployment, and build times can increase with a large number of pages. To shorten the initial build time and incorporate changes without rebuilding, consider ISR.

DOCS: https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation

Incremental Static Regeneration (ISR)

ISR allows partial re-rendering without rebuilding the whole application. It also pre-renders pages, but you can implement different cache invalidation strategies. You can also choose to not render at build time, but to cache on first request. That means the initial build takes less time.

It allows on-demand content updates without a full rebuild: "Regenerate this page, when I make changes to this database."

DOCS: https://nextjs.org/docs/pages/building-your-application/data-fetching/incremental-static-regeneration

Server-Side Rendering (SSR)

SSR does not pre-render pages at build time but at request time. Therefore, the user always gets served with fresh, up-to-date content. It still works well for SEO because the content-rich HTML files are sent to the client.

It is slower than SSG or ISR, and Time to First Byte (TTFB) can be lacking. The server first needs to render the whole page before sending it to the client. It consumes more server resources than SSG and requires a runtime in the first place.

DOCS: https://nextjs.org/docs/pages/building-your-application/rendering/server-side-rendering

Client-Side Rendering (CSR)

CSR uses the browser to render the content. JavaScript bundles are served to the client with instructions on how to render the page. It brings the possibility to manipulate HTML after receiving the static HTML file. Real-time interactions with external data and transitions between application states without refreshing the page can be realized.

Since JavaScript bundles must be downloaded, this can slow down the loading of the website. Furthermore, it can bring down SEO rankings and Core Web Vitals.

DOCS: https://nextjs.org/docs/pages/building-your-application/rendering/client-side-rendering

Partial Prerendering (PPR)

PPR combines static and dynamic components. You can wrap specific code in React Suspense to enable SSR or CSR while keeping the rest in SSG. Since this feature is still experimental in Next.js 15, I will leave this one out for now.

DOCS: https://nextjs.org/docs/app/building-your-application/rendering/partial-prerendering

Choosing the Right Strategy

When deciding on a rendering strategy, it might be helpful to answer the following questions:

  • How often does the content change? SSG is good for static content, ISR is great for sometimes changing content, and SSR or CSR is best for real-time data.
  • Is the page critical for SEO? Good Core Web Vitals are easier to achieve with SSG and SSR.
  • Does the content vary by user? If you need personalized content, you need CSR or SSR. SSG does not allow personalization.

As a rule of thumb, you can use these basics:

  • Default to SSG whenever possible.
  • Use CSR only for responsive interactions and not for fetching external data.
  • Use ISR cache invalidation strategies for periodic changes.

Choosing the right rendering strategy is crucial for optimizing performance, SEO, and user experience. Next.js offers several approaches that differ in where and when the HTML should be rendered. With that, I hope to bring some clarity to this confusion of concepts.

Resources