Gatsby: a modern tool for creating fast websites 

By Max Ikaheimo

28th November, 2022

Gatsby used to be the new kid on the block, but it’s not anymore. Now it’s a well-established meta-framework with 57,000+ live websites and ~23% market share among static site generators (SSG). 

What makes Gatsby so popular is its technology choice. Websites created with Gatsby are pre-rendered; therefore, they can quickly appear on the screen. And data loading is made simple with the comprehensive GraphQL layer.

Despite Gatsby nudging developers to adhere to specific technologies, it is flexible enough: with the help of plugins, you can employ any data fetching protocol or rendering method you like. 

Before we go deep into what is Gatsby, we first need to explore why to use static sites. 

In this post:

A quick intro into static site generators

In the past, a developer would write a static website by hand with HTML/CSS and some magic. But creating and maintaining such a website took a lot of work, especially for non-developers. Then WordPress (WP) came in, making website creation super simple. 

Because WP was so convenient, static sites were forgotten for a while. But then developers realized WP could be too heavy for specific needs. So, static sites returned to the scene, but this time not crafted by hand but generated from markdown files and templates. The corresponding tool was called static site generator (SSGs).

A static site generator takes a bunch of blog posts and combines them with images into static HTML pages. These are stored on the server and sent to clients upon request. Even without a content management system (CMS), users can add new content by adding a .md file.

First-generation SSGs, like Jekyll or Hugo, were perfect for building non-interactive websites. That’s because of their short load times!

Load times explained

Static site generation is a rendering strategy that scores exceptionally well on page load times. Let’s look at the modern-day rendering methods and compare them on the load speed to ground the statement. 

If your website relies on client-side rendering (CSR), browsers execute plenty of JavaScript to obtain HTML pages. However, because servers have more computing power than client devices, rendering pages there and sending a ready-made HTML to browsers is faster. This is what server side rendering (SSR) does. 

In SSR, pages are built anew upon each request, which takes time and may overload the server. It’s not the same for SSGs: you instantly receive content ready to display because all your pages are rendered in advance and stored until the next build. 

So, load times are the shortest in SSG.

Benefits of SSGs

Because of short load times, static sites are perfect candidates for SEO. Google makes sure users get the best experience from the top search results. Accordingly, it ranks the websites which are faster to load higher! 

Also, static sites have fewer vulnerabilities than client-rendered ones. In CSR, browsers receive JS code, so malicious actors may target it to collect sensitive data. In SSG, pages are less complex, thus, there’s little to no JS code to be targeted. And the back-end doesn’t reach out to the data source when a request is made; therefore, no SQL injections or XSS are possible. 

Static sites are highly scalable because they can be cached on a content delivery network (CDN) closer to users’ locations. This way, servers don’t get overloaded, and the speed increases. 

But SSGs are on the rise not because businesses give up dynamic content in favor of short load times and security. On the contrary, dynamic content is needed more than ever. Thanks to JAMstack architecture, static sites aren’t that static anymore.

What is Gatsby?

Now that we’ve discussed all the benefits of static generation and JAMstack in particular, it’s time to explain why to choose Gatsby as a JAMstack provider. 

Gatsby is a meta-framework for React, so you might find it comfortable working with Gatsby if you worked with React before. It has a file-system-based routing, loved by developers. 

Its architecture, pretty much like WordPress is based on plugins. The Gatsby ecosystem is vast and actively supported by the community. Chances are you’ll find any functionality you need. But the main Gatsby traits are the ones we discuss next.

Gatsby’s benefits

The framework inherits all the benefits of its underlying technologies – SSGs, JAMstack and decoupled architecture. That’s why we’ve discussed them in detail. To recap: SSG/JAMstack sites are interactive, fast, secure and scalable. But Gatsby adds up to these qualities. So let’s explore what exactly it adds!

• Image Optimization: Gatsby pays special attention to optimizing images. It minimizes image file sizes, which shortens request round-trip times. It also generates responsive images, which adapt to different device sizes. Additionally, Gatsby smartly prioritizes loading "above the fold" images and lazily loads other images as needed, ensuring that users see content as quickly as possible.

• Progressive Image Loading: Besides optimizing images, Gatsby uses progressive image loading. This means that as images are being loaded, Gatsby will display low-resolution previews in their place. This technique speeds up the perceived loading time and maintains layout stability by preventing content reflow and visual glitches that can occur as images load.

• Prefetching Content: Gatsby comes with built-in support for content prefetching. This feature means the browser preloads the content before a user clicks on a link. As a result, when a user does click a link, the navigation feels instantaneous, providing a significantly enhanced user experience.

• Code Splitting: Gatsby uses code splitting to optimize performance further. During the Webpack compilation process, Gatsby divides the code into smaller chunks. This enables the on-demand loading of code pieces, making more efficient use of network resources and improving site performance by only loading what is necessary.

• Extensibility and Customization: One of Gatsby's strengths is its extensibility. It offers a rich ecosystem of plugins, so you can easily add features and customize your site. Moreover, it allows easy integration with various data sources and third-party services.

• Developer Experience: Gatsby provides an environment that is friendly to developers. It is designed with a focus on performance but also aims to provide tools and features that enable faster development cycles, efficient debugging, and easier deployment processes.

• SEO Optimization: Gatsby also helps streamline SEO efforts. Through simplified configuration and automation, it becomes easier to manage SEO. Moreover, Gatsby supports schema markup and other SEO best practices out of the box, helping your content rank higher and reach a broader audience.

• Community and Support: Gatsby is backed by a vibrant and active community. This means access to extensive documentation, tutorials, and forums that foster support and knowledge sharing for developers and users alike.

These are the major Gatsby benefits. But there are many more bright sides and fantastic functionality that we just cannot fit into the article.

