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.
Let’s examine how Gatsby works. But we first need to explore why to use static sites.
A quick intro into static site generators
In the past, people wrote static sites by hand with some HTML/CSS and some magic. But it took a lot of work to create and maintain a website, especially for non-developers. Then WordPress (WP) came in and alleviated the need to know any programming.
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 a set of markdown files and templates. The corresponding tools were called static site generators (SSGs).
SSGs take a bunch of blog posts and combine them, together with images, into HTML pages. These are stored on the server and sent to clients upon request. Even without a 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, it’s faster to render pages there and send a ready-made HTML to browsers. 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.
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. Why is that?
JAMstack benefits
First and foremost, JAMstack is performant, which means that 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 at a glance
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 plugin 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 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.
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 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 that a JS bundle is sent along with the HTML to the browser to put everything together. 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.
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!
One of Gatsby's prominent features is image optimization. Gatsby minimizes image file size to shorten request round trip and generates “responsive images” for different device sizes. In addition, it fetches the “above the fold” images immediately and postpones fetching other pictures for later.
While images are being loaded, Gatsby displays “progressive images” in their place — previews of entire images. It helps to hold the images’ position and prevent reflow and glitches. Gatsby also comes with built-in support for prefetching content — even before you click a link, its content will be already downloaded by the browser, hence you’ll proceed to it quickly.
Then, there’s code splitting: during Webpack compilation, the code is divided into small chunks. It helps to load some pieces of code on demand, which frees up your network capacities.
These are the major Gatsby’s benefits. But there are many more bright sides and amazing functionality that we just cannot fit into the article.
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 applications or B2B services) since its content is pre-rendered. 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!
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 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.
Top comments (0)