Faster, leaner, greener: 10x lower website carbon emissions with Thibaud Colas

Speaker 1: Hi everyone. Thanks very much for having me. I'm Thibaut, my pronouns are he, him, come from the UK, I'm a developer. working at a company called Torchbox. We make websites for nonprofits and the public sector. And we have an open source CMS called Wagtail, which I'm a contributor to I'm also a board member of the Django Software Foundation, but today I'm here to talk about my work at Touchbox and with Wagtail. I want to say quickly thank you to my partner who's looking after our kids while I get to be here. And also thank you to Torchbox who has me presenting today. And yeah, if you've not heard of Wagtail before, it's a CMS that's used by a lot of companies, some of which are in this room today. Quick disclaimer, this is a talk about uh digital sustainability.

Speaker 1: climate change and emissions. I'm by no means a climate scientist. I'm just a developer who put together some numbers and is trying to figure out what to do about this wider societal issue. So Yeah, expectations. But yes, why I'm here, plainly speaking, is because uh we have this big societal challenge and in our tech industry. We have plenty we can do on the global scale of our whole industry, but also at the individual level. And that's why I'd like to show you some numbers that put the problem in context and hopefully give you some guidance on what you yourselves can do about it in your own projects

Speaker 1: So this first big number that's my best guess at the cabot footprint of the whole Django web. That's 120 thousand tons of CO two emissions per year for fifty thousand Django websites. It's probably most likely hundred to five hundred thousand Django projects out there, but this just gives us a sense of the scale of the problem. If you've not looked at carbon emissions figures in the past, this whole conference is on the order of 300 tons. uh return flights transatlantic might be a ton of carbon emissions. So this number compared to some other industries, compared to the whole of the tech industry, maybe not so big, but for us

Speaker 1: quite a humongous figure. And um yeah, it's not getting any any better. Uh I'll try hard not to go like old doom and gloom, but This chart here is uh CO2 emissions over time, both in the past and projection for the future. And um yeah, the business as usual curve. That is definitely not where we want to be. And uh if we zoom in a bit on uh this point in time, this this purple area, uh I can big to a better sense of the challenge. Uh we are in the left side now and we're at this point where we have to decide, okay. Do we make our best to reduce society's carbon emissions, to reduce our industry's emissions, and follow those pathways towards little to no warming?

Speaker 1: Or do we just keep going business as usual to 2050? And um the specific target that people tend to use is 2050 net zero. So when you see figures like 1. 5 degrees of warming, that's the goal for us to limit global warming to that amount at that date. And that's what the talks uh title is about, 10x lower carbon emissions. We all love that number, that 10x, but it is actually based on uh this n goal of 1. 5 degrees net zero by by twenty fifty. So plainly speaking it comes from a net zero Reporting standard from an organization called SBTI that says we have to reduce our industry's emissions by 90%

Speaker 1: by that date. So 90% reduction is 10 times lower So that's why we're here. We're here to figure out, is it possible? Yes. And exactly how do we go about it? And uh yeah, I thought I'd start with uh a picture of uh the internet as uh shown in the Django Girls tutorial. So I really like the Django Girls tutorial, I thought I'd use it. On the left we have our user that's trying to access a website. So they may be on their phone or on the laptop And when they make a request to that website, it goes through quite a bit of infrastructure to reach the Django Girl server. And this here, this path From me as a user to the server, it helps us define what we call system boundaries, which we'll use to figure out how

Speaker 1: we decide what we what we're calculating essentially. So Use my MS Paint skills and I drew three separate segments of our system boundaries. The user devices in purple the network in blue and the data centers or our servers in in red. And when we uh look at those three separate things, we can uh talk about them uh via the lens of specific models that tell us, okay. If we have those separate system segments, if we've drawn those boundaries, here are the emissions we can expect in the three areas. So those figures here they come from a model called sustainable web design that is very, very popular. And this specific model tells us, okay

Speaker 1: About this much of the emissions are across those three separate uh segments. So 22% for data centers, 24% for networks, and 54% for user devices. which is me on my phone accessing the site. And um yeah, there's another way to break this down, which is based on whether those emissions come from using the hardware, like electricity that's powering up your phone, or whether they come from uh creating the hardware. So literally someone mining the resources, shipping the phone to you, and so on. So that's what we call embodied and operational emissions. And um What I want you to be very clear about here is that where there's the most emissions by far

