Gatsby is a meta-framework built on top of the React framework, offering solutions to inherent pitfalls found in client-side single page applications (SPAs) built with React. Gatsby was built with two goals in mind: SEO performance and developer experience.
This article will mainly focus on Gatsby SEO optimization, but also touches on the developer experience.
TL;DR: Gatsby SEO & Quick Links
What Problems does Gatsby Solve?
As the web evolved, we began to see pages go from static to dynamic, offering an ever richer user experience (UX) by including dynamic data and client side coding. This evolution has resulted in the inception of many client-side frameworks, such as ReactJs.
Why is Gatsby Ideal for Search Engine Optimization?
Gatsby helps achieve great SEO in a number of ways. Offering a combination of features is a necessary requirement to satisfy the multifaceted conditions set forth by Google.
Gatsby is ideal for SEO because it covers so many of these related factors out of the box, giving developers the freedom to concern themselves with design and functionality rather than SEO performance enhancements.
SSG vs SSR | What They Are and How Gatsby Uses Them
Up until recently, Gatsby was used only as a static site generator, leaving frameworks like NextJs SEO to dominate the SSR market.
However, with the release of Gatsby v4, we can now utilize Gatsby for both SSG and SSR. Let’s take a closer look at what both of these technologies bring to the table.
Static site generation (SSG) is a relatively new technology that piggybacks on some pretty old concepts. The web began with static content, served to clients as pre-built HTML files that didn’t have much functionality; hence the name “static”.
In a way, Gatsby brings us back to yesteryear, offering a way for us to serve static pages while maintaining most of the great features found in dynamic SPAs.
Gatsby SSG allows developers to continue using the React framework they’ve come to know and love, but handles things differently when it comes to putting things into production. When developing with Gatsby SSG, static HTML pages are generated at build time. The workflow goes something like this:
- A developer codes up a website using Gatsby, which is very similar to coding a React, but better for React SPA SEO.
- The developer runs a “build,” which renders all the React code into actual HTML files.
- The generated HTML files are then served from a hosting provider, offering pre-built and easy to consume web pages.
SSG is great, but it’s not ideal for data intensive sites that update content frequently. Every time data is added or changed, a new build must be run in order to generate the new HTML pages. This is why SSG is usually chosen for optimizing small blog sites and small business pages.
For sites more dynamic in nature, we’ll need to take a look at server side rendering (SSR).
Server side rendering was added to Gatsby’s newest release (v4), and is a great addition to an already powerful framework. The inclusion of SSR brings Gatsby a huge step closer to being a complete framework, making it much more capable to handle more complex projects.
SSR offers the same end goal as SSG; faster page loading. However, SSR goes about things in a much different manner. When a page is requested, the server generates the HTML on the fly, rather than having the HTML pages generated at build time.
The workflow will look like this:
- A developer codes up a website using Gatsby, much the same way as they would with an SSG site using Gatsby.
- When coding page components that the developer wants to be rendered on the server, they include a function in the component called getServerData(), which tells Gatsby to render this page on the server on a per-request basis, rather than at build time.
- These components are served as routes on the server. Upon each request, requested data is retrieved using code in the getServerData() function, and only then is HTML generated and sent to the client.
This solution may not always perform as well as SSG sites, but they offer more capability because pages can be built on the fly. This trade-off must be considered when deciding which method is best for your project.
Deferred Static Generation | Gatsby’s Newest Solution
Deferred static generation (DSG) is a new feature offered by Gatsby in v4 to help alleviate one of the pitfalls that come with SSG sites: the high-overhead build process. We won’t go into crazy detail here, because the concept is actually pretty simple if you already understand SSG.
DSG is essentially exactly what the name implies. It defers the generation of static HTML files until the page in question is requested for the first time. So, rather than each page having to be generated at build time, it is requested and cached only after the first user requests it.
Other than the unfortunate user who requests the page for the first time, you will reap all the benefits of SSG, but without having to do a full build after each change to your site. This sacrificial lamb approach isn’t a bad idea, since one slow response probably won’t register much in the eyes of Googlebot.
Gatsby is known for being a rather opinionated framework, and when it comes to image optimization this is no exception. Image optimization with Gatsby deserves a write-up of its own, but we can do a brief overview in order to understand the basics.
Gatsby defaults to compressing images to the relatively new WebP format, typically offering a minimum 25-35% reduction in image size for modern browsers.
Gatsby offers the ability to optimize images at build time, at run-time, or to pre-optimize images to conserve CPU power. For sites with lots of images, it would be a good idea to set up a pre-optimization script.
- Build-Time Image Optimization: This option applies to sites built with SSG. The Gatsby image components are utilized to optimize each image every time your site runs a build.
- Run-Time Image Optimization: This option applies to sites built with SSR. The Gatsby image components are utilized to optimize page images every time a specific page is requested.
- Pre-Optimized Images: This option allows developers to build scripts that can be executed on demand, optimizing images so they are readily available for whichever Gatsby implementation you choose. Essentially, the images are stored in their optimized form, rather than optimized upon each build or request.
The <head> tag of any HTML page should contain metadata tags that are important for SEO. These tags are analyzed by Google crawlers to determine details about the page for indexing. It can be difficult keeping up with this section of a page because the metadata is page specific.
Each blog post, news article, or company landing page will have its own set of metadata tags specific for that page. The Helmet component allows these tags to be populated dynamically during the build process.
For SSG, the Helmet component generates all of the necessary metadata tags during the build process. For SSR, the Helmet component generates and renders them during each page request.
The meta description is one such tag, and it’s very important that each page have a meta description that describes the content of the page in succinct language. The meta description should be between 155-160 characters, while utilizing keywords that have been researched to help determine relevance for Google searches.
A meta description tag found within the head tag would look something like this:
<head> <meta name="description" content="What we have here is an example meta description. Google will truncate this text around 155-160 characters"> </head>
How Does Gatsby Compare to WordPress SEO Performance?
WordPress is a free, open source content management system built with PHP and MySQL that offers an easy to use plugin architecture and templating mechanism. It’s really popular for its ease of use, and is often chosen for the type of small sites that Gatsby advocates using its framework for.
So how does WordPress measure up with Gatsby? The short answer is that Gatsby can achieve better SEO performance than WordPress in most cases, but the learning curve is much higher for Gatsby.
WordPress offers SEO optimization plugins such as Yoast to help streamline the process of enhancing SEO performance, which can be effective. But WordPress is highly abstracted in order to simplify the development process, which leads to bloated client-side payloads that hinder performance.
The more user-friendly a framework is, the more you lose in the way of performance optimization, which is why WordPress can be limited in this regard.
The folks at Gatsby actually did their own comparison on the two frameworks, found here, which does a pretty good job sizing them up. Or you can read our Gastby js vs Next js article.
GatsbyJs | Overview and Concluding Thoughts
Choosing the right framework for your next project is essential in today’s competitive online market. Google engineers have programmed their crawlers to assign better rank to pages that offer the best user-experience (UX). What determines great UX to Google isn’t always clear, but studying their published web vitals is a great place to start.
The Gatsby framework was built with search engine optimization (SEO) and web vitals in mind, aiming to achieve excellent UX according to the standards set forth by Google.
With this goal in focus, Gatsby helps developers score high vitals with relative ease, offering a streamlined approach to building SEO performant websites with the React framework.
With the release of Gatsby v4, this framework leaves little to be desired and comes highly recommended.