When to use SSR with Next.js

Learn when to use SSR or SSG with your Next.js application

·4 min read
Cover Image for When to use SSR with Next.js

👋 Hi! Would you like to learn how to build an AI SaaS with Next.js, Supabase and Stripe including a fully working SaaS template? Check out our new course!

Server-Side Rendering (SSR) is a rather foundational concept of rendering HTML pages on the server before sending them to the client. During the SPA-craze of the 2010s, server-side rendered pages were considered obsolete and slow, because web applications built with the SPA architecture offered an easier way to deploy applications, together with the separation of concerns that brought the bulk of the complexity to the client-side.

Nowadays, SSR and transactional web applications are becoming the developers' favorite way to develop modern full-stack applications: that means, the first navigation is rendered by the server, and the subsequent navigations through page pre-fetching and client-side navigations using the History API.

What are the factors that SSR and Transactional Apps possible?

Here are the main factors that helped developers transition to Transactional Web applications:

  1. The evolution of client-side frameworks to support SSR (Next.js, Vue, Remix, Angular Universal, Solid, etc.)
  2. The evolution of PaaS providers that help developers deploy SSR-ready frameworks as easily as using git push: among these is Vercel, which is the leading provider that allows zero-click deployments of many SSR frameworks (despite developing their own!)

When to use SSR?

Server-Side Rendering, as we've seen, is the process of rendering the initial navigation on the server, followed by client-side navigations (eg. without fully reloading the page).

The above brings us to the question: when to use SSR for our application?

The good news is that with many frameworks we have the flexibility to choose when to use SSR (Server-Side Rendering), or SSG (Static-Site Generation). In fact, the Makerkit SaaS boilerplate does exactly that.

SSR is ideal for the internal pages of your application

Many stress about the performance and SEO benefits of server-side rendering your pages (which are valid points), but there's more: SSR can also help you build more dynamic pages with less effort from a developer's perspective.

  1. SEO - The first valid point of using SSR is that it can help the pages that need crawling for SEO reasons
  2. Faster Initial Rendering - The second point is that SSR (compared to CLient-Side Rendering) can help you make your website faster for the initial navigation (FCP)
  3. Better DX (Dev Experience) - Helps developers combine server-side logic for cumbersome interactions on the client-side: for example, displaying a loading spinner every time we fetch data from the server: this can be avoided for the initial navigation by serving a fully-rendered page.
  4. Huge websites - Ideal for displaying thousands (or more!) pages stored in a database that would be too costly or slow to build using SSG

When to use SSG?

SSG (or Static-Site generation) is the process of generating HTML pages statically, i.e. instead of being rendered on-demand by a web server, they're generated as static HTML files that do not change until the next deployment.

SSG pros

The benefits of using SSG for rendering your Next.js application are clear:

  1. Faster - They are faster than SSR-rendered pages
  2. Cheaper - They are cheaper to serve since no server runtime is needed
  3. Easy to Deploy - They are extremely easy to host anywhere (Github Pages, CloudFlare, etc.)

SSG cons

The cons of using SSG with Next.js, instead, are that these pages will use client-side rendering for the dynamic parts, making them not the best choice for various scenarios, for example:

  1. Customizing the user experience
  2. Managing the user's authentication
  3. Slow when building thousands of pages
  4. Not ideal for content that changes quickly

Which pages are ideal for SSG?

So, which parts of the application should be statically generated? For example, in Makerkit, we only server-side render:

  1. The landing pages of the website
  2. The blog and the documentation pages

These pages are ideal because they do not change when the user is authenticated or not, and can potentially be high-traffic pages since they contain informational content that can bring many visitors from search engines: SSG, in this case, helps reduce the costs associated with traffic volume.

Ultimately, we can say that SSG is ideal for informational content that does not change. But what if it changes and you do not want to use SSR? Enter ISR.

ISR can help make static pages dynamic

If you're using Vercel, you can also use proprietary technology and techniques such as ISR (Incremental Static Regeneration). With ISR, you can instruct Vercel to re-generate a page based on a certain time window you can provide (for example, every 1 minute).

ISR is ideal for static pages that need to be continuously updated, such as an eCommerce product page for displaying changes to pricing, availability, reviews, etc.

The main drawback of ISR is that your Vercel bill will increase substantially, so it's something I'd use carefully and only for certain scenarios like the above.

👋 Hi! Would you like to learn how to build an AI SaaS with Next.js, Supabase and Stripe including a fully working SaaS template? Check out our new course!

Read more about Tutorials

Cover Image for Building an AI Writer SaaS with Next.js and Supabase

Building an AI Writer SaaS with Next.js and Supabase

·57 min read
Learn how to build an AI Writer SaaS with Next.js and Supabase - from writing SEO optimized blog posts to managing subscriptions and billing.
Cover Image for Announcing the Data Loader SDK for Supabase

Announcing the Data Loader SDK for Supabase

·8 min read
We're excited to announce the Data Loader SDK for Supabase. It's a declarative, type-safe set of utilities to load data into your Supabase database that you can use in your Next.js or Remix apps.
Cover Image for Adding AI capabilities to your Next.js SaaS with Supabase and HuggingFace

Adding AI capabilities to your Next.js SaaS with Supabase and HuggingFace

·20 min read
In this tutorial, we will learn how to use add AI capabilities to your SaaS using Supabase Vector, HuggingFace models and Next.js Server Components.
Cover Image for Building an AI-powered Blog with Next.js and WordPress

Building an AI-powered Blog with Next.js and WordPress

·17 min read
Learn how to build a blog with Next.js 13 and WordPress and how to leverage AI to generate content.
Cover Image for Using Supabase Vault to store secrets

Using Supabase Vault to store secrets

·6 min read
Supabase Vault is a Postgres extension that allows you to store secrets in your database. This is a great way to store API keys, tokens, and other sensitive information. In this tutorial, we'll use Supabase Vault to store our API keys
Cover Image for Introduction to Next.js Server Actions

Introduction to Next.js Server Actions

·9 min read
Next.js Server Actions are a new feature introduced in Next.js 13 that allows you to run server code without having to create an API endpoint. In this article, we'll learn how to use them.