Speaker 1: is actually on those user devices. So as Django developers, our role isn't so much to optimize the servers It's actually to deliver much smaller websites for our users that will allow them to keep their devices longer and that will allow those devices to just take up less energy to display our sites and apps. And again, just to hammer this point across, I put together this CPU chart of serving a request on a website probably with Django and a database. And the the yellow sparks, that's my automated browser CPU. And the blue and if you can see them, the green sparks at the very bottom. That's actually our server. So we care much more about limiting the amount of energy that the browser takes than

Speaker 1: the server takes. Obviously there is room for both, but that's kind of where the biggest savings can be made. So yeah, we'll look at a few savings and hopefully there's something interesting for quite a lot of your projects in the room. I tried to pick things where I could put an exact number on the savings. I've struggled quite a bit going through this in just as a thousand different options for things you could do, but putting a figure on which one actually lowers emissions. is really hard. So yeah, hopefully it helps. And I'll start with a very simple one which is called the facade pattern, which you might have heard of before. It's a really simple idea and we're gonna play a bit of a guessing game. You have to look at the two sides of this slide.

Speaker 1: We have two different YouTube videos. And we're gonna have to look and compare, like, okay, in what way do they differ? And short answer is there are some differences, but they're not too important if what you care about is playing the video. But the big difference is behind the scenes. One of these is ninety-five percent less uh resource intensive than the other. So to the left we have the base YouTube embed. It's almost a megabyte of resources to load in your browser just to display that square with the image and the red arrow in the middle. And to the right we have an uh YouTube embed that's much more optimized. And yeah, 95 % less resources to load in the browser to display something that's more or less functionally identical.

Speaker 1: So I really like this because it's a really great example of the types of savings we might not expect, but as we start to look at the numbers, it's really clear that for the users of our websites The one on the right probably is just as good and definitely takes much less energy, produces much lower carbon emissions. So yeah, this facade pattern pattern again. Nothing specific to Django here, nothing specific to YouTube either. It's a very generic way to decide, okay, I have something that's quite intensive to load I can do that by having a much simpler version loaded and then replacing it on click And yes, so we'll keep looking at front end things for now and I want to talk about dark mode and

Speaker 1: OLED screens. So OLED is one of many technologies that uh power display panels on phones, laptops, tablets, and so on. And uh some of you might have already heard that dark mode is meant to lower energy emissions. I have spent ages trying to get some proper numbers and we now finally have them. So displaying those two versions of the Django websites on my own screen. The one on the left, the light theme, eleven watts to have this displayed on the screen at any point in time. And the dark theme is four watts Again, an enormous saving you might not necessarily suspect. And there's lots of good reasons to do dark themes. It's not just that. It's also quite great for accessibility that people get to choose between the options.

Speaker 1: just plenty m good reasons to use it and yeah just lowering energy usage of those displays is a big factor. And again, this is not niche technology OLED. I believe Apple as an example, they are meant to complete their whole switch from LCD to OLED on phones next year and start the switch for laptops in 2026. So these savings, again that are quite big, uh will be available across pretty much all devices in the future. So just to give you a sense of uh where to I'm for your websites, this chart here is my best attempt at going through all the screenshots of colors of different websites that I could find and charting based on how dark the color is or how light the color is.

Speaker 1: how many emissions to expect. So you can clearly see that even without necessarily creating a whole dark theme, just using slightly darker colors, you already can get quite big savings in power usage. Okay, next one, image optimizations. This is something that I'm sure lots of people in the room will have already heard about. Uh but there's some interesting innovation that's definitely worth checking out. So here we're looking at three different versions of the same image and I'm sure that it's really hard for you to tell any difference between them. And again, it's behind the scenes. The other difference is there, which is the file size. The image on the left, that's quite an optimized JPEG, about 200 kilobytes. The middle one has been re-encoded with a new encoder from Google called

