Every developer seeks to optimize site performance. Since we are all citizens of the Earth, devs are also increasingly seeking to optimize for environmental efficiency, as well. So what if I told you that it’s possible to have both at once?
To demonstrate, let’s compare two site architectures: traditional monolithic WordPress and Gatsby with headless WordPress. It’s a head-to-head, eco-friendly technological showdown. Along the way I’ll share some of my recently learnt knowledge about what we can do as developers to help create a better and more sustainable internet…While also achieving blazing fast page loads and builds.
Spoiler alert: What’s good for the planet is also good for business!
About EcoPing
A lot of this knowledge was gained through working closely with my chum Dryden Williams, who built EcoPing – a set of web-based tools to improve your website’s carbon footprint and performance.
With EcoPing you can quickly and easily see the overall size of your website, then drill down into which resources make up those numbers: images, CSS, fonts, JavaScript etc. EcoPing also shows where in the world your resources are coming from and an approximation of how much renewable energy the data centers that serve these assets are powered by. It’s the perfect tool to help understand the environmental impact your website has on the planet.
The Showdown
I’ve used a combination of EcoPing and Chrome’s Developer tools to analyze and assess the eco-friendliness of two almost identical websites. One is built with traditional WordPress and Hosted on Hostinger. The other is built with Gatsby and uses the new gatsby-source-wordpress plugin and is hosted on Gatsby Cloud.
Both sites use the same WordPress theme, Susty by Jack Lenox which is widely recognized in the eco community as a versatile, professional-quality yet environmentally responsible best choice.
WordPress
WordPress has long been the go-to choice for building sites quickly, with its famous 5 minute install and easy-to-use content editor experience. But the traditional WordPress monolithic approach, coupling content with code, comes with significant drawbacks. Many developers have begun to shift towards Jamstack architecture and newer purpose-built “headless” CMS solutions.
At GatsbyConf 2021 Gatsby announced the general release of gatsby-source-wordpress, a plugin which makes it possible to query a WordPress database using GraphQL. In other words, Gatsby has now made WordPress “headless” and easy to integrate into a Gatsby frontend.
Gatsby
Gatsby is React but with a few extra super cool things added on top. Gatsby’s technology converts a React Single Page Application into multiple static HTML pages. The output is similar to that of a WordPress site, e.g an actual HTML file for each page of your site. In any Gatsby site, however, the React overhead is still present. Part of this project’s purpose was to find out exactly how this increased JavaScript bundle size might impact sustainable web performance.
Assumption
It was therefore my starting assumption that a Gatsby site would be larger, slower to load and worse for the environment than an equivalent WordPress site.
Sadly, on initial inspection, this was in fact the case 😳. Using the Susty defaults to render versions of our Gatsby headless WordPress site vs. traditional WordPress site, a like-for-like comparison for the Home page of both our demo sites looks like this:
Susty Gatsby: 45KB
Susty WordPress: 15KB
EcoPing data reveals that an average (desktop) webpage is around 1.97 MB. And, while both my demo sites are way below this average, the Susty WordPress site is approximately 30kb — 67 percent — smaller than the Gatsby equivalent site. Chalk one up for WordPress! ✅(FYI: Figures relate to desktop and are approximate ☝️)
However, both these sites are absolute bare-bones and it’s fair to assume that branded sites in production will contain more… well, “bones” 🤷♂️ . Google analytics, custom fonts, a more complicated logo perhaps, and almost certainly the truly big kahuna: images.
As an example, the Keep Britain Tidy “eco” site includes over 15mb of images on their homepage alone! 😲
Test 1: Unoptimised Images
I decided to see what would happen if I uploaded just one unoptimised image on a page in both of the Susty demos. Both sites are using the same exact image, which originally started life at 2.6MB. It has not been manually resized or optimised. Here are the results:
Susty Gatsby: 893KB
Susty WordPress: 1.6MB
The Susty WordPress site is now 707kb larger than the Gatsby equivalent — that is 45 percent larger!
Test 2: Optimised images
Because some content creators will optimise images before uploading, it was only fair to set up a second test. I uploaded one manually optimised image (again, the same one) as a page in both Susty demos. The optimised image originally started life at 220KB, then was first manually resized to 500px x 500px before being manually optimised using TinyPNG. Here are the results:
Susty Gatsby: 123KB
Susty WordPress: 235KB
The Susty WordPress site is now 112kb larger than the Gatsby equivalent — 47 percent larger.
The image testing takeaway
From the unoptimised image test, you can see that both WordPress and Gatsby perform image optimisation. This produces a smaller file size than the original image.
In the optimised test, however, only the image processed by Gatsby is smaller than the original!
So it would appear that — even starting with a manually optimised image — Gatsby still manages to shave off some of those vital kbs (893 kbs in the original, 123 in the optimised). Chalk one up for Gatsby! ✅
Gatsby achieves this with the all-new version of their image plugin gatsby-plugin-image. Among other things it processes source images as JPEG, WEP and the latest image format AVIF. WordPress, sadly, only processes the image as JPEG. You can optimize images in WordPress by adding plugins (responsive images (picture element) plus ShortPixel Image Optimizer is a classic WP combo). However, since gatsby-plugin-image is simply built into the latest Gatsby v3 framework, image optimisation is basically handled for you.
Again, some content creators will responsibly resize and optimise images before they upload them to WordPress. However, based on a recent post by EcoPing: The digital carbon footprint of Dezeen; the world’s most popular architecture website, you’ll see that some content creators don’t…Yikes!
In this case, having Gatsby and gatsby-plugin-image working behind the scenes is worth the overhead that comes with a React site. Even if just one time, one person uploads one image that hasn’t been properly optimised, you won’t have to give away the farm 🐖.
Test 3: Static sites showdown
There are concerns around the eco-effectiveness of static site generators. The reason being that, each and every time content or code changes, the build pipeline takes over and rebuilds the entire site from scratch. This can lead to many many minutes of server time. Imagine an e-commerce site, for instance, where products are updated regularly or go in and out of stock multiple times a day. Re-running the build every time this happens is an absolute eco-no-no, not to mention bad for business.
This is tragic, because static sites are terrific in most other ways. The simplicity of the architecture, the inherent security, and the reliability and ease of handling traffic spikes.There’s so much to love but, if you’ve used Gatsby, or any other static site generator for that matter, you know that as sites get larger, build times unfortunately start to get larger, too. A lot larger.
This is where I believe Gatsby Cloud comes in. Gatsby Cloud incorporates incremental builds, meaning that any time there is a data change to a site — content is added or updated — Gatsby Cloud intelligently rebuilds only the parts of the site that have changed. This is a complete game-changer, because it solves the one bad thing about static sites: long build times.
Gatsby Cloud also recently added Hosting on a global edge network, and this too should make a difference in how fast a site can not only build but deploy live.
To put this theory to the test I ran a like-for-like build and deploy comparison of the Gatsby Susty site on Gatsby Cloud and on Netlify. Like many developers, I find Netlify to be a great solution and I have hosted many projects with them. But while in full-on experiment mode, now seemed like the time to see if there is indeed a difference.
Initial build test
Yes, this Gatsby demo site is both basic and small in scale. But it’s a consistent baseline for the purposes of our experiment. Here are the results for the initial build, where we build the entire (uncached) site from scratch:
Rebuild test
Here are the results for a rebuild of the Gatsby Susty site on both Gatsby Cloud and Netlify. A rebuild occurs when new data changes are detected, like when content from WordPress is added or updated.
The initial build and deployment on Gatsby Cloud is surprisingly fast. But, as you can see, the rebuilds triggered by content/data changes are also much — much — faster than the Netlify builds and deploys for this same site and data change. That is (…does math…) 193 percent faster!
(I should note here these times have been produced using “out of the box” config, for both Gatsby and Netlify. There are ways to optimize Gatsby build times on Netlify: See this post by Jason Lengstorf, 5 Optimizations For Faster Gatsby Builds, for more).
Personally I’m of the opinion that, if you’re developing Gatsby sites, using Gatsby Cloud to build and Gatsby Hosting to deploy just seems the obvious choice. Especially given that there are robust free plans for both Gatsby Cloud and Gatsby Hosting. The two technologies; Gatsby (The Open Source Framework) and Gatsby Cloud (The build engine / Hosting CDN) have been designed to work perfectly together. Aside from the speed advantages, on much larger projects I imagine there would be considerable cost savings simply due to fewer build minutes being used, and best yet — no additional config required to achieve optimal performance results right out of the box.
Conclusion
To sum up, it’s hard to make an open/shut case that traditional WordPress is better than Gatsby or vice versa. There are valid arguments both for and against each technology, and it all comes down to what results you need from the site you are building.That said, Gatsby does appear to be continuing to develop ways to make web experiences faster and ever more reliable…And that will also, as a happy side effect, contribute to creating a more sustainable web.
What’s not hard to argue is my experience building and deploying sites on Gatsby Cloud and Hosting. It’s demonstrably fast, which is good for business. The Gatsby framework’s built in image optimization and speed means shorter builds, which equals fewer build minutes paid for…Not to mention less data center power consumed, meaning that running your site in Gatsby Cloud is even friendlier to the only planet in our solar system capable of supporting human life (yet, anyway).
I’m considering turning the Gatsby Susty demo into a Gatsby Theme so if you’re interested in or hacking around in this space please come find me on Twitter, I’d love to chat about it some more: @PaulieScanlon.
In the meantime the source code for the Gatsby demo can be found on my GitHub: https://github.com/PaulieScanlon/gatsby-sustainable-web.
Ta ta for now 🕺