Published on July 17, 2019 Last modified on July 09, 2021
Static site generators
Traditionally, this is what happens behind the scenes when a user visits a page in your site: the user makes a “request” by either clicking on a link to your page, or directly inputting your page’s URL in the browser. The request goes to your web server, which then builds an HTML page out of the content in your database, then serves such HTML page to the browser where your user can view and interact with it.
Static site generators, on the other hand, does the “building of HTML page” part before the user even requests for it, making the page readily available when the user actually does.
There are many site generators available for use today, the most popular of which are Hugo, Jekyll, and Gatsby.
We’ll focus on discussing Gatsby but you can also check out these other options to learn more.
React is known for building fast and performant sites, but it’s also known to present a problem for SEO.
Gatsby acts as a happy medium by providing the same performance benefits of React, but also eliminating the issue that it presents with indexing.
Basically, Gatsby uses React to create “components” (i.e., the building blocks that compose the sections of a React page) from your data, then builds static HTML/CSS/JS files from such components, allowing your page to be “readable” by crawlers.
Gatsby has only been around for about four years, and even then it only started gaining popularity in the past year or so.
Now it’s a new buzzword in web development because of how websites built using Gatsby are always blisteringly fast.
1. Gatsby pre-builds HTML pages then serves them in one go when a user makes a request, skipping the part where the web server has to read the database and only then build the HTML out of the data provided.
Think of it as a ready-made fast food order served right away compared to a restaurant meal that has to be prepared from scratch—except with Gatsby, it’s the same “food” but delivered faster.
2. It’s not only the initial page loading that’s fast, but subsequent page navigation as well.
Once you visit a page in a Gatsby site, it also starts to pre-load the other pages in the background, making the overall user experience smoother with switching from page to page done in a snap.
3. Performance is built-in to the Gatsby framework.
In fact, most of the little tips we’ve mentioned above are already done automatically by Gatsby—take it from Gatsby’s founder Kyle Mathews himself, who said he designed Gatsby “with the goal that when using it, it’d be really, really hard to build a slow site.”
On its own, Gatsby doesn’t have an interface for managing content.
Instead, what it does is build pages based on data pulled from another source where content is initially entered and managed, like content management systems (CMS), product information management (PIM) systems, markdown files, CSV, JSON, databases, APIs, and the list goes on.
In fact, you could even have your data in a simple Excel file and publish it as a website using Gatsby.
Of course, there are configurations to be set up and the actual user interface to be designed, but the general idea is that Gatsby can pull data from anywhere and help you deliver it quickly to your users.
Using headless CMS with Gatsby
Since Gatsby in itself doesn’t have a “backend” to speak of, or a place where you can add and edit your data, you can consider using a “headless” CMS to do the job.
In a nutshell, a headless CMS strips away the frontend layer of your site (i.e., the “head”) and leaves only the backend technology (hence the term “headless”).
This is as opposed to how a CMS is usually set up—where the system provides a platform for managing your content (i.e., the backend) and handles how that content is displayed to your end users (i.e., the frontend).
When you go the headless route, you are essentially using the CMS only as a place where you manage and edit your content, but the publishing is done through a different service or platform—in this case, site generators like Gatsby.
Most popular CMS like WordPress and Umbraco can be “converted” to headless, so to speak, and use it along with Gatsby by developing an Application Programming Interface (API) that integrates the backend to Gatsby.
This sort of “re-routes” the publishing of the data so that instead of it being delivered by the frontend component of the CMS, it’s instead sent to Gatsby, which will then work its magic to deliver the content in a snap.
(Umbraco Heartcore is Umbraco’s headless version. For WordPress, there are website plugins like this one that helps convert it to a headless CMS.)
Aside from this, there are also CMS options that are headless at the outset—they’re built without a frontend and are designed to easily integrate with static site generators and other publishers without the additional development that turning a traditional CMS to headless requires. Some examples are Contentful, Storyblok, Butter CMS, and Contentstack.
Aside from all the performance benefits, using Gatsby and/or a headless CMS also provides an extra layer of security for your data due to the HTML pages of the frontend being distinct from your data in the backend.
If you are an omnichannel brand, headless also makes it easier to publish to any platforms by using only one CMS to deliver content not just to your website, but to other platforms as well such as mobile apps, smart watches, and Internet of Things (IoT).
On the other hand, Gatsby makes it easier to publish data from any data sources you may have aside from your CMS.
Mak, one of our project managers for Umbraco, had only good things to say about his experience using Gatsby and headless Umbraco. “[The main benefit is that] you can spend your development time on more important things and not worry too much about performance, as Gatsby will take care of it for you. Also, since Gatsby is built with React, there’s a ton of tools and an extensive library available for us developers to use, as well as a huge support from the community.”
Now Gatsby is great and all, but you’re probably wondering how much development time it will cost.
For websites built from scratch, Mak has observed that the project duration is similar to projects built using traditional CMS—considering, of course, that your developer already has experience with using React and/or Gatsby and doesn’t have to learn the system and technology first.
However, when turning an existing CMS-based site to Gatsby, many factors come at play that make it difficult to provide an exact time estimate.
“The first thing to consider is whether the CMS [the client] is currently using can be turned, because if not, the only thing we can use is the frontend, and only then use it as a reference. It will be like basically starting from scratch,” Mak says. “Another factor is the complexity of the frontend features. It all really depends on each site and how it’s customized.”
Going the headless + Gatsby route is something that you will need a dedicated development team for, and the implementation is for sure not something that can be done in a snap. Again, depending on your website, it may well be a full-blown development project.
Still, this option is worth considering for all the performance benefits that it could bring to your site.
If you’re interested in learning more about headless and Gatsby, and how these can help your site, contact us and one of our project managers can help you understand it better in light of your specific website needs.