Speaker 1: JPEG Lee That makes the image 30% smaller. Same image format, exact same compatibility for end users No code change is needed, just the image has been recompressed with a newer encoder, and right away we get 30% savings. And yes, there are newer formats like AVIF on the right that are even more promising that I would definitely encourage you to consider, but aren't backwards compatible and require code changes, not just a switch of the image file. I've left quite a few references, but I'll just uh breeze through them. And yeah, there are Django packages that do this. You don't need to reinvent this yourself. uh quite a few of these is just a matter of getting the right package set up and configured for your project.

Speaker 1: And yeah again just to hammer the point home. A few months ago I read the PSF's annual report as a PDF. It was a sixteen megabytes PDF file, which is really bad for lots of reasons. So Took it upon myself to try and make an HTML version of that, got quite good savings out of it, then run it through JPEGly, even bigger savings, and then AVIF, and that's how you can with the same content before and after get those 90% savings. So it very much is possible. You just have to figure out for your type of site or content which of those options will have that kind of payoff. And also keeping with images, you might have also heard of a different technique called responsive images. It's the very simple idea of loading an image size.

Speaker 1: That's the optimal size for the device it's displayed on. So here again, three versions of the same image that more or less look the same at the size they're displayed at here. And just by virtue of having resized them for this target size, we get quite big savings I'll skip through quite of this of this just in the interest of time. But again, that's something that quite a few Django packages uh make possible, so you don't have to reinvent this. all on your own. And yeah, again, I wanna make it clear that this is real-world savings. So we did this for Wagtail as part of a Google Summer of Code project. We had two interns, Amon and Parf, working on this with us and the before after savings are thirty percent lower images

Speaker 1: across our demo websites. And when I say across the demo websites we expect those savings to scale across the whole of the Wagtail ecosystem. So our target goal for that project is if it was rolled out across all Wagtail sites out there, we'd have two thousand tons of emissions reduction per year. I hope this gets you thinking as well about potential changes in Django or packages as well that could uh deliver similar numbers. So yes, moving a bit further towards the back end, I want to talk about site architecture. And yes, there's been quite a few talks about SPAs. Next. js, HTMX, all the JavaScript buzzwords. And as much as I like JavaScript, if you start to look at the numbers, it is quite clear that the more JS you ship to your users

Speaker 1: the higher the the emissions, unfortunately. So this chart we'll spend a bit of time on. We have four different figures of energy usage to display a hello world page on a site. Just a very like plain HTML hello world. To the left we have the database. On its own, there's no page displayed, but I like to keep it in because it's a reminder of the energy you might not be able to remove because we do have to keep our data somewhere, one way or the other. Then we have Django plus the database, so just a very simple WISGI server. Then Nginx plus the database means it's a static export that's served by Nginx. We can see that the static sites actually takes less energy than the Django served websites.

Speaker 1: And to the right we have Next. js that's talking to Django via an API that has the database. quite clearly it's higher. So maybe that kind of headless sites with a separate client node or other technology that makes sense for your project, but you do have to be aware that in terms of energy consumption The bigger the stack, the higher the emissions, essentially. And there's nothing that beats uh serving sites as static files So, yeah, just uh again to show you what it means in practice, uh, these numbers here, that's the types of emissions we see for the types of websites that my company hosts So just putting them here so you have a sense of where the emissions are across the different components of the Django stack.

Speaker 1: The Django server itself actually might not be where the most of the emissions are. For us it's the database because we expect it to be quite a bit beefier. We can't scale it as easily. It's all vertical scaling. So that's where it is. Cache, that means Redis in our case. Quite clearly something that uh takes here about 25% of the emissions, and we probably will try to get rid of, no matter how useful it is, it is something that we can probably uh get by without using. And yeah, the file storage is very interesting. People often get the idea that storing lots of videos might mean lots of emissions. In our case, that's for one terabyte of storage per year, that we have three kilos of emissions.

Speaker 1: So, yeah, all those things have varying degrees of carbon emissions. And I wanted to give you a sense of, I guess, possible improvements there, server side. This chart here is about uh function as a service infrastructure and how it could help us lower server emissions. From left to right, we have different degrees of over provisioning a server with more CPUs than it needs. And the darker grey area shows how much CPU is used by just idling. So the the point here is to show that if your workload is consistent and the very small light gray area at the bottom It's in your interest to have a stack that can scale down all the way to meet that workload

