Fershad Irani - Posts

An impact framework for the Web Sustainability Guidelines

2026-07-12T00:00:00Z

Last year I attended TPAC 2025 in Kobe. A big part of my time there was spent in conversations about the Web Sustainability Guidelines (WSGs) with members of the Sustainable Web Interest Group who were there in person and online.

Through these conversations, it became apparent that the guidelines were lacking a means for people to assess their impact. At the time, there were over 80 guidelines, and the guidelines document was a long read (still is, tbh). A refrain I heard a lot was "People are asking 'where should I begin? what are the most impactful things I can do, now, with these guidelines?' I had been apart of a few metrics related calls earlier in 2025 which was trying to tackle this, though coming up with a single metric (or set of metrics) which could encapsulate the extremely broad scope of the guidelines proved tough.

In one of our Interest Group meetings at TPAC this topic came up again. During that, I put my hand up to create some kind of framework that could help give people coming to the guidelines some method for prioritisation so they might know where to start.

That work came together in a pull request in December last year with a first draft of an impact rating framework for the WSGs. This draft include impact scores for each guideline across the categories of "people", "planet", and "prosperity", as well as impact timeframe. For each, I also included a brief rationale for the scoring provided. That wasn't easy, given how broad the guidelines are. Plenty of time was spent head scratching.

Thankfully, with the PR published, the interest group swung into action. Over the next few months, that framework was refined thanks to the feedback from members of the working group - big shout outs to Siddesh, Susannah, Emma, Andy, Nick, Thorsten, and Tim for their feedback across the various sections. With the review complete, Tzviya, Hidde, Alex, and Rose turned what was a shoddily written Google Doc and messy spreadsheet into a web page ready to be published alongside the WSGs - the Web Sustainability Guidelines Impact Measurement document.

Opinions will differ

It should be acknowledged that there are still large gaps in our ability to assess and quantify sustainability impacts of digital activities. So there is a degree of "expert opinion" and subjectivity in these impact ratings. You probably will find some that you disagree with - that's fine. If you do, then give the rationale a read. If you still disagree, then there are a few things you can do:

Get involved with the W3C and the Web Sustainability Interest group
Raise an issue on GitHub with constructive feedback, suggestions, and proposed changes
Share the impact ratings with others who might have domain knowledge and who can contribute through the two ways mentioned above

While opinions about individual impact ratings may differ, one thing I'm really proud of about this artefact is that it, in my opinion, has achieved what it sets out to - to make the WSGs as little bit more approachable by having a way to prioritise them based on impact categories, timeline, or overall impact score. I've also heard on the grapevine that some other Interest Groups in the W3C have seen the document and wish they had something similar for what they're doing. I'm glad the Sustainable Web Interest Group was able to get this published, and hope folks find it useful!

Nobody cares

2026-03-31T00:00:00Z

I recently learnt about the closure of CarbonRunner, a service that aimed to enable running of continuous integration and continuous delivery (CI/CD) in the cleanest available region (in terms of grid carbon intensity). The idea behind CarbonRunner was a sensible one - location shifting the running of automated workloads to the cleanest available location should result in a lower carbon impact from these tasks. This vibes with the ideas we explored last year in our Grid-aware Websites project.

The CarbonRunner website today has a few short paragraphs announcing the closure of the platform. These are grouped under three headings, which explain the reasons behind the closure. The first of these headings is "Nobody cares".

Nobody cares
Building environmental based products is hard because nobody really cares. People care about money, they don't seem to care about environmental savings, even if they're faster

This theme gets carried forward in to the second point:

The cost of switching is too high
Switching services takes a lot of mental energy, it requires due-diligence, plenty of testing and teams that want to embrace it. Going back to point #1, software developers, on the whole, do not care about carbon savings, even if it would have been the easiest thing to swap over their CI jobs. Software developers do not have to think about the carbon emissions of each function they write.

People care but the incentives are not there

The two statements above feel loaded with emotion. I get it. The team behind CarbonRunner put loads of time and effort into building and promoting their product. It sucks to see all that work fall flat. But the sentiment that "nobody cares" doesn't truly reflect the reality.

People care, but their ability to influence their organisation's decisions is limited. At the level of the decision makers, there just isn't the incentive to care enough about digital sustainability. I saw this in action at the W3C's TPAC event last year, where I had multiple conversations about web sustainability with individuals from a number of large web technology companies (and not just Google, Microsoft, and Apple). However none of those large organisations are actively engaged in the process of developing the Web Sustainability Guidelines, at least as far as I'm aware. Despite their own sustainability claims, they just don't have the incentive to work on sustainability on the web in way they do for, say, performance.

Selling sustainability is tough

This, again, is anecdotal. After around 6 years focusing on digital sustainability I've seen a good share of many a web sustainability focused company come and go. From analytics platforms, to ones like CarbonRunner focused on developer tooling, a common theme has been that "there's not enough interest to make this viable". I think that's going to keep being the case until there are genuine incentives for organisations to care about digital sustainability.

At the moment, if you're in the carbon reporting game - providing carbon emissions data to organisations for their annual reports - then there might be something in it for you. That's where the legislation is at the moment - "show us your data". Legislation is a large driver of organisational incentives when it comes to sustainability. I'd love to see web standards or customer demand replace that, but I just can't see that happening. What non-reporting based legislation there is around digital services these days seems to focus on efficiency, but is targeted at data centers and large energy consumers rather than smaller organisations and workloads.

Unfortunately, I feel that in the years to come, we will continue to see that selling sustainability as an add-on to a larger product might be a feasible strategy. But solely sustainability focused products will remain a hard sell. Not because nobody cares, but because the incentives just aren't there to drive organisational adoption.

2025 in review

2026-01-10T20:30:00Z

I understand this might be a bit late for a year in review. We've had a lot of Touch stuff going on here in Taipei for the last couple of weeks, and tonight is my first chance to sit down with the cat and get this written.

2025 was a year on the go, with (mostly work related) travel throughout the year. It was also a year of catching up with old friends from Taiwan in their new homes overseas, and meeting a whole bunch of internet friends for the first time at conferences and events. Unlike 2024, which was a World Cup year, Touch took a bit of a back seat for most of the year and with it so did whatever fitness I'd build up in the year prior.

Personal

Once again on the personal front 2025 was a quiet year, which bodes well ... right? For family, my sister got married earlier in the year, which gave our family a chance to be together for a few days for the first time in a while. On the other end of the spectrum, the year ended with the passing of my partner's grandmother. She was 101 years old, and had moved to Taiwan in the 1940s from Fujian province. We've spent the time with family, helping prepare items for the ceremonies that are performed per the Taoist tradition.

