Building a grid-aware web.

Cheers, John. Yeah. What year is it? 2025. It's already June. So just to set a bit of context, and John kinda helped with that, this talk is not gonna be about CSS Grid. Although we are in Melbourne, we are not gonna be talking about the f one grid either. But if we can just take a moment just to manifest for this guy because how how good would it be if he won the whole thing? But anyway, no f one grids.

If you want to come and talk to me about that later, we can. We're going to talk about energy grids instead, which is probably not something you'd expect at a developer conference. But we're going to look at how we can use information about the energy grid to create front end experiences that reflect that to the user, doing less when the grid is dirty and doing more progressively as the grid becomes cleaner.

So with that said, 2% to 4%, that's the range you'll normally hear people reference when they talk about the carbon footprint of technology. For most companies, it's around 40% of their annual carbon footprint that comes from tech. Okay?

But let's go back to this two to 4% number. 2% to 4% might not seem like a big number when you're thinking about global annual emissions, right? But in terms of comparisons across industries, 2% to 4% puts technology on par with civil aviation and shipping in terms of annual emissions footprint.

And just like aviation and shipping, technology plays an important part in our daily lives as individuals and as a society. And like a lot of things in our daily lives, technology requires electricity in order to make it work. But where that electricity comes from varies.

Some places in the world have access to plentiful amounts of clean, renewable energy. But most of the world, as you can see on this map, still relies on finite fossil fuel sources to power their daily lives. So ideally, we'd like to be using the greenest energy possible for our compute. But that's not always going to be something we can do, as that previous map illustrated.

But we, as technologists, do have tools available to us today to allow us to use the greenest energy when it is available for our compute. And when it's not, sorry, we can do things to make our compute more efficient, both on the back end and on the front end. To do this, though, we first need to understand where the carbon emissions of technology come from.

This is normally represented in these five segments. You'll have emissions from hardware production. So whenever you buy a device, there are embodied emissions that come with that device. That's why we always suggest to extend the life of a device as long as possible so you stretch out those embodied emissions over a longer period of time, and you reduce the need for more devices to be manufactured in the first place.

You've then got emissions from using tech, so the topic that everyone's talking about, data centers, servers and back ends. Transmission, so your networks that connect us all. Front end use, all the devices that we use in our daily lives, and then also the end of life component. Disposal of those devices also has an impact.

Now as people working on the web, we genuinely only have control over the back end and front end segments here. If we are lucky, we might work for an organization with sustainable procurement practices that takes care of the hardware production and end of life segments for us as employees. If your organization doesn't have sustainable procurement practices or you think they should, it might be worth raising that, if you can, within your org.

Meanwhile, transmission, the networks that connect us all, these things are over provisioned. They are always on. They have to be to allow for that that bandwidth to allow for spikes in network usage. There are people working to reduce the energy intensity of the energy use of networks with some different approaches, but as developers, we do not have the tools available for us to make meaningful changes on that segment. So again, that leaves us with the back end and the front end. And we can actually start to do things on the back end today.

At the Green Web Foundation, we maintain a dataset of verified hosting providers that have shown us evidence which allow us to verify their green claims of using 100% green energy to power their services. This is a living data set, so it's something that we update on an annual basis. New providers are added weekly sometimes.

They're updated weekly as well. And then annually, we ask providers to update the evidence they share with us. If they are unable to do so, they're archived in our data set. So this is a living thing. It's constantly changing. We're also in the process of reviewing our guidance and our requirements for what it means to be a green hosting provider. We service this data center in a couple of ways.

You're looking at one of those on the screen right now. We have a directory. So the next time you're starting a new project, you can maybe hop over to our directory and see if you can find a green hosting provider that has that offers the services you're looking for for your project so you can host on them.

We also have an online checking tool and an API, which allows people to enter a website domain and returns a result showing you if that website domain is hosted on one of the verified hosting providers in our data set. But beyond using a green web host, another thing that you can do on the back end is something that's called grid or carbon awareness. Now there's a slight nuance between these two terms, but for the purpose of this talk, I'm going be using them interchangeably.

