When to use SSR with Next.js

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

next

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.

Some other posts you might like...
Choosing the best hosting provider for your Next.js applicationIn this post, we'll show you how to choose the best hosting provider for your Next.js application.
Next.js API Routes: The Ultimate GuideLearn how to build robust, secure, and efficient API endpoints in Next.js. This comprehensive guide will walk you through the critical best practices for creating robust, secure, and efficient API endpoints in Next.js.
Building a Real-time Notification System with Supabase and Next.jsLearn how to build a complete real-time notification system using Supabase and Next.js. Includes live updates, dismissible notifications, and Row Level Security.
How to Write Secure and Type-Safe Server Actions in Next.jsA comprehensive guide to using enhanceAction in Next.js applications. Learn to implement authentication, Zod validation, and error handling in your Server Actions
Next.js Version Control: Implementing Auto-Updates in Your ApplicationLearn how to implement automatic version updates in your Next.js application to prevent stale clients and API conflicts. Includes ready-to-use code examples and best practices
Next.js App Router: Project StructureThis guide will help you with the architecture and structure of a production-grade Next.js App Router project.