PyCon US 2025: Building low-carbon websites
Details of our PyCon US poster about web sustainability
As part of this year’s Wagtail presence at PyCon US, we put together a poster about websites’ carbon footprint. Here are more details on the different sections within this poster, for people wanting further references.
Why websites’ carbon footprint matters
Put simply, to limit global warming, we have to reduce all forms of greenhouse gas emissions, including digital ones. There are millions of websites out there, and they keep getting bigger. We’re currently at 2.5MB of average page size according to the HTTP Archive’s State of the Web report. Those numbers add up fast at the scale of millions of websites and billions of users. Not to mention the carbon footprint of the users’ devices, which have to be replaced to keep up with the bloating of web pages!
If you want more information on this topic, we recommend:
Grid carbon intensity
An important concept to understand first is the carbon intensity of the electricity grid. It represents how much carbon it takes to produce electricity, and varies a lot around the world. This depends on the energy sources of the local electricity grid - renewables, coal, gas, nuclear, etc. Here this is pictured on Electricity Maps, which offers both live data and historical figures. How "dirty" or "clean" the grid is also varies over time and even during a single day, since a lot of energy sources are dependent on the weather.
On this map, "green" areas have a relatively low footprint. Brown areas have a high footprint. And here we just have a zoomed-in version of the same info for the USA:
This is an important factor to understand early on, as we can then reason about the carbon footprint of a website based on where its servers are in the world, an also where the users are: there is energy use on the two ends, and also for the network in-between. There’s also carbon emissions to produce the required devices, called "embodied emissions".
Note: when we say "carbon" here, technically it’s "carbon-equivalent", so also includes other greenhouse gas emissions (methane in particular).
Quantifying emissions
So – to build low-carbon websites, we then first have to understand how much energy websites are using! There are many different techniques here, we’ll cover the two most promising ones, that we have been researching as part of Estimating Wagtail websites’ emissions.
Website page weights in the Python web
Page weight is a useful metric to assess performance (lower weight = faster sites). And it’s also a good approximation of websites’ energy use. The idea being that heavyweight pages take up more resources to generate, more bandwidth to send across, more resources to render on a device. Sustainable Web Design explains this better, and online tools like EcoPing or WebsiteCarbon are based on page weight. It’s far from perfect however, see for example Why we don’t report carbon emissions by DebugBear.
Anyway, from technology to technology there can be big differences in say JS payload size, ability to compress HTML or images, which leads to differences seen on charts like this. In the Python world, this is affected by which features the different frameworks support (image optimization, compression, deferred loading).
Digital Carbon Ratings
Digital Carbon Ratings are a promising way for sites to communicate at a glance how much emissions their pages generate. Those ratings are based on page weight, and assigned based on the distribution of weights on the web. A rating of "A+" corresponds to pages that are in the 5% most lightweight. A rating of "F" is pages that are more heavy than average (so bottom 50%).
This specific graph shows the distribution for Wagtail homepages. It’s still early days for the creation of such standardized ratings, there is more work needed to make use of this reporting format. But the reasoning is sound: over time, we would want to see more A+ / A / B pages, and fewer "F". And we’d ideally want to do (much) better than the average website. So it’s a good way for us to picture the overall progress of the Wagtail ecosystem.
CPU measurements
Now let’s stop looking at page weight! This chart comes from Green Metrics Tool, the best way to end-to-end benchmark a Wagtail site’s energy use that we’ve found. It represents CPU measurements for four separate services:
- Yellow: the browser, simulating a user’s visit. This spikes really hard, and goes much higher than other lines, which is a good representation of how much energy use there is client-side.
- Blue: the application server. We can see this is much more constant regardless of whether anyone is browsing the site, though there are a few spikes.
- Green: DB. Mostly invisible. But for a real-world site this would probably be using a beefier server.
- Red: Redis. Same as DB.
This is a great illustration of the possible levers to reduce energy use. Client-side there is a lot of room to reduce energy use. Server-side too, though not necessarily where people think.
Reducing emissions
Now that we have a base understanding of quantifying emissions, we can look at reducing them! Here as well, our poster showcases some of the key findings from our past research.
Image checks
This comes straight of our 2023 Google Summer of Code project, with all results presented in Leaner images, lower footprint, at scale. Images are pretty heavy, so when we work on page weights, they’re a good thing to try and optimize! Fewer images = better, but also making sure to use newer formats: WebP, or even better - AVIF, or JPEG XL (browser support dependent). Although lots can be done by optimizing images in established formats (like with jpegli), newer formats are generally suited for a wider range of images and have the opportunity to compress more.
In Wagtail, another key benefit is having a solid API for developers to easily generate images at multiple sizes, to leverage responsive image techniques and only load an image as big as needed for the current device / page layout.
To roll this out on a site, try the Cloudinary image checker! Gives a good sense of how much room there is for improvement.
OLED displays
For OLED displays (very common in smartphones), darker designs means lower emissions. Side by side, this picture shows how the same OLED monitor has a drastically different power consumption when displaying the wagtail.org website in light mode (7.6W) and dark mode (4.4W).
We’ve been researching this recently, in OLED and dark websites = lower footprint ✨. Devices’ displays tend to be the components that consume the most energy for smartphones and laptops. So creating dark themes for apps and sites helps for accessibility and meeting user preferences, and in reducing energy consumption for those display technologies.
Going further
See RFC 90: Sustainability roadmap for other changes we’ve considered in Wagtail. There are lots of possible levers. Big ones for the Python web ecosystem would be:
- More "scale to zero" infrastructure. Rather than over-provisioning databases and application servers, having some where resources are better utilized. Serverless databases and Function-as-a-Service are clear opportunities here. But only if Python cold start times can be kept low. See for example How to profile and improve startup time.
- Smaller servers. For a Wagtail site it can be tricky to function with less than 512MB of memory, and a dedicated database on top. Cutting that in half, would likely cut carbon emissions in half. It’d also reduce costs! See for example how the Fly.io hosting cost calculator accounts for memory.
- More client-side focus. There are a lot of opportunities for optimizations there. Responsive images are a big one, but also all sorts of deferred loading of client-side assets.
For Wagtail, our next avenue of exploration will be websites’ grid awareness as part of our Google Summer of Code participation. If you want to keep up with our sustainability work, we regularly showcase new research and improvements in the Wagtail newsletter!
This Week in Wagtail
A weeklyish newsletter with Wagtail tips, news, and more.