Okay? So carbon awareness is all about modifying our systems so that they take advantage of the lowest carbon energy sources possible when those sources are available. And there's two ways to do this, moving compute through time or through space. Moving through time is all about running compute at a time of day when there's more green energy on the grid, whilst moving through space is about moving your compute to a location where more green energy is available. Now there is nuance behind both of these approaches.

If everyone decided to run their compute at the same time of day or if everyone decided to move their compute to the same region, those physical grids would have there would be real world implications for those physical grids that would freak out. Right? But there are ways to kind of diffuse that that sudden surge so you can spread your computer out over different times of the day. You can also look at moving to different regions at different times. So you can combine these two methods as well.

But these are the two approaches we have available to us on the back end to make sure that we can use the greenest energy possible for our back end compute. And organisations have been doing this for years. Google's been doing it for upwards of five years now moving to green regions. Microsoft has been trying this out on consumer devices.

So they look for the time of day when there'll be the most green energy on the grid and try to run Windows updates at that time. And Apple's also looking into the same thing for how and when an iPhone is charged. Now this feature, iOS 16.1, I think it was released in The US a couple of years ago.

I'm not sure if it's made its way down to Australia, but if you are an iPhone user, you can have a look and check it out. And just quickly, I'll leave this side up for a moment. These are some of the tools you can look to use on the back end if you are interested in doing some of the moving compute through time or space so that you can use the greenest energy possible.

Carbon runner is a really interesting one. If you use GitHub actions or CICD for your websites or for your deployments, they kind of offer the moving through space thing as just like a single line of code change. So they're an interesting project that started up recently. But what about websites?

What about on the front end? Right? We can't just throw our users out and tell them, hey, come back later. They're probably not gonna do that. We can't tell them all, hey, you should move to another country just so you can use green energy because that's just not possible. As nice as it would be for everyone to move to Spain so that we could use green energy and have siestas and stuff like that. We have to meet our users where they are.

We have to provide dynamic front end experiences that respond to their local energy grids. And this is something that's being tried out today. This is an example from Branch magazine. So Branch is an online magazine that we run at the Green Web Foundation. It was launched in 2020, and it's one of the first and few examples of a website that changes its look, feel, and behavior to respond to the energy grid.

So you can see here that when branches when there's more fossil fuels on the grid, branch provides a core experience to users. Images are hidden. The user opts in to viewing them. We present them with the key information that they've come to the site to see, which is the articles in the magazine. As the grid progressively becomes cleaner, we then add more features and functionality. You can see the colors of the website change.

The pictures also are colorized, and some other functionality is added as well. There's a catch. Because the first time you visit branch, you'll get an experience like this. I'll just replay that for you. You can see that in this video, we've got this gray screen.

Right? This, let's call it, flash of unstyled website. There's that gray screen before the grid aware version of branch is shown to the user. That's not an ideal user experience, is it? The reason we're getting that gray screen is because of how branch was built back in 2020.

All the computers done on the client. A user visits the website, the whole page is returned from the host, and then the grid awareness kind of kicks in. And that's not ideal because we're doing a lot of processing on the users in the user's device. There's a JavaScript being run to get the API, to get information about the energy grid, and then there's a whole bunch of DOM manipulation going on as well to make those grid aware changes based on the results that that API sends back.

Another kind of counterintuitive thing about Branch is that the the information it uses to determine which version of the site to show is based on The UK's energy grid. But the changes it's making on the front end are all about reducing the energy being used on my device. But if I'm here in Melbourne, what's happening on The UK energy grid? Like, I don't care about that.

I care about what's happening on Melbourne's grid. That should be influencing my experience. So branch is a good start, but there is a better way. There is a way we can create dynamic experiences that are based on the user's actual location and the energy grid that they are using. That is the idea behind Grid Aware Websites.

