Reflections on our first advisory group meeting for Grid-aware Websites

The concept of grid-aware is a relatively new one. If you’ve heard of carbon-aware before, there are a lot of parallels between the two.

Making something grid-aware is the idea of making it detect key metrics of the electricity grid around it, and depending on what’s going on adjust something about it’s behaviour. The main driver for this is to understand more about how clean or dirty the electricity is when a visitor comes to your site and alter the site’s behaviour to lower the impact.

As mentioned this similar concept to carbon-aware. But instead of only being about carbon, it places an emphasis on carbon within a wider systems thinking approach. The kind of systems thinking we’ve got in mind relates to electricity grid systems. Grid systems are complex infrastructures serving the needs of many users, and that digital infrastructure is only a subset of. Grid-aware is the concept of thinking about how digital can be changed to better align with the wider goals of electricity operators, which are likely to include decarbonisation but also other positive contributions such as demand management, stability, resilience and equity.

More on the concept of grid-aware.

In the last few years we’ve seen a precursory approach to grid-aware, called carbon-aware, introduced into software and data center solutions. The core idea being to increase the amount of clean energy used by digital infrastructure through flexibility in the location or timing of running digital services.

Microsoft announced that Windows Update is now carbon aware, while Apple have also taken tentative steps in this direction with iOS version 16.1. Google’s been shifting workloads between data centers based on the availability of carbon-free energy since 2021. Projects like our own Grid Intensity Go library, Carbon Aware Scheduler, Carbon Aware KEDA Operator, as well as services from other organisations such as Electricity Maps and WattTime make this possible. 

These tools and services are aimed at backend developers. But what about solutions for frontend developers? What, if anything, can we do to make the interfaces and apps we build respond to the state of the energy grid they’re being run on?

This project aims to provide frontend developers with the tools to be able to do just that.

Yes. A thousand times, yes! 

In an ideal world every website would be performant, accessible, and low-impact by default. Projects like grid-aware websites wouldn’t be needed at all. But the reality is we’re some way off that ideal. As a general web development industry, we don’t do that well at building performant or accessible websites at the moment. 

In the web performance space, the 2024 Web Almanac shows us that less than 50% of websites on mobile record a “good” rating based on Google’s Core Web Vitals metrics. For desktop the figure is 54%. So there’s half the web out there that are failing to meet at least one of the Core Web Vital baselines. Baselines which contribute towards a website’s ranking in Google Search results (setting aside what you think about the effectiveness of search these days).

For accessibility, the WebAIM project releases an annual report titled The WebAIM Million. It looks at one million homepages on the web, and analyses them programmatically using the WAVE accessibility engine. In their latest 2024 report, 92% of the homepages examined had detected WCAG 2 failures. The most common being low contrast text and missing alternative text for images. 

Web performance and accessibility are deeply intertwined with making the internet a more just and sustainable place, the high-level mission we work towards at Green Web Foundation. They provide solid justifications about why we should put effort into making websites better. But these reasons alone don’t seem to be enough to create the internet we need. 

That said, they’re not the only lens to look through when asking if a website is as just and sustainable as possible. There’s also the environmental angle, our area of expertise at Green Web Foundation. The environmental angle tends to look at what physical resources are being consumed in order to serve a website. The most common resource to consider is the carbon intensity (or dirtiness) of the electricity being used. 

The environmental angle provides another compelling argument about why we should care about building better websites. A different angle, or reason to care, can motivate a new section of the web building community to examine their practices and take action. And when doing so, they’ll start to see that the other lenses of performance and accessibility are part of the same puzzle. 

Therefore we see that exploring environmental approaches is a way to complement, not compete with, existing performance and accessibility efforts. With effort and voices from all these different angles we have a better chance of achieving the things we call care about: changing web building defaults so there are fewer negative harms on people and planet.

At its core, the Grid-aware Websites code library empowers developers to understand more about the electricity a visitor is consuming when on their website. They can find out the types of fuel being used and how dirty or clean that is, and then decide if they should adapt their website to make it lower-impact. These decisions can be based on defaults that we’ll include, or parameters that the developer can specify themselves.

Around this core library will be a set of plugins that developers can use to get this code working with different platforms. Initially, we’ll build plugins for content delivery network (CDN) Edge runtimes (think Cloudflare Workers style environments). However, it should really be possible to run our code with any server-side JavaScript framework. That’s something we’ll explore later in the project.

And finally, but arguably most importantly, we’ll be creating a whole heap of documentation, design and development guidance, and a UI/UX catalogue that designers and developers can refer to when using the grid-aware websites code.

No. Our grid-aware code library deliberately stops at making design changes to the websites on which it’s implemented. It will simply return a flag indicating that changes should be made. Decisions about what changes are eventually made to a website to make it “low-impact” are left up to the team working on it because creativity can’t be computed.

We have three hypotheses we wish to investigate in this project:

– There will be a reduction in power consumption on user devices when grid-aware driven, low-impact designs are implemented. 
– Implementing grid-awareness at the server level is less energy intensive than client-side.
– Providing a grid-aware toolkit will unleash more creative ideas for raising awareness about the relationship between digital and physical resource consumption.

The latest Sustainable Web Design Model research estimates the user’s device – that’s the mobile, laptop or tablet being used to view the website – accounts for 54% of the overall energy consumption for the web. 



Of that 54%, just under half is attributed to the use (operational emissions) of the device. The other half happens as a result of manufacturing devices (embodied emissions). The use of devices is estimated to be a significant portion, around a quarter.

The biggest influence on how much energy a device uses when viewing a page is the website’s frontend. A website’s frontend is the content that the user sees and interacts with, as well as what’s running behind the scenes. This includes the text, images, videos, and fonts. It also includes other code that loads, usually JavaScript, to provide dynamic interactions or send/retrieve data on the fly.

