Gatsby continues to gain popularity among developers and companies of all sizes. In this article I aim to describe what Gatsby is, what problems it tackles, when it’s worth considering it, and its benefits.
Gatsby describes itself as:
“A free and open source framework based on React that helps developers build blazing fast websites and apps.”
Despite being classified as static site generation, Gatsby is often described as Progressive Web Application generation to highlight that not only static sites can be built with it.
It’s worth mentioning that Gatsby is also a company which received ~$3.8 million investment in 2018. Apart from maintaining a framework (with some great help from the community) it also provides products such as Gatsby Preview and Gatsby Cloud.
A brief comparison with React
Before we jump into a full description, I think it would be useful to conduct a brief comparison to the React app.
With the React application, when a user enters a URL into the browser, he or she will:
- Receive a blank page
- Wait for React to draw entire page (at this point we start to see something)
- Wait for React to ask for data from various sources
- After that our website is ready
Gatsby allows us to do the bulk of this work beforehand. Before we even start shipping our website Gatsby (during build process) will:
- Fetch data from various sources
- Pass the data to React components
- Generate static pages for each route
Because of this, when our user enters the page details into the url, they will:
- Receive a full page with all the data in place (except for data that we want to be fresh as possible, such as items available in shop)
- Load fresh data if necessary
- Our website is ready
So the key difference is that because we do so much work beforehand, our users can access the site much faster.
How Gatsby works
During the build of our application (before we send it to the user) Gatsby will fetch data from a defined source. This can be an API or CMS (content management system like WordPress, Contentful, Sanity). We can get data from multiple sources. For example – we can get blog articles from WordPress but download our shop product list using Shopify.
Apart from truckton of optimizations aimed at making development easier, Gatsby optimizes our website for users. If we (developers) don’t make big mistakes during development process, we’re guaranteed to receive 90+/100 scores on the Google performance test with Lighthouse.
Each link to site in Gatsby can be prefetched. This means that when the link is visible, the page that it points to starts to loading. This results in load times fast enough to appear instantaneous.
However, remember that this effect won’t appear when a user has a slow mobile connection and is not connected to WiFi. We don’t want to be a nuisance to our users.
Optimization of images
Images are one of the biggest resources on the webpage and Gatsby helps a lot here. Gatsby generates low resolution placeholders so we see a blurry image instantaneously and then starts to load up an image that is appropriate to a device’s width. We don’t want to load a 1900px wide image if the device has only 800px in this dimension.
Apart from that Gatsby Images are also lazily loaded, meaning that if the image is out of our sight we won’t load it to avoid wasting time and transfer.
Because our website is fast and ready to read almost instantly, Gatsby sites are treated better in SEO than standard apps – another big bonus.
The JAM stack
- A static site generator – Gatsby
- API – WordPress, Contentful, Sanity
- Markdown – static site, that is build as a result of Generator getting data from API
JAM stack offers multiple benefits:
Static file hosting is the cheapest way of delivering content to users. What’s more, because most of our infrastructure isn’t needed after the build, it can be scaled down. In most cases we don’t need to hit our database on every user visit, we can do it on every build reducing load greatly.
Since we’re building static files with the whole page ready we don’t need our CMS or databases to be available after the build. If they fail or become unavailable we’re only blocked from releasing content updates, users still can experience the older version of the website uninterrupted.
If our website doesn’t need any data, our user will not have any way of maliciously accessing our database. This disables a big vector of attack,
Due to Gatsby opinions on how we achieve fast experiences some trade offs were made, which leads to some limitations.
Because the entire website is built upfront, any change requires it to be completely rebuilt. That means that when we make any change to code or content we have to trigger our build process again. It doesn’t matter if we change one button color or a small typo. What’s more, we cannot preview what our changes will look on site without rebuilding it. This tradeoff is worth considering when we decide if we want our website to be easy to work with or if we want it to be as fast as possible.
Building an entire website upfront can be troublesome when we want to hide content from users until they login. We don’t want to be generating a great, fast experience, only then to hide it away later. In this case we would want to consider Server Side Rendering solutions such as next.js.
Another problem might arise when we want to display only fresh data to users. In this case we will hardly benefit from the entire machinery that Gatsby uses. We won’t be able to offload most of the work to the build process. Again, Server Side Rendering appears to be a better solution here.
Typical Use Case
The best websites suited for Gatsby are the ones that use content which is known upfront or changes infrequently. Typical use cases are marketing sites, blogs and shops.
Websites built with Gatsby are fast, light and effective. This technology provides users with fast load times and small transfer usage. Business benefits from great SEO, lower infrastructure costs and better conversion due to users not switching pages because of slow load time.
Interested in starting a new digital project using Gatsby? Get in touch with us on firstname.lastname@example.org – a friendly member of our team will get back to you as soon as possible.