It is a project that we are working on at the Green Web Foundation, thanks to funding from SIDN Fonds in The Netherlands. We've been working on this for the last eight months now, and we've got a few months more left on the funding bid for this project. So there'll still be some more changes to this project as we go. But the idea behind grid oil websites is what I've been repeating throughout this talk, creating online experiences that respond dynamically to the energy grids they are being used on, doing less, providing a core experience when the grid is dirty, and progressively enhancing that experience with features and functionality as the grid becomes cleaner.

And here's how it works. For our implementation of GridAware websites, we leverage edge functions, CDN edge functions, which intercept the request, do all the processing to determine how clean or dirty a grid is, make changes to the website, and then return it to the browser.

And this is what it looks like. So you'll see in this video, we didn't have that gray screen appearing first. The user got the website colored straight away. You'll also probably if you remember back to the previous video, I think it was green, and this one was orange.

I took these videos, these screen screen captures about a minute or two apart in my home in Taiwan. But because the previous version, the online version of Branch was actually based on The UK's energy grid, I got a version of the site that was not relevant to my local grid. Whereas Taiwan, we've got pretty dirty energy grid at the moment.

It's becoming cleaner, but it's pretty dirty. And so I received a version of Branch when I used the GridAware website's code running in a CDN. I received a version of Branch that was actually relevant to my location. So why this approach? Firstly, by running, the processing on an op on edge servers, we're using servers that are actually optimized for this kind of compute.

We're not leaving it up to chance by running it on the user's device. We can we can design user we can design experiences to reflect the user's actual energy grid. This is thanks to an API from an organization called Electricity Maps, who I'll talk about a bit later. And also by using edge functions, we allow this approach to be applied to websites already today in a manner that's incremental.

So you can apply it to specific routes, maybe routes that receive less traffic if you want to try it out, test out the features, get user feedback, and then expand it across the rest of your site. So how do you make your website grid aware? Well, we've been working on an open source code library which does the grid aware checks.

So this library goes off and gets the information from the API and then we'll return a signal to the developer to indicate the state of the grid and whether changes should be made to the front end. I mentioned electricity maps before. They're the API provider we're using. They have data available for a lot of countries in the world, on their energy grids and the makeup of those grids.

It's they have real time information, historical information, and also forecasting. We are working with them to release a new API specifically for this grid aware project. It's an API that we believe will not just benefit our project, but will make grid awareness much easier to apply to other parts of the tech stack as well.

If you remember the map I showed you at the beginning of this talk, that's an open source project from Electricity Maps as well. And they've got an interactive version of it on their website. So if you've got a free ten minutes, jump on there, have a click around because there is a lot of interesting information about electricity grids that you can find out from clicking around on that map.

We're also building helper libraries for the CDN platforms that GridAware websites can be deployed to. So at the moment, we've got helper libraries for Cloudflare and Netlify, and these help you get started by reducing the amount of boilerplate you need to write to deploy grid awareness onto those websites onto those platforms, sorry, and also takes advantage of some of the more advanced functionality that those platforms have to offer, like caching in KV stores.

That said, we would like to work with other CDN providers to try and get grid aware websites, this project working on their platforms as well. So if you know folks from those CDNs or if you know folks at other CDN providers that have edge functions as a service, please do put them in touch with us because we'd love to start those conversations and see how this project can be applied on their platforms too.

And just to finish, like, the GridAware websites library that we're developing is just JavaScript, not TypeScript, but it's got types, but it's JavaScript. So it should work anywhere that JavaScript works. You could run it in the browser, but you gotta make API requests. I probably don't do that. Any server side framework should be capable of running this code.

Same with middlewares and and other platforms like that. I haven't yet tested this, though. So if you want to go out and test it yourself, you can. I give no guarantees, but you're welcome to raise issues in GitHub if you come across any issues. So what about those design changes that we're talking about as well?