Speaker 1: and ideally scale to zero would be the ideal hobby. Okay, one last point of possible improvements that I think would be relevant to quite a few people here, which is thinking of where you host your website and how it can impact emissions, which we call grid carbon intensity. So I pulled this map just this morning. It shows us the grid carbon intensity, so how much the grid pollutes across different areas in North America and Yeah, we can see South Carolina, which is where the US East One region of Google is, uh quite a dark shade of brown, so not ideal. But if you were to take your websites up to Canada and uh Eastern South Canada in particular, it is all very, very green.

Speaker 1: And that's quite simply because they have a lot more renewable energy up there and hydroelectric energy in particular. And the thing is, your site will more or less work the exact same, regardless of which of these regions it's in. So you want to look at those numbers and again they can give you quite amazing savings. We're almost at ninety percent lower emissions just from switching to US East One to US West One with Google. I've dodged the whole AI topic through this talk, but I just wanna bring it up at least once to show that it's again not all doom and gloom. So we're looking at this table of all sorts of different AI models and I want you to focus on the ones on the left, GPT-3 and Bloom. and the very last

Speaker 1: number in the very last row, which is their total training carbon emissions. And what's really interesting about these two is that those models have very comparable performance, but the emissions of Bloom are twenty times lower than the emissions of GPT-3. So again I think it's important to show this just to demonstrate that It is not all doom and gloom. And if you pick your server architecture correctly, if you pick the right data center, you can get very similar results with much lower emissions. We can talk about AI more later if you want, but yeah, whole other universe. And I want to leave you with a few pointers on where to go next if you want to get started with climate action in your company.

Speaker 1: One big recommendation for me is to join an online community like Climate Action Tech. It's a Slack server and pretty much that's it for me, but I found amazing people and resources on there. If you want to learn more yourself, there's an excellent course from the Green Software Foundation. Takes about two hours to go through and we'll teach you all of the relevant concepts. And finally, if you want to try a tool, EcoGrader is excellent. I'll leave this there for now, but just one last thing you could try if you have the time. If you use Firefox, it has a built-in power profiler. You can use it to check a website how much uh energy it consumes, and it's something that you might already have installed on your own device. And yeah, that's me. I hope it was useful and have

Speaker 1: plenty of time for questions.

Speaker 2: Thank you for the talk. Uh my question is, uh as a developer who works with Python and Django, um I know that oftentimes it's easy to uh think of certain important topics on uh all my projects if there's some kind of built-in tool that will uh automatically point out like hey This is not not working as well as it should be. Um Do you know of any such tool? Are you currently inventing any such tool that can say This website is probably using too much electricity or too many emissions, that sort of thing.

Speaker 1: Yeah, definitely. So not Python and Django specific at all, but EcoGrader that I have on this list. You give it a link to a site or a page and it gives you a small report that gets you started. Then if you want to look at more Python Django specific things, any kind of application performance monitoring If you look at the CPU and memory usage, it gives you a good sense of where there might be room for improvements. If you want to go further than that, look specifically at uh emissions and power usage. might be better served by the cloud platforms tools. They don't necessarily tend to be very truthful, but the ones from Microsoft and Google in particular can give you quite a good sense if you have a it's like service-oriented architecture with lots of different components.

Speaker 3: Thank you for um for the talk. It will be interesting to um measure the amount of energy we the Django itself consume and also release by release how much we improve this uh yes this amount

Speaker 1: Yes. Uh we we haven't had discussed it yet because it is quite technically challenging still, but I'm definitely hoping to at some point put an annual figure on the emissions of Django and the DSF combined. I guess you want to look at things like CI for example. So there are tools out there that tell you for a given like test run how much energy it's used So we could set up something like that. And yeah, Django has existing performance-focused benchmarks. I assume we can reuse the same benchmarks at look at energy use instead. or in addition to performance numbers. So yeah, some people are looking at this, but we could definitely use more interest in this topic. So that open source projects as well as companies um

Speaker 1: put those figures together and report them back to start with.

Speaker 2: All right, let's give another round of applause to Thibaut.