Gatsby 4: New Rendering Options and Faster Builds

Gatsby 4, released in October 2021, marks a significant shift for the framework. Previously known for static site generation (SSG) with long build times, Gatsby now offers multiple rendering modes and performance improvements that position it as a more direct competitor to frameworks like Next.js. The Gatsby team reports the largest signups on Gatsby Cloud following the release, citing faster builds and new rendering options as key drivers.

Deferred Static Generation (DSG)

One of the longstanding criticisms of Gatsby has been slow build times, especially as sites grow. While incremental building—only rebuilding new or changed pages—helped, the initial cache-less build remained a bottleneck. Deferred Static Generation (DSG) offers a solution by letting you designate specific pages to "defer." These pages are not built during the main build process; instead, they're generated upon a user's first request. After that initial request, the page is cached on the CDN and behaves identically to any SSG page.

This is particularly useful for older or rarely visited pages that don't need to be regenerated with every deployment. DSG requires a running server, which is a departure from Gatsby's traditional server-less architecture, but it provides more flexibility. There's no SEO penalty either: a page delivered via DSG is server-side rendered only for the first request and acts as a static page 99.9% of the time thereafter.

Server-Side Rendering (SSR)

Gatsby 4 also introduces support for true Server-Side Rendering (SSR), a feature long available in Next.js. SSR builds a page each time a user requests it, which is valuable for creating personalized content based on who is visiting. With this addition, Gatsby developers now have access to all four major rendering strategies: SSG, DSG, SSR, and Client-Side Rendering.

Build Performance Improvements

Parallel Query Running

Gatsby 4 restructures its data layer to address build speed. Query running—the process of pulling data from the data layer into pages—has historically accounted for roughly 40% of total build time and could only use a single CPU core. Gatsby 4 replaces its Redux-based data store with an in-memory solution using lmdb-js, described as an ultra-fast key-value database interface for Node.js and Deno. This architectural change enables query execution across all available CPU cores, dramatically reducing build times.

DX Optimizations

In addition to the headline features, Gatsby has made numerous tweaks to infrastructure and configuration aimed at reducing build and development server start times. These changes, delivered across Gatsby 3 updates and finalized in Gatsby 4, improve the developer experience by reducing the wait times associated with restarting the dev server.

Gatsby Cloud

Hosting and Configuration

Gatsby Cloud is a deployment service designed exclusively for Gatsby sites. Unlike Netlify or other hosting platforms, it cannot host Next.js, Vue, or other frameworks, but it is heavily optimized for Gatsby's unique requirements. A key advantage is the near-zero configuration required; Gatsby Cloud supports all of Gatsby 4's new rendering features out of the box.

The service integrates with GitHub, GitLab, or Bitbucket repositories and supports automatic deployments on branch changes. Webhooks are available for triggering production builds when external data, like a CMS, changes. The platform also includes tools for previewing changes via a shareable URL and provides a Lighthouse report after each finished build.

Enhanced Speed

Gatsby Cloud leverages Gatsby's optimisation features, including incremental builds, parallel query running, and caching, to keep build times very low. On a 10,000-page site, a CMS-triggered update reportedly takes only about 10 seconds. Deployment time—pushing the built site to the CDN's edge—has also been improved, averaging 2-5 seconds for a medium-sized site that might otherwise take several minutes on other services.

Serverless Functions

Gatsby Functions allow you to add an Express-like backend to your Gatsby project for tasks such as creating an API, authenticating users, or handling form submissions. While they can be deployed to other platforms, integration with Gatsby Cloud is particularly simple. This is valuable in cases where multiple frontend applications need to access shared data, allowing you to decouple the backend and communicate via an API while keeping everything hosted in one place.

Netlify as an Alternative

Both Gatsby Cloud and Netlify offer similar feature sets and have free tiers. The main practical difference is that Gatsby Cloud only works for Gatsby projects, while Netlify can host a wider range of frameworks. If you are already dedicated to Gatsby, Gatsby Cloud's optimizations make it a strong choice.

Gatsby 4 vs. Next.js

With SSR now in Gatsby, a long-standing feature gap has closed. Today, a developer can achieve similar user experiences with either Gatsby or Next.js. The realistic differentiators have shifted to areas where each framework holds a distinct advantage:

  • Gatsby: Offers Deferred Static Generation, a built-in data layer for sourcing queries, and a large plugin ecosystem providing out-of-the-box support for CMSs, e-commerce, analytics, and more.
  • Next.js: Provides Incremental Static Regeneration and has Server Components in alpha development.

Given the overlapping functionality, developer experience becomes a primary factor in choosing between the two. Gatsby's centralized data layer and its ample plugin library give developers immediate resources to start a project, saving significant time and setup effort.

What Gatsby 4 Brings to the Table

Gatsby 4 represents a significant shift in how the framework approaches content delivery. The headline additions are two new rendering options — DSG (Deferred Static Generation) and SSR (Server-Side Rendering) — which join the existing SSG (Static Site Generation) model. This means Gatsby is no longer purely a static site generator; it now supports dynamic rendering strategies that were previously only available in meta-frameworks like Next.js.

With DSG, you can defer the generation of non-critical pages until requested. This is handled via the new defer option in createPage. Developers mark certain pages as deferred, and Gatsby generates them on-the-fly at runtime, caching the result. This reduces build times for large sites by avoiding the generation of every page upfront.

SSR in Gatsby 4 allows you to server-render pages at request time. This unlocks the ability to use request-specific data, cookies, or authorization headers. The power comes from having one codebase that supports both static and dynamic behavior. Gatsby uses a unified data layer, so you can query data with GraphQL for SSG/DSG pages and use regular Node.js for SSR logic. The getServerData function is the official API to resolve server-side data before React renders.

Under the Hood: The New Rendering Architecture

The internal architecture was rebuilt to support these options. Gatsby now implements renderPage as a unified function that runs in all three rendering modes. For DSG and SSR, it is invoked in a serverless function in Gatsby Cloud, while SSG runs it at build time. This ensures a consistent API surface between the modes.

The global __SERVER constant flag was split for granular control — __GATSBY_SSR is now used for server rendering contexts, and __GATSBY_DSG for deferred generation. However, Gatsby still recommends the platform-agnostic approach using exports conditions in package.json, because the internal flags are not supported across all bundlers or serverless environments.

Gatsby 4 also ships with feed support, a built-in RSS/Atom generator, simplifying one of the most common site requirements. The configuration is moved from a plugin into the core Gatsby config file with a cleaner feed option that supports content types, filters, and custom serialization.

How Gatsby 4 Compares With Next.js

While Gatsby has long been compared to Next.js, the two have different strengths. Next.js dominates the SSR ecosystem and is often praised for its developer experience. Gatsby 4 now closes that gap by offering similar hybrid rendering modes, but it still doesn’t outpace Next.js's advantages in expressiveness and community adoption.

That said, the new rendering modes make Gatsby a more considered choice for projects that need flexibility between static and dynamic content — without abandoning a unified data layer and the performance benefits of static generation where possible.

In short, Gatsby 4 is not a replacement for Next.js, but it is a compelling option for teams that want static and dynamic rendering side-by-side in a single framework.