Travel

Places I visited in 2025 (in no order): Sydney, Katoomba, Mudgee, Orange, Melbourne, Singapore, Zurich, Lucerne, Munich, Amsterdam, Den Haag, Rotterdam, Tokyo, Chiba, Hiroshima, Kurashiki, Kyoto, Kinosaki Onsen, Tottori, Matsue, Izumo, Taichung, Nantou, Bangkok.

I am way behind on getting the rolls of film I shot in all these places developed. There's some colour stuff from Switzerland and Australia, as well as some black and whites from Tokyo up on https://film.fershad.com, but still a heap more to come. I've put a few into this post though.

Meeting friends old and new

A big part of traveling this year was attending various conferences to speak about Grid-aware Websites. Other trips included time in Europe with the Green Web Foundation team, and TPAC 2025.

The time in Europe was definitely a highlight, where I spent time in Zurich, Munich, and the Netherlands. During 3 weeks on the road, I was able to catch up with a few old friends, meet a few internet friends IRL, and making some new friends as well.

Many of the highlights came from the summer in Europe, during a pleasant heat wave (pleasant for someone coming from East Asia). Spending a few days in Zurich catching up with two former colleagues and their new born was by far the best of the bunch. Meeting Romain Jacob, Michael Oghia, as well as Hidde de Vries and family in person were all great times. And, of course, catching up with all the folks I work with at the Green Web Foundation for a few amazing days in Munich was very special.

Finally, no trip to Europe would be complete without some Touch. I spent a week bouncing around the Netherlands doing some work and mixing in training sessions with the Dutch Mens National Team and clubs in Amsterdam, Den Haag, and Rotterdam.

Work

There's been a lot happening in Green Web Foundation land this year, and I've been lucky to be part of a nice chunk of it.

Grid-aware Websites

Most of my year was spent working on the Grid-aware Websites project. I'm really pleased with what we were able to achieve with the help of our funding from SIDN. We were able to work on delivering a core code library, and starters for working with both Cloudflare Workers and Netlify Edge Functions.

Most pleasing was being able to deploy grid-awareness to the Branch magazine website as part of a design refresh. It was a really stressful time getting the redesign planned, implemented, and tested while balancing travel and conference speaking. Probably not something we'd want to try again (he says now), but definitely worth the hard yards.

Through the year, I also gave three talks promoting the project in Singapore, Melbourne, and Amsterdam. Although we weren't finished with the project at the time I did those talks, they presented a great chance for me to refine my thinking about the project and to hear the thoughts for new audiences.

2026

2026 is shaping up as a landmark year for Touch in Taiwan. We are in the process of preparing to send two teams to an international tournament for the first time - with plans for a Womens and Mens Open teams to travel to Australia for a tournament in April. This will take up a lot of my spare time through the first half of the year, as I'll be coaching (and maybe playing for) the Mens Open team.

On the work front, we're working our way through finalising some important updates to our provider verification process which we plan to get public feedback on shortly. Besides that, we're also continuing to work on the carbon.txt project, and I'll be involved with that in a variety of ways.

I also might have been bitten by the TPAC bug following the recent session in Kobe. It's a long way away, but I'm wondering if a trip to Dublin might be on the cards for TPAC 2026 😅.

As always, if you're visiting Taiwan for work or play, let me know. There's so much to do, see, and eat (mostly eat, though) here. I'd love to show you around!

We nearly had power profiling in Chromium

2025-11-25T00:00:00Z

One of the things I learnt at TPAC 2025 is that the Chromium Issue Tracker (also known as "CRBUG") is a thing. More than just being a thing, it is (as the name might suggest) the place where you can raise bugs and issues you might encounter in Chromium browsers. Beyond that, it's also a place where ideas for new Chromium features can be raised, triaged, and tracked.

Chromium is the open source browser project that powers Google Chrome, Microsoft Edge, Samsung Internet, and a host of other browsers. Features built into Chromium might not always make their way into all the browsers that use it immediately (or ever), but it sure does make it much easier to get adoption.

So what's this about power profiling?

Since 2022 (Firefox 104), the Firefox browser has included the option for developers to capture "Power Profiles" from within its developer tools. This gives developers the means to get granular information about the energy being consumed by the browser as a website is used. In terms of front-end measurement for web sustainability, it is close to the best possible data folks can work with.

But Firefox is but one browser. Chromium-based browsers have by far the largest market share, and yet have little-to-no sustainability-related features built into their developer tooling at the time of writing.

So I was really surprised to find this closed issue on CRBUG from ... wait for it ... 20-friggen-14! In it, there seems to have been work done by folks at Google and Intel to include power profiling into the Chromium DevTools in a way that looks similar to what Firefox has now built. It appears as though code was committed to make this happen, but was then rolled back in 2015 after an "offline discussion".

Why this matters

Having the ability to capture a power profile on a website from within then browser opens up a whole new layer of information from both a sustainability and performance perspective. With power utilisation being shown alongside really detailed information such as stack traces and browser events, developers will be able to actually assess their code is having on real user devices.

Having the ability to capture power profiles across multiple browsers may even help improve the efficiency of those browsers themselves. Profiles of the same site across multiple browsers might shed light on areas in which the same code uses more or less power depending on the browser it is running in.

Probably most importantly though, it will allow us to start presenting the case for improving website sustainability backed by meaningful data rather than models.

I mean look at this screenshot from the case study that's linked in the description of the issue. To have this in the most widely used browsers on the planet would be a huge step forward for the frontend web sustainability community.

And yes, I did choose this screenshot on purpose because I'm all about fish power.

Inside jokes aside, discovering this has given me some hope that we might one day be able to get power profiling into Chromium browsers. It's been done before, why not try and land it again ~

Reflections on TPAC 2025

2025-11-23T00:00:00Z

Earlier this month, I had the pleasure of attending the W3C's annual TPAC meeting.

TPAC?

TPAC is something I've heard about a lot through my time as a web developer as a place where folks gather to nerd out over web standards. It is a five day event, with a mix of detailed working/community/interest group meetings and breakout sessions for idea sharing.

TPAC 2025

TPAC 2025 was held in Kobe, Japan from November 10 - 14. It's a short hop from Taiwan. Conveniently, lined up with the weekend of the Japan Touch Nationals in Tokyo, which I was able to referee at before making my way down to Kobe.