The GridAware websites library that we're developing deliberately stopped short of making arbitrary design changes to the websites on which it's applied. And that's because we understand that every website is unique. And every set of stakeholders that is involved in a website project has their own requirements for their website. So at the moment, we believe it's best to leave those decisions up to the developer development teams and the designers that are working on the websites themselves.

But what are some ideas? What are some things you can do? Animation. Maybe only look to animate content when the grid is clean. Animating stuff at 60 frames per second on the Internet, on the web, in a browser is one of the most energy intensive things you can do in a browser. I was speaking to one of the developers at Mozilla on Firefox the other week and they were telling me that if you've got a simple website, some text, some images, simple page, It's there's every chance that the loading spinner in your tab is using more energy than actually processing the code to load your website.

Animation has a big impact on energy use on the web. You could be creative with images, videos, other interactive content like we saw with Branch. Limit compute on the client. Like, I mean, just use less JavaScript if you can in general. But maybe when the grid's dirtier, look to see if you can remove bits of functionality on your website that rely on JavaScript, which aren't necessarily key features.

On my personal website, I've got some filters on the blog blog page of my website. They get removed when the grid is dirty because it's it's not key. You can still go find and find the content you're looking for just using your keyboard. Run fewer dynamic ads perhaps. Look and see if you can replace those with static ads.

And then as the grid becomes cleaner, you can add those dynamic ads back in. There's a lot of compute that happens on the back end as well as part of dynamic ads, so have a think about that. For some more design inspiration, you can check out these two directory websites. They are very good sources of inspiration for sustainable web design, and I hope that they illustrate to people that sustainable web design is not boring web design.

Some of the experiences, some of the websites that are shown on these on these sites are like really, really engaging, really well designed websites. So just because we say a website has to be sustainable doesn't mean we're talking text images and no CSS or very little CSS. We can still design really nice experiences as part of this.

And one of the things we've also heard from people as we've talked about this project is the requirement or the need to give users context and information about what they're seeing and also give them control to opt out if they want to from the experience. So as part of that, we started work on a web component, which will be kind of like an info bar style thing that can be added to a web page that runs the grid aware code. And this allows the user to have context about what they're seeing, the information about their energy grid as well, as well as being able to opt out of grid awareness entirely if they so wish, and then being able to choose between the different views that are available to them if they wanna get a different experience.

That's something we've heard from folks on branch is that they do like to select their experiences rather than just being presented to them. This is something I started developing last week, so unfortunately, I do not have something to share with you. But if you follow us on the socials, you'll find out when when something is ready for this.

So just to wrap up, what about the future? We've been talking about individual websites, applying code to individual websites to make them grid aware. What about a grid aware web? How sick would it be if this was in browsers? Every website could then be grid aware with just a toggle.

Obviously, this consideration has to be given around fingerprinting and tracing and other things like that, as well as how do developers indicate to the browser what changes to make to their website, or do we just trust the browser and let them apply changes to our website? But if this was in the browser, though, I think that would be so, so good.

What about a GridAware CDN? So CDNs at the moment prioritize delivering content from the closest point to the user. But what about a CDN that went, okay. I'm gonna prioritize delivering content from the closest point to the user, but the one that's powered by the most green energy as well. And this is actually something that's kind of possible today.

So this website is hosted on something that's called a solar protocol. So there's a bunch of small servers around the world connected to solar panels, and the version of the website that you receive is served from the one that's receiving the most sunshine at any point in time. It's a green CDN. But if I'm honest with you, the future that I'd love to see is this one, a fossil free Internet.

Because once we get to there, we don't have to worry about grid awareness. We don't have to worry about moving compute through time, through space, or anything else because the Internet will be green by default, and that's a nice future to imagine. That's the future we're working towards at the Green Web Foundation.

We are a Dutch nonprofit that works at the intersection of technology, climate change, and climate justice, and our mission is for a fossil free Internet by 2030. If the ideas in this talk or the idea of a sustainable green Internet appeal to you, please do reach out, follow us on the socials. I've left some stickers on the table next to the next to the entrance, so pick those up on your way out.

Thanks for your time, folks.