Gatsby has been a beloved React-based open-source framework for a long time now. Its stable architecture and focus on performance have made it a top choice among enterprise customers for mission-critical web applications.
Throughout the past quarter, our Frameworks team has been working hard to ensure that Gatsby hasn’t been forgotten. We’ve been striving to bring the best parts of Gatsby Cloud across to Netlify and addressed critical bug fixes and performance optimizations. We’re also excited to share some enhancements that are set to improve Gatsby’s capabilities even further.
Framework Stability
Reliability and stability of your frontend framework are key when you’re building large high-traffic sites - a message we hear loud and clear from our many enterprise customers who choose Gatsby for their projects.
To ensure that you can be confident in using Gatsby for your websites, our initial focus was on stability:
- We fixed some complex issues with Gatsby internals when using the Gatsby LMDB data store in the generated Server-Side Rendered (SSR) or Deferred Static Generated (DSG) functions.
- We took a look at some tricky dependency issues in our serverless functions. Now, Gatsby can self-heal to avoid issues with incorrect binaries which caused runtime issues with SSR-and DSG-based pages.
- We also took this opportunity to fix an issue with the popular Gatsby Contentful plugin. The issue was causing intermittent build failures for some people. Fortunately, some serious debugging got us to the root of the issue.
Gatsby Adapter Improvements
Another significant focus has been on solidifying the work we’ve done since we released our Gatsby adapters earlier this year.
Our aim with moving towards the adapter pattern is to make it easier to deploy your sites to Netlify, or any other platform you want, by taking the production output from your site and turning it into something your platform understands. As our Director of Engineering, Claire Knight, wrote earlier this year, “We want to ensure that the Gatsby ecosystem remains open and encourage other platforms to build their own adapters too.”
After the initial release of our gatsby-adapter-netlify community members have highlighted some issues they had when adopting it. As a result of this feedback, we’ve made improvements. Specifically, we addressed issues with very large websites and added extra configuration options.
Some of our users leverage the power of Gatsby to build extensive sites with tens of thousands of pages. We’ve spent some time improving site generation performance and addressing some bugs and missing features for these.
For example, our Gatsby adapter creates a manifest file from which a Netlify _headers file is generated, allowing you to apply custom response headers to your site or parts of it. In some extreme cases, this file became too large and caused builds to break, so we optimized the code to generate a more minimal set of path patterns.
Our adapter implementation also needed a couple of key features that the Gatsby community were asking for. We heard you and so we made sure we worked on these too:
- Firstly, we added
pathPrefixsupport to ensure you can host your Gatsby site in a directory other than the root of your domain. This allows your site to function and all assets to be served correctly if your site is in a sub-directory. - Also, we added
trailing slashsupport to help to make SEO-friendly Gatsby sites and fixed a few issues with country and language options not being honored with Gatsby redirects.
Image CDN
We recently announced our new Netlify Image CDN beta to reduce page load times by delivering smaller, optimized images. To make sure that Gatsby users can benefit from this as well, we have leveraged the image CDN in both the Gatsby build plugin and the new Gatsby Netlify adapter.
To enable the image CDN in your Gatsby project, set the environment variable NETLIFY_IMAGE_CDN to true. This will enable using the CDN for transformation of both local images from your site and remote images from other servers.
If you’re using remote images, you also need to set a list of allowed URL patterns from which your external images are served, as a list of domains which can be regular expressions. Both this list and the above environment variable can be set in your netlify.toml configuration file:
[build.environment]
NETLIFY_IMAGE_CDN = "true"
[images]
remote_images = [
# Example to load from Contentful - replace contentful-space-id with your space id
'https://images.ctfassets.net/contentful-space-id/.*',
# Example to load from WordPress or Drupal hosted on Pantheon.io - replace the domain with your own
'https://live-contentacms.pantheonsite.io/.*'
]
If you’re using an external content management system (CMS), make sure you adjust the list of remote_images to match the image domains that CMS uses. For more details, look at the documentation for the Netlify Gatsby plugin or Gatsby Netlify adapter.
This one-time simple setup brings real benefits: it can improve the performance of your pages, lower bandwidth by serving correctly sized images, resize or crop your images, and serve them in an optimized image format such as AVIF or WebP.
Moreover, since images are now served from our CDN rather than being transformed at build time, it also saves your precious build minutes. In tests with some of our larger enterprise customers, we’ve seen build times reduced by 80% by adding just a few lines of configuration!
While we’d love you to use our Image CDN to transform your images, the code for our image URL generator is open-source. You can use this to build your implementation for other image CDN providers too.
The Future of Gatsby
While the Gatsby framework is no longer the new kid on the block, it’s not going away any time soon. It’s been battle-tested by companies for many years and is used for large, real-world, high-performing websites, including many of our enterprise customers.
Here at Netlify, we are committed to continuing to support Gatsby as well as working with the community around it.
In addition to ensuring that the framework is stable, predictable, and high-performing, we’re now working to give it extra superpowers via strong integration with our Composable Web Platform, specifically Connect and Create.
At the same time, we will also continue decoupling the parts of Gatsby core that were closely tied to proprietary cloud infrastructure, through the adapters feature.
The regular conversations we have with our enterprise clients helped us understand that many mature and established organizations prioritize stability, robustness, and predictability over bleeding-edge innovation and rapid churn in the tools they select for building their web experiences.
We want to satisfy that need, as our CEO Matt Biilman said recently:
While we don’t plan for Gatsby to be a place where the main innovation in the framework ecosystem takes place, it will be a safe, robust and reliable choice to build production quality websites and e-commerce stores, and will gain new powers by ways of great complementary tools.
Over the last few years, Gatsby’s static-first approach guaranteed high performance and uptime for customers, while allowing teams to build compelling front-end experiences.
Our aim to make sure that this is still the case over the next few years.