I was attending TPAC as an Invited Expert and part of the Sustainable Web Interest Group (SWING). All my involvement with the group until this time has been asynchronous due to time differences. I'd had one off real-time conversations with people in the group, but never been involved in the more general group discussions or decision making. So TPAC 2025 was a great opportunity for me to meet some other SWIG members and be an active participant in the process of developing the Web Sustainability Guidelines.

I was also attending TPAC with my Green Web Foundation hat on. On this front I was keen to better understand how things get implemented in browsers, as well as better understand the topic of Verifiable Credentials and the role that might play in bringing greater transperancy and data access to the digital supply chain.

Highlights from TPAC 2025

Below is an unordered list of highlights from the week:

Spending the week chatting, hanging out, hunting for gifts, and sharing meals with the few Sustainable Web Interest Group members who were able to make their way to Kobe from all parts of the globe.
Chilling in the hallway and hearing all the different conversations going on about how certain features might be implemented in browsers, or written into standards, or other really nerdy stuff. All waaaay over my head, but cool to hear.
Finding out that there's a project to introduce Digital ID Wallets in Taiwan based on the W3C Verifiable Credentials standard. It's always nice to see Taiwan represented at large global events, and it was even better to be able to make a connection with Denken who's working on the project. We've already caught up again now that we're both home.
Conversations on the metro to the conference venue with Jake Archibald and Adam Argyle. These are two folks who's work I've followed (and has helped me out) for as long as I've been in web development, and it was great to jsut have a casual chat and say thanks.
Getting a much better understanding of what it takes to get features into the browser. Thanks to Barry Pollard for taking the time to explain that process to me.
Being able to speak with folks from all the major browsers about the kinds of web sustainability features we might be able to build, and again getting ideas from them as to the best way to move things forwards.
Catching up with my mate Christian, who's been living near Kobe for the past 7 years. We ~~worked~~ drank together in Taiwan, and it was great to reacquaint in Japan.

It was a fulfilling week, but an absolutely exhausting one too. I'm an introvert bro, and my battery was well and truly drained after it all (probably why it's taken so long to get this post out). That said, I'd do it all again if the opportunity presents itself~ ✌️

Thinking about network sustainability for frontend developers

2025-09-02T00:00:00Z

This post started out in a different form three months ago. Between then and now, I've written a draft, got some feedback, engaged with some folks on this topic, and sharpened my thinking. Thank you Chris and Romain.

One of the first suggestions that most folks get when asking how to make their website more sustainable is "reduce the amount of data transferred". Hopefully it's not the only advice they'll get, but even today it is still prevalent. That is perhaps because it presents an approachable solution to something that might initially feel daunting.

Before you start thinking ah here goes Fershad again talking about data transfer being a poor metric, this post will (I hope) be a bit different. I want to present a "yes, but" argument for reducing data transfer especially when thinking about our impacts on the network.

Nuance. Wild, I know.

Data transfer and network sustainability

I've written a lot about the use of data transfer as a poor proxy metric in web sustainability. See:

As is my policy, those are strong opinions but loosely held. I think there are other things, like animation and JavaScript bloat, that should be a higher concern for a web developer who's thinking about the sustainability of their website. That said, it's normal to see advice like the kind I alluded to in the opening paragraph. That's not to say the advice is wrong. Being judicious in what a web page requires to load and be functional can lead to web sustainability (and performance) benefits. But we need to be honest with ourselves that those benefits are more a result of the actual design and development decisions made (e.g. load on interaction patterns), rather than the fact that less data is transferred.

This is especially true when we think about the impact our website might have on the network. If we reduce the amount of data our site transfers, then that would reduce the amount of energy being used by the network, right?

No.

Network devices are always on, and their energy consumption is generally independent of their traffic load (especially for fixed networks, mobile and wireless are a bit more dynamic). There’s a spike in energy consumption when the device is first turned on, and then its power usage stays relatively constant even as utilisation increases. The below graph illustrates this. It is taken from a paper titled The Internet of tomorrow must sleep more and grow old by Romain Jacob and Laurent Vanbever.

Power draw of networks is decoupled from data transfer.

Yes, but

So where does that leave us? If we want our websites to be sustainable across the entire stack (i.e. servers, networks, user devices), what can we do to improve the sustainability of the network layer?

My answer? Reduce data transfer.

While data transfer might be a poor proxy for network energy use, it is still a valuable metric to use. For fixed networks, reducing the amount of data a website transfers isn't going to have any immediate impact on the energy used by the network. It's not an "instant sustainability win" that you can claim, but rather it sends a singal that can have longer term results. Meanwhile for mobile networks, where the marginal cost per additional bit of data transferred is higher, reducing data transfer can have some impact on network energy use. That's important as more and more internet consumption takes place on mobile devices.

It takes all of us

The network has to always be on, and over-provisioned, so that it has capacity to handle surges in traffic, outages, or other sudden shocks. Network operators do this provisioning based on a baseline traffic volume that they expect. Again, Romain Jacob covers this wonderfully in his Green IO talk The Internet is Getting Emptier; That's a Sustainability Problem.

So for us, as web developers, to have an impact on reducing the energy being used by the network we need to lower that baseline traffic volume. That's not something an individual developer can achieve on their own. It takes all of us.

The signals we send

The median page weight of a mobile page has risen by 1.8 megabytes in the past 10 years. It's around 1 megabyte for desktop over the same period of time.

Median page weight over time. From HTTP Archive

At the same time, our lives as a whole have become incredibly data-hungry. Streaming services, mobile apps, social media, the rise of video, AI chatbots in everything, the list goes on. We send and receive a lot of data every day, which signals to network operators that more infrastructure should be provisioned to allow all that data to be transferred.

My blog by itself wouldn't even register as a blip on the radar in terms of network traffic. A network of websites, might show up as something. The entire web ecosystem though, yeah network operators would probably notice that. That is especially true for sites serving video content, which is taking up an increasing share of internet traffic. More on video in a tick.

As a collective, we need to disincentivise network operators from deploying extra capacity. Because as we saw from the chart earlier, turning on a new network device uses a lot more energy than letting an existing one sit idle on the network. That's before we even consider the embodied environmental costs that come with the production of new devices.

So how do we, as web developers, send this signal to the network operators? In two ways:

We reduce the weight of our web pages whenever possible.
We set sensible data usage defaults in the sites, apps, and services we build.

Reducing page weight

