Gatsby has always been known for its prowess for Static Site Generation (SSG), but has recently gained two powerful new page rendering modes that give web developers and site managers even more flexibility and control over their Gatsby sites: Server-Side Rendering (SSR) and Deferred Static Generation (DSG).
We often hear the question: Which page rendering mode should I be using? The answer to that question is the time-worn reply of: It depends.
Let’s kick things off with a discussion about the Gatsby page rendering mode you may already know best: Static Site Generation, or SSG.
When to use Static Site Generation (SSG)
The most familiar page rendering mode to long-time Gatsby users, SSG has no equal when it comes to page load speed and security.
SSG simply means the entire site is pre-rendered into HTML, CSS, and JavaScript files at build time, which are then cached by the CDN and then served to users. This is great for two reasons.
First, because there are no running servers or databases, content gets to the user faster. Second, the static pages provide a layer of security via indirection over any running services you might have – like a database or WordPress instance. With SSG, malicious users will never even know these services exist.
- Register Today! Join us for GatsbyConf on March 2nd and 3rd, 2022
SSG is a great fit for almost any web page that doesn’t change depending on the user – home pages, landing pages, technical documentation, blog content, and so on.
When you push certain kinds of new code to your site, like updating your plugins or changing gatsby-node.js, it will kick off a full site rebuild, and every page on your site rendered using SSG will be regenerated.
If you’re using Gatsby Cloud and Gatsby 4, and you have a couple of hundred pages, this will only be a couple of minutes. However, if you have tens of thousands of pages, it could take 10 minutes or longer. We consider SSG a great default and 90%+ of Gatsby sites should be built fully SSG.
However, there are a couple of scenarios where it doesn’t work as well.
Let’s take an example of a large university news website. They want to have short build times in case there’s urgent, breaking news they need to broadcast to the campus community.
At the same time, they have tens of thousands of pages of old content. They don’t want to be caught in a situation where they are trying to get urgent updates out to their community but are waiting on their build to complete when, at most, a header or footer might have changed.
This site would be a good candidate for….
Deferred Static Generation (DSG)
Introduced in Gatsby 4, DSG is a new page rendering option in the Jamstack world that cuts down long build times. DSG gives developers more options to balance developer experience and user experience. With DSG, Gatsby defers non-critical page generation until a user requests it. This allows the most important pages to be built and deployed to the edge instantly.
This is especially effective with larger sites that have lots of infrequently accessed content (like old blog posts or reference guides). There is no practical reason to generate them on each build (and thus delay the delivery of fresh articles). In this case, you may choose to defer the generation of old pages, and Gatsby will skip them during the build step.
DSG keeps both the performance and security benefits of SSG. Developers comparing Jamstack rendering modes will note that DSG is an implementation of an earlier concept called Distributed Persistent Rendering (DPR).
If you’re interested in employing a data-driven approach to help you decide what pages to render with DSG, Gatsby Senior Software Engineer Lennart Jörgens (@lekoarts_de) has written an article entitled Using Deferred Static Generation with Analytics Tools that explains how to use data from an analytics tool (like Google Analytics) to programmatically defer pages that are not popular and only build your most popular pages as SSG. Lennart’s article will also teach you how to create an analytics tool source plugin and use that to help defer pages on your site.
DSG requires support from the deploy and hosting platform. We have first-class support for DSG in Gatsby Cloud, but this isn’t true for some hosting providers.
When to use Server Side Rendering (SSR)
If you’re introducing features like authentication-gated data, personalization, or A/B testing, server-side rendering is one option you should consider. Introduced in Gatsby 4, Server-Side Rendering is a method of content rendering in which each web page is served to a site visitor at runtime, meaning that a portion of the build process happens on each page request. Because the content is rendered during runtime, visitors will always get the latest version of content directly from the server—though they may have to wait longer for it to display.
There are other options to provide similar levels of functionality. Many times, fetching authenticated data or personalizing content can be done using SSG or DSG with features available in earlier versions of Gatsby, such as client-side rendering and Gatsby Functions.
These methods load 95% of the page first, except for key pieces of data. Jamund Ferguson of PayPal demoed this approach at QCon London in 2019, in slides 54 and 55, or video at 27:30.
- How-To Guide: Using Server-side Rendering (SSR)
However, some developers may find writing SSR pages more natural than these methods, and if you need a consistent layout and want all of your content and data to load at the same time, without any layout shifts or flickering, you should use SSR. SSR gives a more consistent user experience when working with real-time data or user-specific data.
Gatsby’s implementation of SSR uses serverless functions. As a result, SSR, like DSG, requires support from the deploy and hosting platform. We have first-class support for SSR in Gatsby Cloud, but this isn’t true for some hosting providers. A common use-case for SSR is a content site that is adding an authenticated section with user-specific information, like profile pages or personalized dashboards. Another example would be incorporating user-generated content, like comments, that a user would expect to be live immediately after posting.
Conclusion
Gatsby supporting these new rendering modes – DSG and SSR – means that developers can now choose how content is generated, opening up new possibilities for what Gatsby can help build.
A quick closing note: I’d like to thank Sam Bhagwat (@calcsam), Kyle Mathews (@kylemathews), and Ward Peeters (@wardpeet) for their technical editing, commentary, and feedback on this article. You can also follow me on Twitter at @jeffjames3.
Related Reading
- A conceptual guide to rendering options in Gatsby’s documentation
- For an introduction to page rendering modes as a concept, this rendering on the web document written by Jason Miller and Addy Osmani on the Google dev team is a good primer
- Brian Rinaldi of LaunchDarkly compares different Jamstack framework rendering options in his article on Bejamas.io