Build your next website
with a Gatsby partner

Official Gatsby partners: Ikius is part of the Gatsby partner ecosystem.

Grow your business: We’ll work together to grow your business and build the best web experiences.

Expand your team: Partner with a team of Nordic talent.

Gatsby use cases: What’s it great for?

Gatsby is great for building SEO-oriented websites with dynamic content. Why? For instance, eCommerce websites feature loads of goods, each represented by a photo. Image optimization in Gatsby helps to load these photos optimally! Thanks to it, illustrations are displayed on time while not overloading the network. 

Gatsby can also support read-heavy websites (web app or B2B services) since its pre-rendered content. And if you are worried that data may get stale, regular builds are enough for most cases to keep the data fresh. 

But this recipe with re-builds is only suitable for small to medium-sized websites. This is because the build process takes longer for bigger projects, which is a major Gatsby drawback. In turn, longer builds slow down your CI/CD pipeline, and updates get less frequent. Because data can get stale, Gatsby isn’t recommended for large websites, even though there are ways around it. 

And, of course, you can use Gatsby to create simple personal blogs, galleries, or corporate websites with dozens of landing pages. The framework isn’t too heavy for that and easy enough to handle! 

Gatsby and JAMstack

Gatsby has its take on JAMstack: its default approach to fetching data is through a GraphQL layer. GraphQL is a type of API that allows you to define your own schema. The querying language is simple, and you can fetch only the data you need, so you don’t overfetch (as you sometimes do with REST). And you don't need to use async thunks; you can fetch data directly from React components.

But who needs a framework that restricts you from integrating with 72% of non-GraphQL services worldwide? No one restricts you in Gatsby! The thing is, GraphQL is used only for data orchestration. For each build, all the data is pre-fetched via the protocol used by the service and then served internally via GraphQL. In this way, Gatsby makes for a better developer experience. 

Jamstack: combining static and dynamic

If you ask what is Jamstack, the answer would most likely be: “J” is for JavaScript, “A” is for APIs, and “M” is for markup.

But this answer doesn’t clear things up, does it? 

What you need to know are the reasons why Jamstack was created. And here you go: the initial goal was to grant more interactivity to statically generated content. This way, the benefits of static generation could be applied on more occasions. But how to do so?

The idea is to move rare computations to build time while executing more frequent ones in runtime. So, imagine you are creating a website publishing the highest currency fluctuations of the previous day.

Technically, the data is dynamic, but it changes infrequently. So, instead of looking up the values in the database for each request, you check the API once a day when rebuilding the static site. But if a user asks, what are the current values, a new API request is made.

Yes, Jamstack relies on APIs, which are the first element of our puzzle. Through APIs, front-end, back-end, and 3-d party services communicate. By and large, APIs allow for separating the content and presentation parts, which is the backbone of decoupled architecture. 

Because it is fundamental for Jamstack, let’s ensure you understand the decoupled approach. As you may know, in classic CMSs like WordPress, the front-end and back-end sit in one place — they are tightly coupled. You can’t separate the code that generates HTML from the one which interacts with the database. 

Contrary to that, in decoupled architecture, the front and back-end are independent. They may use different technology stacks and be hosted on different platforms. For instance, the latest trend is to use headless content management systems for back-end solutions.

Let’s get back to Jamstack, though. Interactivity is achieved by employing JavaScript to make API calls via HTTPS. In essence, you load static content, and only need JS to load extra data upon interaction. 

Then comes “M” — markup. Including “M” in JAM means that we are pre-rendering HTML pages (HTML is a markup language). But many think that “M” stands for markdown, which is incorrect. Because the ‘JAM’ was ambiguous, the company behind the tech stack, Netlify, has moved away from the acronym. These days they use just Jamstack (JAM not capitalized) as a reference to the development philosophy.

According to statistics, JAMstack’s popular: 2.7% of websites in 2022 use it.

JAMstack benefits

First and foremost, JAMstack is performant, meaning your website loads fast and is suitable for SEO. It also retains other benefits of static content, such as a smaller attack surface and better scalability, while allowing for interactivity, which isn’t characteristic of classic SSGs. 

JAMstack’s distinct feature is that it eliminates the so-called database latency. In classic CMSs like WP, the back-end retrieves data from a database to populate HTML each time a request is made. It takes time to obtain the data, render the page and send it back to the client. In JAMstack, the first two steps happen upon build, and in this manner, you only serve the page.

Then, the decoupled approach inherent to JAMstack comes with plenty of benefits. For example, you’re not bound to a specific predefined technology stack, and your data is more secure because it’s stored in a proprietary CMS.   

Gatsby and React

You may wonder how Gatsby can be based on React if it’s server-rendered. Classic single-page applications (SPAs) are client-rendered — all the Gatsby website content is sent to the client as one JS file, which is later executed to obtain HTML. But Gatsby sends pages in HTML, not in JS!

Here’s the answer: static pages can be assembled into a SPA through so-called hydration. This means a JS bundle is sent along with the HTML to the browser to assemble everything. Compared to classic SPAs, there’s much less JS to execute. And Gatsby retains their main benefit: needing less network-related traffic than a multi-page website. 

Closing thoughts

Gatsby is popular for a reason. Powered by JAMstack, it caters to most of the modern web's needs. It ensures not only short load times but also a seamless visual experience. Given that Google values both, the framework scores well on SEO. 

Also, Gatsby’s updated frequently: since 2020, three versions were released, and now it’s on v.5. So, its development goes hand in hand with current trends. For instance, in September, a new slice API was introduced: now you can build and deploy only the pieces of your Gatsby website that have changed since the last build.

To sum up, the developer experience is good enough, and viewers have a great time scrolling through websites built with the framework. So it’s high time to move your website to Gatsby.