There's plenty of documentation and guidance on this for web developers, yet we still see page weights going in the opposite direction. I feel a large part of this is down to two factors - frameworks and video. My recent look at the COP30 website turned up the use of a framework that bloats the website for no real valuable reason, coupled with limited image and font optimisations. Meanwhile for developers working with video, there's probably some difficult conversations to be had with clients and designers. I'm not saying remove video completely, but rather explore what techniques can be adopted to reduce the amount of video content that is downloaded automatically without a user action triggering it. Those aren't easy conversations to have, as Nic Chan shared in her recent blog post about Grid-aware Websites, but they're important ones to have.

I once had a client that sold sustainably made household items, and they wanted their website to reflect their commitment to sustainability. I suggested the usual high-impact things like reducing the size of media and using a static site generator. They didn’t mind the statically-generated approach as it helped them save on hosting costs, but they didn’t want to give up their use of background video, a decision that forced every user to download an additional 6MB of video.

Nic Chan

Sensible defaults

This one probably applies more to larger websites or platforms, and again those serving video content probably can have the largest impact here. Take the example of YouTube, a video platform that is seeing an ever increasing number of podcasts publishing there as well. Podcasts are primarily audio a medium, so a sensible default for YouTube to set for that kind of content would be to provide an "audio only" option, with the ability for viewers to switch to a video feed if there's something they really want to see (thanks Chris for this idea btw). Likewise other steps, such as having "play the next video automatically" set to off by default, or setting "autoplay" to off by default in social media apps/platforms can all have a significant impact at scale.

To reiterate, neither of these things (reduced page weights and sensible defaults) will reduce tangibly the network "carbon footprint" of an individual website (okay, perhaps YouTube or Netflix are a different case). What they can do is signal to network operators that we don't need to continually grow capacity, that we can make do with what we have. That signal only gets through, though, if it comes from the collective action of a large part of the web development community.

Final thoughts

At the level of an individual website, data transfer has no meaningful relationship to the energy consumption of network infrastructure that is serves it. Practically that is true, the impact of an individual website is close enough to zero to be zero. But in another way, the amount of data we transfer can have an influence on network energy consumption. Not in the immediate term, but over a longer period of time, the decisions we make today as web developers can have a significant impact on the energy profile of the networks that transport our content.

So sure data transfer does not equal network energy use. Yes, but ...

A web component for grid-aware websites

2025-08-26T00:00:00Z

One of the objectives we set for the Grid-aware Websites project when we started planning it last year was to deploy the project on the Branch magazine website sometime in 2025. In doing this, we could show the code working on a website that receives a non-insignificant amount of regular traffic. It would also be a full-circle moment for the project, since the original Branch design in 2020 was one of the things that got me exploring the ideas of carbon-aware frontends in the first place.

As we got further into the project, Branch took on an increasingly important role in showcasing our ideas for how grid-awareness could be applied to websites. We commissioned a new issue (Issue 9) for the magazine around the theme of attunement – reimagining digital infrastructures attuned to life systems, planetary constraints, and our collective needs. This ties in with the whole idea of Grid-aware Websites, designing online experiences that are designed to work with and within the constraints of the energy grid. To top things off, we decided that it'd also be nice to give Branch a modern redesign in the process.

All these things kind of depended on each other, so we decided to bite the bullet and tackle them at the same time. As it would happen, that coincided with members of our team traveling for work, taking extended leave, and our entire team coming together in Munich for a week of away days and Green IO conferencing. There was a lot to do, and a lot of disruption to work around, but to use the vernacular I grew up with – "She'll be 'right, mate". (Narrator: She did, indeed, end up alright)

The idea for a Grid-aware Status Bar emerges

Tom Jarrett designed the first issue of Branch back in 2020, and we reached out to him to see if he'd like to help with the 2025 grid-aware redesign. To our delight Tom said "yes"!

The original Branch design had a small selector near the top of the page which allowed visitors to change between the different grid aware views available – live, low, moderate, high. Grid intensity information was also shown on the far right side of the page (i.e. "Low grid intensity", "Moderate grid intensity", or "High grid intensity").

A screenshot of the original Branch design showing the "Grid intensity view" selector in the top right right and grid intensity information on the far right side of the page.

From the earliest iterations of the 2025 redesign, Tom explored ways to adjust this section of user interface (UI). His aim was to provide visitors with simultaneously much more context about their grid-aware experience, and more control to adjust that experience if they want to. We began calling this part of the design the "grid-aware switcher", which later became the "grid-aware status bar".

An early draft of a "grid-aware switcher" on the redesigned Branch website.

Exploring through iteration

As we continued iterating on the redesign, the Grid-aware Status Bar started to become central to how grid-awareness would be applied to Branch from both a technical and user education standpoint. Many conversations were had about the look, feel, and functionality of the status bar. But many more took place focusing on the wording for different elements within the status bar, what those words conveyed, and how much information should be presented to visitors.

Some of these decisions were made for us by the information available from the Electricity Maps Carbon Aware Websites API which is the data source behind grid-awareness on Branch. For example, the API returns only "high", "moderate", or "low" values for a given energy grid which limits the level of detail we could present to a user without making additional API requests.

Other important decisions made in the design process focused on user experience considerations. These went through several rounds of iteration and discussion before we landed on a final design. These included things like:

How location information was presented to the user (and at what granularity – local grid, region, country?). We went with the local grid for Branch.
Whether to show a "last updated" timestamp in the status bar. We eventually opted against this to a) reduce clutter, and b) reduce confusion to the user as to what the timestamp is representing.
How to word the toggle which activates the automatic application of grid-aware design to the website versus allowing the user to choose the view for themselves. After much iteration we settled on "Grid-aware mode" to describe this toggle.

Building a status bar for reuse

When I first saw Tom's early drafts for a status bar, my mind went straight to "this is brilliant, and something that we should build so that it's reusable by others as well". Pretty much I was thinking about it as a web component from day one. That thinking also played an important role in some of the decisions we made around the design and functionality of the status bar.

The "status bar as a web component" idea also introduced some scope creep into the Grid-aware Websites project and Branch redesign. It's not something we had originally planned for, but it just made so much sense to do that it was worth the extra effort. An unintended upside of this scope creep was that it allowed us to separate out some of the redesign workload – Hannah could work on WordPress code, and I could build out the web component. Being able to split up the work like this was probably critical to us getting the redesign out in time for the Branch Issue 9 launch.

Screenshot of the grid-aware status bar web component implemented on the redesigned Branch website.

Features and functionality

While building the web component to be used on Branch was the main priority through the development process, we also wanted to make sure we created something that would be useful to any website looking to use the Grid-aware Websites library.

Drop it anywhere on a page