Therefore, we think finding ways to reduce the power consumed by a user’s device when viewing a website is a worthwhile place to focus effort. 

Running furthermore running any grid-aware logic on a server, be it a CDN, cloud, or on-prem machine, also has the added benefit of allowing us to consolidate where this compute happens.  In turn we can collectively leverage the compute of those data centers that are powered by renewable energy.

The super long-term success of this project would be that it is archived and that CDNs, hosting providers, web browsers, and operating systems are all providing grid-aware functionality through their platforms – ideally by default.

That’s a ways off right now, so in the more immediate term we’re looking to set some quantitative and qualitative goals around this project that can allow us to gauge its success.

– Number of known websites using code base (quantitative)
– Number of installations of code (quantitative)
– Number of Pull Requests (PRs) and issues opened (quantitative)
– Examples/case studies of techniques applied in practice and lessons learned (qualitative)
– Other forms of contributions such as a donation or case study (qualitative)
– Engagement with CDNs, hosting providers, and browser/operating system developers to extend this work onto their platforms (qualitative)

There are also other areas that this project could have impact deliver in, which are not directly tied to easy adoption metrics, such as:

– We have more data to support or disprove the notion that a grid-aware website is an impactful intervention and in what specific scenarios.
– We can demonstrate that this project has encouraged CDN and cloud providers to share more transparent data on usage of their platforms.
– We can demonstrate that there is more awareness of the relationship between digital use and energy consumption.

We don’t view any kind of learning as a failure. That’s one of the core reasons we are committed to working in the open and being transparent about our findings and approaches. 

If the conclusion we draw after all this work is that this doesn’t help drive any kind of positive action, then at least we’ll know this as a web development community. Our project can serve as a learning point that web developer’s sustainability efforts are better focused elsewhere, or are perhaps most impactful when a grid-aware approach is used in a very specific way.

We’re aiming the first version of our toolkit at two key audiences:

– Web developers: Whether that’s a technical lead, or someone who has the desire to hack away at new ideas within their organisation. We think they’ll be most interested in the code & implementation ideas.
– Web designers: We think they’ll be most interested in what low-impact design changes can be applied and how that will enhance or detract from the UX experience. Our UI/UX catalogue would be speaking to them.

Assuming we arrive at the conclusion that there is merit in adopting grid-aware approaches, we’d look to expand our toolkit to a third key audience: those commissioning websites. You might also refer to this audience as the clients or decision-makers. 

We would provide them with supporting documentation, evidence, and talking points which they can use to convince others in their organisation/clients that the planet should be one of their stakeholders, and what they can gain from such an approach.

Part of this project aims to explore the difference in energy consumption from implementing grid-aware checks on a user’s device (client side) to that of a server. 

So yes, you could see this as just moving a problem around. But we think if you assume that implementing grid-awareness somewhere is worth it, then one place for running that code is superior to another. Or, put another way, we are moving it from lower-spec hardware (end user devices) to infrastructure that’s hyper optimised for these kinds of workloads.

In doing so, we can:

1. Utilise idle compute time that these devices might have.
2. Increase the likelihood that the grid-aware logic is run on a device that’s powered by 100% renewable energy – which is less likely to be the case for a user on a local energy grid.

This concern stems from the notion that sustainable web design is often seen as a “take something away” approach, resulting in a degraded or poor experience. Part of this project aims to explore this notion in more depth. We want to see if this really is the case, or if we can shift this narrative to something more positive through providing examples of what grid-aware design changes add-in or improve for users.

Although our code is stopping short of making design changes to websites, that doesn’t mean we won’t be doing anything in that space as part of this project. In 2025, we are planning to create a UX/UI design catalogue bringing together different sources of inspiration. These might be designs, sketches, or even examples of these concepts working in practice. 

We’re currently working out the best way to create this catalogue so it can be useful to our project, but crucially be maintained beyond the life of our grid-aware websites project funding. We’re also thinking through how to encourage and reward a wider cross-section of the web design community to share their low-impact design ideas, suggestions, and thoughts.

On the device, we can use tools like the Firefox Profiler to measure the power used by a web page. We can do a test of a site to see the benefits of making some grid-aware changes:

– A regular site
– The same site, with grid-aware UX/UI changes applied in the cloud

We can also compare the power utilisation of a site running:

– Grid-aware logic run on the device & applying changes
– Grid-aware logic run on a server (cloud) & applying changes

This would allow us to see any savings made by shifting that workload to servers. 

Using Performance Metrics
How our code library might negatively impact website performance was also something that was raised. There was particular concern around what might happen if the API requests made as part of the grid-awareness checks take too long, or fail completely. With that in mind we can look to use web performance metrics such as Core Web Vitals to assess the impact or benefits of this approach. We are also tracking work to ensure the library “fails fast” through this GitHub issue.

Such an approach could also use a before and after comparison to assess the impacts of applying grid-aware logic and changes to a website on the server or CDN. Another benefit is it would allow us to explore the web performance implications of various sustainable UX design and development practices.

Measuring at the CDN and server side
This gets a little trickier, as we need to understand the power utilisation of specific servers. Frustratingly, CDN providers and hosting companies aren’t forthcoming in sharing information about the power utilisation of code that runs on their platforms. Because of this lack of data in the public domain, we can’t just put some code online and get power usage data back through a dashboard or API. We believe this has to change.

An alternative, more involved, approach could be to provision our own web server and use that to test the impacts of running grid-aware logic and page manipulation. While this setup wouldn’t be a like-for-like with what a hosting provider or CDN might use, it would give us a controlled space upon which we can test against our hypothesis and generate some kind of estimate.