While on Branch we've put the status bar at the very top of the site, we can't be certain that everyone using it would want to do the same. Using CSS Container Queries, a newish feature on the web platform, we've been able to build the web component so that it resizes based on its parent element on the web page. This means that if someone wants to put the web component into a narrow sidebar menu, they absolutely can!

In fact, I use the web component in the footer of this site. To demonstrate this flexibility, I've also put the web component into the middle of this blog post which is a narrower container.

Oh hey, and these web components are interactive too 😉. Click around. Note: I've set fixed location and grid intensity for the demo in this post. The one in the footer should show your actual location and grid intensity.

Demo

A big thank you to Hannah for getting the initial Container Queries implementation into the component!

Preserve state across pages

The Grid-aware Status Bar allows website visitors to opt-in/out of automatically applying grid-awareness to their browsing experience. If grid-awareness is not being automatically applied (as is the case when you visit Branch for the first time), the user then also has the ability to select the website "mode" they wish to see.

It's important that these user choices are retained as a user navigates the website. To do this, the status bar web component saves state via cookies in the browser.

Why cookies?

The Grid-aware Websites library has been designed to function server-side (or in edge functions). As a result, we need some way for the state selected by the user (e.g. grid-aware mode auto on/off) to be communicated with the server in a reliable way. By setting cookies in the browser to capture visitor actions, our server-side grid-aware code library can read those cookies as they are included in each website request that is made. This allows the server-side code to know which version of the website to return if the user has manually selected one, or if it should proceed with performing live grid-aware checks instead.

Customisable grid-aware modes

On Branch we have four different "grid-aware modes" for the user to experience. Other websites might have three, or even just two. So we've made it possible for developers to specify and name the different "grid-aware modes" on their website. Visitors can select from these modes when not automatically applying grid-aware changes. Developers can also set a default mode which is seen by users who have not manually selected a specific mode to be displayed.

Screenshots showing the four display modes for the Branch website.

We view the status bar web component as being the main way a visitor would interact with grid-aware functionality on a website. For that reason, we felt it was important to have some way for developers implementing it to tell people about what they're seeing and where they can go to for more information. Developers can do this by setting a couple of data attributes on the web component when adding it to their page.

The information popover is triggered when a visitor clicks the 'i' icon located on the far right side of the "grid-aware toggle". Again, we've taken this opportunity to use some newer browser features which allow for popovers to be added to a page with minimal additional code. Thanks to Nick L for pointing us in the direction of the Popover API. In supported browsers, the popover will appear below or above the web component as space allows. On other browsers, it will appear in the center of the screen with a darkened background. Eventually as all browsers include this new API, the user experience will become consistent.

Using the Grid-aware Status Bar on your website

The Grid-aware Status Bar is an open source project. You can explore the code repository on GitHub which includes installation steps and configuration instructions. That's also the place you can post any bugs or issues you might be having with the Status Bar, and of course we also welcome community code contributions as well!

If you're using the Grid-aware Status Bar on your website, then we'd love to know about it. You can tag us on LinkedIn, or get in touch with us via our support form.

The Status Bar is designed to work with the Grid-aware Websites project. If you are using the Grid-aware Websites project on Cloudflare Workers, we have a plugin that can help you get started quickly and includes configuration options to automatically include the Grid-aware Status Bar on your site. We've got a blog post coming out soon about how we did this, but in the meantime you can learn more in the Grid-aware Websites Cloudflare Workers plugin repository and in this tutorial on our Developer Docs website.

COP30 website review. Rinse and repeat.

2025-08-10T00:00:00Z

COP30 (Conference of the Parties) is taking place later this year in Brazil. Which means there's another COP website for me to review. I took a break last year, having done three COPs in a row (read my takes on the COP26 (Scotland), COP27 (Egypt), and COP28 (UAE) websites). Coming back to it this year, COP30's website sees some familiar patterns emerge when compared to those previous reviews.

What we’ll look at

For this review, I'm going to focus mainly on the desktop version of the COP30 English language homepage (https://cop30.br/en), looking at it through a web performance and sustainability lens.

A screenshot of the COP30 English homepage

Real world performance

To get an idea of how folks around the world are experiencing this website, let's use Treo's free Site Speed Audit tool to explore data from the Chrome User Experience Report (CrUX). It's worth noting that this data only represents a subset of Chrome browser users and that it covers the entire domain (not just the homepage).

Looking at the data for June 2025 at the 75th percentile, we have:

Metric	All devices	Mobile (50.8% of visits)	Desktop (47.8% of visits)
Time to First Byte (TTFB)	1.4 seconds	1.3 seconds	1.6 seconds
First Contentful Paint (FCP)	2.8 seconds	2.8 seconds	2.8 seconds
Largest Contentful Paint (LCP)	3.2 seconds	3.3 seconds	3.2 seconds
Interaction to Next Paint (INP)	125 milliseconds	150 milliseconds	75 milliseconds
Cumulative Layout Shift (CLS)	0	0	0.05

A few things stand out in the numbers above which we can explore later in this post:

That's a long TTFB. It probably points to no CDN being used on the site, and it being served from a single location.
The time gap between the TTFB and the FCP values indicates that there's a bit of content being downloaded in the client before it's displayed. This is also normally an indicator that a client-side framework is being used to render the site.

A long TTFB

This is a familiar story on COP websites. When I looked at the COP27 website in October 2022, it had a TTFB of 1.3 seconds. Drilling into that site surfaced that it was hosted in Egypt itself, and wasn't using a content delivery network (CDN) to serve assets to visitors from other parts of the world. My guess is that the same thing is happening with this COP website.

Checking for a CDN

To quickly check for the use of a CDN, I'll use CDN Planet's CDN Finder tool. Putting the homepage URL through there returns an "unknown" CDN result. Clicking the "show IPs" option above the results reveals an IP address of 189.9.168.10.

Hosted in Brazil

With this IP address, the most obvious next thing to do so we can find out where the site is hosted would be to chuck it into any one of the number of IP to location tools that are on the internet. That's too obvious, so I did not do that. Instead, I did a lookup for the IP address' Autonomous System Number (ASN) - which is a way to tell what network it belongs to.

The results returned SERVICO FEDERAL DE PROCESSAMENTO DE DADOS - SERPRO. That looks like it belongs to a Brazilian government agency of sorts. A quick look in IPinfo then confirmed that the IP address is traced back to Brasilia, the capital of Brazil. So yeah, probably hosted at a government facility.

Server sustainability

Based on this information alone it's hard to say how sustainable the server is. It could be housed in a building running on solar and batteries for all I know. Or it might be using the local grid. Brasilia is located in a part of Brazil that consistently generates over 75% of its energy from renewable sources though, so that's a good start at least.

Given that COP is a global event, you'd expect people around the world would be visiting the website for information and updates. It would really be nice to see a CDN being used to help get content to folks just a bit quicker. It would align with the recommendations in the Web Sustainability Guidelines, and could even help a tiny bit with the FCP related issue we'll touch on next.

A longer time to content

The site appears to use Plone CMS (<meta name="generator" content="Plone 6 - https://plone.org">) for both managing content and for the frontend. I've not heard of Plone before, but from their website and docs I understand that it deploys sites with a React frontend via something they call Volto UI.

I kinda guessed it'd be something React-ish the first time I loaded the site and looked at the Network tab in my browser's DevTools. There was a 2.6 MB client.8227f7bd.js being downloaded. That's a React smell. This one file made up almost half of the total data transferred for the homepage to load - 5.4 MB on desktop, 4.7 MB on mobile. For reference, the HTTP Archive State of the Web have the median web page size for desktop at 2865.6 KB and 2562.5 KB for mobile (July 1, 2025). One JavaScript bundle for this site is around the same size as the median web page. 🤯

This client.8227f7bd.js file allows the whole site to then be rendered as a Single Page Application (SPA), with subsequent "page" navigations downloading a few dozen kilobytes of JSON content from the Plone CMS backend (which is on the same server in Brazil we talked about earlier).

Really? An SPA? For this?

This website, like other COP websites before it, is nearly entirely images and text only. That's it. As far as I can tell, the only real bits of "interactivity" on the site are:

The language selector
The cookie notification banner
The loading of content on some pages (e.g. News, Letters from the Presidency, Speeches)
A search function in the menu bar

It also seems that content for the website footer and social media links also rely on the client.8227f7bd.js file to populate.

But like ... text and images. This entire website could be a static site, or server-side rendered. There's nothing "snappy" about the SPA experience, nor is anything being saved by initially downloading the 2.6 MB client.8227f7bd.js file. To be honest, it's probably 10 times more JavaScript than is actually required for a website like this to function. Yet, visitors are forced to download that bundle, parse it, and execute it. That's just waste if you ask me.

The only upside of this approach comes as a result of the Brazilian host server, no CDN situation described above. With an SPA, we only need to fetch and download a 10-30 KB JSON package from the server for each navigation event, rather than waiting for the whole page to come back. But even that can be solved with upcoming web features like Speculation Rules or a tiny library like instant.page instead.

To reiterate - there is no reason for this website to be bloated in the way that it is by React. Plone provides a Rest API which allows it to be used as a headless CMS (one where the backend and frontend are decoupled). From there you've got your choice of frameworks many of which support server-side rendering or static site generation out of the box.

It wouldn't be a COP website without image issues

The first COP websites I reviewed (COP26) got more attention than I expected because of a 3 MB image in the footer of the page. That attention helped get the matter to someone at the UK's Government Digital Services team who could at least optimise the image to reduce its size.

Images have been a constant theme through the other COP website reviews I've done as well. This site keeps that trend going.

Firstly, credit where it's due. The site is loading responsive images, and using native lazy-loading as well. By the looks of it that comes along with the Volto UI frontend for Plone CMS. What it lacks, though, is support for delivering modern image formats. This GitHub issue from 2020 has one of the lead developers on Plone suggesting it should be added to the platform.

Of the 14 images loads on the homepage, 13 are SVG or JPEG format. One happens to be a WebP image. So I guess if the user uploads a WebP in the Plone CMS, that image will still be processed, resized, and served to the frontend. But that leaves it up to the user to do any image optimisations. Not ideal.

I honestly feel that by now this kind of thing should be table stakes when assessing a framework or platform for building a website. If image optimisation, including generating modern web formats, isn't baked into the platform, then it should at least be able to be added through a plugin or extension at the very least. Heck there are even online image optimisation services that can be used (for an eventual cost). It's a solved problem.

Finally, fonts

The site loads around 530 KB of font files, out of which 380 KB is for the Google Material Symbols Rounded font family. That font family, as far as I can find on the homepage, is used to generate just seven different icons. I've shown the icons in the table below by importing them from Google Fonts using the optimised code I'll mention in the next paragraph.

keyboard_arrow_down

arrow_forward

newsmode

manage_search

The COP30 website loads in an entire font family for just these seven icons. It is absolutely possible to subset the font instead. In this way just the required content is downloaded. Doing so takes the size of the downloaded font file from 380 KB down to 2.6 KB. Here's the one line code change required to do that:

client.css

diff


- @import url(https://fonts.googleapis.com/css2?family=Material+Symbols+Rounded:opsz,wght,FILL,GRAD@20,300,0,0&display=block)
+ @import url(https://fonts.googleapis.com/css2?family=Material+Symbols+Rounded:opsz,wght,FILL,GRAD@20,300,0,0&icon_names=arrow_forward,close,cookie,keyboard_arrow_down,language,manage_search,newsmode,search&display=block)

Wrapping up

This site is mainly an information portal for COP30 visitors and those around the world interested in the COP process. Some of the recommendations I've made above could be implemented fairly quickly and have a small sized impact on performance and sustainability.

However, the SPA nature of the site is harder to solve, being a decision that is made early in the life of a project like this. There is absolutely no need for React to be used on this website. Now that it's there, it's hard to back out without rebuilding a lot of things from the ground up. I'd love to see that happen here, but won't be holding my breath. Perhaps a better choice will be made for COP31.

Carbon and energy as metrics for web sustainability

2025-07-31T00:00:00Z

The W3C Sustainable Web Interest Group has been doing a heap of work over the last year to update the Web Sustainability Guidelines (WSGs). I'm an Invited Expert in the Interest Group, but due to time zones haven't been able to attend any of the regular meetings in real time. Man's gotta sleep, yo! Instead I catch up with the recordings and occasionally join in on conversations asynchronously.

One thing the Interest Group has been thinking about is how to prioritise the guidelines in a sensible way. This is important, because among the first questions folks normally ask when they learn about web sustainability is "what are the most impactful actions I can take to improve my website's sustainability today?" Having some form of prioritisation for the WSGs to address this would go a long way towards increasing their adoption.

To date, it seems like most of the thinking about how this prioritisation might happen has been based on carbon impact. I had some thoughts about this approach, and that has sparked a healthy discussion which is captured in this GitHub issue.

This blog post aims to flesh out some of my own thoughts on the metrics we use for web sustainability, with a particular focus on carbon emissions and energy use.

Tracking the impact of a change

Most of the tools that people first encounter in their web sustainability journey (like Website Carbon or Ecograder) give carbon estimates as the main result. But, I believe, to go further we really need to begin thinking about energy as a key metric in web sustainability.

Thinking back to the question I posed earlier - "what are the most impactful actions I can take to improve my website's sustainability today?" - what comes next? After taking whatever steps are recommended to them, people are most likely then going to want some way to track the impacts of those changes.

It'd be easy to say just chuck the website through Website Carbon once a week and see how things go. But that leaves out a lot of the nuance that is worth taking into account. A better approach is based around considering:

what part of the tech stack (backend/frontend) has been changed,
the nature of the workload or system that was changed, and
the kind of optimisation (or change) that has been made.

Carbon emissions and energy use as metrics

The rest of this post looks at two specific metrics - carbon emissions and energy use - to see where one or the other might be a more suitable metric for tracking the impact of a web sustainability related change. I'll get around to showing how I think about this using the three points I just mentioned.

Why not just use carbon emissions?

To calculate carbon emissions, you need to know how much energy has been used for the thing you're interested in and then multiply that by carbon intensity of that energy. The carbon intensity of energy varies depending on the kinds of fuel sources that are used - renewables and nuclear have a lower carbon intensity than fossil fuel sources. As a result, carbon intensity varies around the world as different energy grids are fuelled by different mixes of renewables, nuclear, and fossil fuels.

This leaves carbon emissions as a metric open to being manipulated based on the carbon intensity that is used in their calculation.

Carbon intensity data can come from a variety of sources, can be average or marginal figures, and can range in their granularity (hourly, monthly, annual). This presents a few issues:

People tracking this metric themselves will need to understand and decide the carbon intensity data source to use.
People using a tool/service to track this metric are relying on the decision made by that tool/service.
It's not possible to compare like-for-like optimisations across websites if different carbon intensity is used.
The lower the carbon intensity the lower the resulting emissions, which presents an incentive to select the lowest value.

Using a global average carbon intensity is one means of standardisation, but result in more generalised carbon calculations compared to using more location specific carbon intensity. That's why I feel that we really need to consider where it makes sense to go beyond carbon emissions alone as a metric.

When to use carbon or energy as a metric

As I touched on above, the decision on whether to use carbon or energy as a metric should be based on a combination of these three points:

what part of the tech stack (backend/frontend) has been changed,
the nature of the workload or task that was changed, and
the kind of optimisation (or change) that has been made.

Each of these steps is influenced by its predecessor. The part of the stack you're in will determine the nature of the workload which, in turn, determines the optimisation options available. Together they should point you in the direction of the most suitable metric to use to track the impact of a given change.

Backend

Nature of the workload

Tasks on the backend can be categorised in three buckets to capture their nature:

Time sensitive - need to run at/near a fixed time
Location sensitive - need to run in a fixed location
Neither time nor location sensitive

Optimisation option: Demand shifting

Workload: Time or location sensitive

Time and location sensitivity are two sides of the same coin. With workloads like these, the two strategies that are most commonly used to reduce their carbon emissions are time and location shifting.

If your workload is time sensitive then you'd use location shifting - moving compute to run in a location where there is more low carbon energy available.
If your workload is location sensitive then you'd look at how you can apply time shifting - changing when compute is run so that work happens at a time of the day when there's more low carbon energy available.

Since the goal of time/location shifting is to maximise the use of low carbon energy, it feels sensible for carbon emissions to be the key metric when these optimisations have been made.

Optimisation option: Code/platform efficiency

Workload: Any

Making efficiency improvements to a backend operation is a definite way to improve its sustainability. Efficiency improvements can take a few forms including code changes, platform changes, or infrastructure changes.

The primary goal of efficiency optimisations is to reduce resource consumption, with energy being one of those resources. So tracking energy use (and other resources if you can) as metrics would be the best way to go about assessing the impacts of any backend efficiency optimisations.

Optimisation option: Switching to clean providers

Workload: Any

I've got biases here. One of the things I do at the Green Web Foundation is maintaining our Dataset of verified green hosting providers. We have a Directory for finding them and filtering by service/region too. You should check it out.

Here the goal would be to use service providers that are running entirely on carbon-free energy, or that are using as much carbon-free energy as possible and taking meaningful steps to phase out fossil-fuels from their operations entirely. Carbon emissions is a suitable metric to use here.

Frontend

Nature of workload

The frontend is much more restricted in the nature of the workload it handles. It is inherently time and location sensitive. When people visit a website, they expect it to be there and available for them to use. Turning a website off because the energy grid is using more fossil fuels would be a very hard feature to sell to most stakeholders. Likewise, it's impractical to ask a user to change their location to a cleaner energy grid just so they can use your website.

On the frontend, we have to meet users where they are.

That's the idea behind the Grid-aware Websites which we've been developing at the Green Web Foundation. But this blog post isn't about that.

Optimisation strategy: Code/design efficiency

Since we can't time/location shift our website or users, the only lever we can really pull from a web sustainability perspective on the frontend is efficiency. That means taking steps to improve the efficiency of our website code as it runs in the browser, how our designs and interactions behave, as well as optimising any server-side rendering that may be happening.

I feel that carbon emissions is a poor metric for testing these kinds of changes. By focusing on efficiency, we're focusing on reduced resource consumption and energy use. Those should be the metrics we use to track the impact of any frontend changes.

Additionally, the carbon intensity of a grid can change hour-to-hour, day-to-day, week-to-week (you get it ...). This makes it really hard to get consistent, meaningful results. If I test my website at midday in Taiwan and then again at 9pm, I'll get different emissions results for the same site because the grid intensity here changes through the day.

For this reason, energy use should be the metric to use whenever possible for the tracking web sustainability changes made to user interfaces or interactions.

Too many words, give me a table

There's a lot of words above this, so if you're after a TL;DR then I hope this table helps.

Segment	Sensitivity	Optimisation strategy	Tracking metric
Backend	Location sensitive (fixed location or limited ability to move)	Time shifting	Carbon emissions
Backend	Time sensitive (fixed time or limited ability to change)	Location shifting	Carbon emissions
Backend	N/A	Time shifting, location shifting, efficiency (code or platform)	Time/location shifting: Carbon emissions Efficiency: Energy use
Backend	N/A	Change hosting provider	Carbon emissions, PUE, WUE, other
Frontend	Time & location sensitive	Efficiency (code, platform, or framework)	Energy use

Conclusion

The conversation around metrics, estimation, and measurement in digital sustainability is one that is ongoing. As the WSGs get updated, and as assessment tools start to implement them, I'm sure that some of my views will change. The opinions presented in this post are strong yet loosely held.

In the context of the WSGs, the conversation is in the open on GitHub. Leave a comment there if you feel compelled to, or let me know your thoughts via the socials or email.

Sam, champion, yeah nah

2025-06-16T00:00:00Z

Last week, Sam Altman published The Gentle Singularity on his blog. The post is a look towards a near future where superintelligence has been achieved. Sam's tone is along the lines of "look, this is inevitable and really when we think about how far we've come in such a short space of time it's probably just around the corner". Of course he'd strike this kind of tone, given he needs to ensure people (read: investors) believe that OpenAI is still absolutely worth its valuation and the cause is worth pumping billions more dollars into.

Most of the takes I've seen about this post on my own socials pick up on the energy and water used for a ChatGPT query that Sam mentioned in his post. I'll get to that, but there are other parts of the post that I want to first touch on because, to me, they are more important (and concerning) than the far-from-transparent energy and water figures.

Robots that can build other robots

The economic value creation has started a flywheel of compounding infrastructure buildout to run these increasingly-powerful AI systems. And robots that can build other robots (and in some sense, datacenters that can build other datacenters) aren’t that far off.

If we have to make the first million humanoid robots the old-fashioned way, but then they can operate the entire supply chain — digging and refining minerals, driving trucks, running factories, etc.—to build more robots, which can build more chip fabrication facilities, data centers, etc, then the rate of progress will obviously be quite different.
Sam Altman - The Gentle Singularity

That's two paragraphs just to say "line goes up, indefinitely".

Brother, what planet are you on? Because it sure as heck isn't the same planet that myself and 8 billion other folk are trying to inhabit. We're on a planet where resources and space are both finite. A planet that's already living well beyond its means, and has been doing so for decades. So automate away all the digging and refining you want, but tell me what happens when there's nothing left to dig and refine? When there's no more space for that next datacenter? What happens when you've taken all you can from this planet, our only planet, so that robots can create more robots?

Finiteness aside, one does not simply add new capacity to the energy grid. Unless you want to throw the humans of this planet under the bus by running unpermitted fossil fuel generation to drive those datacenter-built datacenters. Because renewables will only get you so far, and the costs of adding that plus additional baseload power for your inbred datacenter onto the grid is already being worn by regular households.

Perhaps all that's a bit harsh. Perhaps we're soon going to have a nuclear fusion future with unlimited clean energy generation for robots to make robots, datacenters to make datacenters, and for humans to ... I really dunno. I wonder if there are any companies that would need more funding for whom selling a future like that would be just the thing to snag some extra investor dollars, Sam?

"We" the few

Throughout his post, Sam also talks about what "we" need to do to prepare societies for the impending superintelligence future.

There are serious challenges to confront along with the huge upsides. We do need to solve the safety issues, technically and societally, but then it’s critically important to widely distribute access to superintelligence given the economic implications. The best path forward might be something like:

Solve the alignment problem, meaning that we can robustly guarantee that we get AI systems to learn and act towards what we collectively really want over the long term.

Sam Altman - The Gentle Singularity

By "we" (emphasis in the quote above is mine), I'm pretty sure that Sam isn't referring to me and you here. He's actually just meaning him and his mates in the global Tech Bro Club. Because why would they ask us? They didn't ask when they trained their huge large language models on our material, including copyrighted works. They've pretty much gotten away with that and made a pretty penny in the process too without giving any of that back to the authors, writers, creators, and other real humans whose work they stole.

So "we" means Sam and friends setting the rules by which superintelligence will be part of our future. It feels pretty sound to leave them in charge of solving safety and ethical issues on behalf of society. They've got a great track record of that, what could possibly go wrong and who could possibly be left out?

Inference energy

People are often curious about how much energy a ChatGPT query uses; the average query uses about 0.34 watt-hours, about what an oven would use in a little over one second, or a high-efficiency lightbulb would use in a couple of minutes. It also uses about 0.000085 gallons of water; roughly one fifteenth of a teaspoon.

As others have pointed out on social media, this is pretty much meaningless without context. What model/s do these figures refer to? What kind of operations are being performed (text-based chat, image generation, voice processing)? That level of transparency, which isn't asking for much really, coupled with more detailed data (i.e. percentiles at the least) would be amazing to see from OpenAI.

As an aside, I wonder if one of the reasons OpenAI is being so closed about the inference energy consumption of their tools is because they too are reliant on the large datacenter operators to host their compute. And these providers aren't the most forthcoming with information about their own energy use, even when compelled to do so by law. So it could just be that Sam doesn't know because his hosting providers can't/won't tell him. Given the billions at play here, I find that hard to believe but still possible.

So yeah

Fershad Irani - Posts

An impact framework for the Web Sustainability Guidelines

Opinions will differ

Nobody cares

People care but the incentives are not there

Selling sustainability is tough

2025 in review

Personal

Travel

Meeting friends old and new

Work

Grid-aware Websites

2026

We nearly had power profiling in Chromium

So what's this about power profiling?

Why this matters

Reflections on TPAC 2025

TPAC?

TPAC 2025

Highlights from TPAC 2025

Thinking about network sustainability for frontend developers

Data transfer and network sustainability

Yes, but

It takes all of us

The signals we send

Reducing page weight

Sensible defaults

Final thoughts

A web component for grid-aware websites

The idea for a Grid-aware Status Bar emerges

Exploring through iteration

Building a status bar for reuse

Features and functionality

Drop it anywhere on a page

Demo

Preserve state across pages

Why cookies?

Customisable grid-aware modes

Extra information in a popover

Using the Grid-aware Status Bar on your website

COP30 website review. Rinse and repeat.

What we’ll look at

Real world performance

A long TTFB

Checking for a CDN

Hosted in Brazil

Server sustainability

A longer time to content

Really? An SPA? For this?

It wouldn't be a COP website without image issues

Finally, fonts

Wrapping up

Carbon and energy as metrics for web sustainability

Tracking the impact of a change

Carbon emissions and energy use as metrics

Why not just use carbon emissions?

When to use carbon or energy as a metric

Backend

Nature of the workload

Optimisation option: Demand shifting

Optimisation option: Code/platform efficiency

Optimisation option: Switching to clean providers

Frontend

Nature of workload

Optimisation strategy: Code/design efficiency

Too many words, give me a table

Conclusion

Sam, champion, yeah nah

Robots that can build other robots

"We" the few

Inference energy