WP Sustainability Plugin - Must Haves & Nice to Haves

[YellowlimeNL]

Assume the WordPress Sustainability Team develops its own WordPress Plugin what are the requirements or in other words ‘Must Haves’ & ‘Nice to Haves’.

For your reference

• a sheet containing some existing sustainability related plugins/initiatives
• a doc with more details on some of them

Work in progress, feel free to complete the list! 🙂

[YellowlimeNL]

My suggestions:

Must haves:

• Measuring the emission of one single homepage load and compare it to 'industry averags' for blogs, corporate sites, webshops

• Providing education (at an external site) about reducing emission

• Nice to haves:

• Collecting the emission scores in order to
  A Benchmark the emission scores [your websites scores .. compared to the industry average]
  B Create insight in evaluation over time [does the plugin result in websites offsetting less emission]

Earlier talks learned me that in order to become a plugin with final goal to become part of the WordPress Core one day, the plugin should not interact with any external APIs or services.

[JamesDominy]

I 100% agree with the above. From a practical perspective, I think we should develop an open standard for emissions data storage and transmission. Different hosting providers can then all funnel their data into a common file location and file format which the sustainability plugin could then use. If we set this standard now, we can (hopefully) avoid the old xkcd competing standards scenario.

I've thought about this a lot, and have some ideas to put forward

1. Emissions data should be reported for a particular site in a mgCO₂/request
2. We should specify what constitutes a request, e.g. served from 'local' cache, PHP executed, served from edge cache or CDN.
3. Emissions data should be stored in a specific file location available to the WordPress Sustainability Plugin
4. The format of the emissions data should be well defined, open, and open to extension (JSON springs to mind here)

[JamesDominy]

Earlier talks learned me that in order to become a plugin with final goal to become part of the WordPress Core one day, the plugin should not interact with any external APIs or services.

@YellowlimeNL do you have any written reference for this. I can't find it in the developer guidelines, but admittedly, searching for it is hard.

[Nahuai]

Thanks for the feedback James.

My reflexion would be, do we aim to create a model to calculate CO2 emissions? or are we confortable using an Open Source project that is well maintained?

For example, CO2.js library it's used but the most popular website carbon calculators (Ecograder, Website Carbon Calculator, Ecoping...).

So that could be a good starting point as standard, don't you think?

[JamesDominy]

Oooh, to quote some of your source material there, "things quickly get complicated" 😁 I really love the framework presented in the calculating digital emissions document, but to their point about closed systems and limited availability of data, most of what I've been trying to do focuses on surfacing data from the data centre portion specifically. Looking at our own data, I say with high confidence that there are two major axes of variability in carbon production: Website design, and where the website is hosted. There's not a lot a website hosting company can do about the first one except to inform you about your carbon production. Obviously hosting can do a lot about the second bit, by offering options in renewable powered data centres.

That said, I wasn't aware of the standard before, but I'm reading through it now, and have a few concerns. Firstly, the choice of reporting metric being kWh/GB averages your site's gCO₂/Gb across the internet as a whole, because getting the actual carbon intensity constant is often impossible. However, if the hosting companies provide this data, then gCO₂/visit can be more accurately calculated for a specific website. I think this is important because (a) it informs the person most in control of emissions what their emissions are more accurately, (b) it enables to more effectively reduce those emissions through their own design choices, and (c) it enables them to more effectively reduce those emissions through their purchasing decisions, i.e. hosting choices; which hopefully starts to put pressure on hosting companies to make better choices available in a way the kWh averaging method doesn't.

I think there might still be issues with /GB bit too, because it can be cheaper, in terms of emissions, to serve a very large static file from a CDN, than to constantly reproduce that same content computationally at source, as an example. Another example would be that AI chatbots consume significantly more energy to produce a few kiloBYTES of text, compared to downloading the same number of bytes in a static file.

This is why I'm in favour of gCO₂/visit; To me it seems like something website owners who aren't experts in carbon emission calculations can understand more easily. Also, it's a metric website owners can influence, because there are only really three aspects of carbon emission manipulation under their control: where they host (influences carbon intensity), how they design their site (influences bytes served Gb), and how the technically design their site by using CDNs/caching/etc (influences carbon intensity). Two of the control levers aren't represented in the /GB calculation.

NB: gCO₂/visit is the same as measurement as my suggested mgCO₂/request, just normalised to grams. If grams are the standard, that works for me, although reporting in grams for many folks leads to a lot of leading zeroes 😉

[JamesDominy]

Okay reading back over what I wrote earlier, I want to point out that the standard I'm proposing we formulate is a WordPress standard for allowing hosting companies (and open source hosting stacks) to store calculated carbon intensity modified information information in way that is accessible to a WordPress site, so any plugin wanting to can use it, and I'm suggesting that the standard unit for that should be gCO₂/visit because that part of the standard takes varying carbon intensities into account...

[Nahuai]

Since CO2.js it's Open Source, would it be an option to give some of the feedback you mention to them (project maintainers)?
I'm just thinking out loud.

If not, would your proposed model be also open to gather outside feedback?
I'm just afraid that we create more models/libraries that we can maintain.

[JamesDominy]

Sorry, I didn't see this reply until now. Lost in the email deluge 😞

Absolutely. On all points. If we can upstream this and make it a more than WordPress only thing, I think that would be a huge win. And I'm open to feedback from anyone and anywhere on this. Also, I've since been thinking about how best to do this, and now believe HTTP headers are a better way. That makes the data available to JS libraries like CO2.js and browser extensions.

[YellowlimeNL]

Great suggestions @Nahuai and @JamesDominy.

[LittleBigThing]

+1 for CO2.js
It requires page size to work with. That is data transferred to build the web page. So we'd need to get that somewhere. Will do a summary about the possibilities to the best of my knowledge below. :-)

[Nahuai]

Also leaving here the comment I left on Slack, so we can have it all the info here:

In this week W3C Web Sustainability Group (the one behind the recently published guidelines) we talked about a lighthouse plugin that's been under develop:
w3c/sustyweb#54
I didn't have the change to look at it properly but I wanted to share it in case we find it helpful.

[YellowlimeNL]

Let me summarize the options mentioned here above and during WP Sustainability slack meetings have for measuring site weight/emission:

• CO2.js library
• Google Lighthouse plugin (under development)
• Google Pagespeed API (used by Websitecarbon.com) (badside: it returns much more JSON data than we require)
• Google Web Vitals Library
• JS Performance API
• Perfume JS

This overview may not be complete, please feel free to add tools to make the overview more complete.

[LittleBigThing]

I have had a chat with @janhenckens about the plugin Statik has released for Craft CMS. Besides being a bit dreamy about what kind of impact WP could have surfacing carbon footprint data in the admin, I'd like to sum up some more practical things:

• their plugin determines the carbon emission of each published page and provides this information in the admin part for the page.
• they estimate the emission using the Website Carbon API (similar to Carbon Footprint). Their impact on the API is rather small, but on a larger scale, it would not be ideal. See this comment for some more background on what could be a better way to go.
• they check each 24h max., no forced updates for sustainability reasons ;-) We kind of decided to check weekly at max.
• we'd need good documentation to get further then awareness: how can one approve their score? Without actionable advice it probably loses momentum...

Then for the dreamy part: ;-)

• having something like this in core could make a huge difference, at least for awareness
• what if Google could allow WP sites use their pagespeed tool to get the page size and enable such information in the WP admin. The page speed API is the only currently feasible way to get the page size correctly and then use it to estimate its carbon footprint. Or what we some infrastructure could be set up to have a tool calculating page sizes for this purpose.
• what would be the impact of this? Including the negative one as well

[JamesDominy]

AFAICT we need two inputs to effectively use the Website Carbon API, we would need bytes and green as inputs (see example request: https://api.websitecarbon.com/data?bytes=1000&green=1. I realise perfection is the enemy of progress, but I would love to see Google Pagespeed as a fallback. It might be more ideal to work with browsers to provide JS APIs to get 'downloaded bytes' more easily. Failing which, perhaps the right approach is browser extensions rather than in WP plugins. Either way, getting the value of green is highly hosting provider dependent. I think it would be useful to provide a standard method for hosting providers to provide a value for green, perhaps in an HTTP header. I absolutely get that this would be open to abuse, and should be verified. So I was thinking we could use it in conjunction with the Green Web Foundation's list, using a logical AND. And if the two values don't match, we display a range of emissions from optimistic to pessimistic.

[jeroenrotty]

Have we discussed or thought about adding it to the Site Health component instead of a plugin? A beta/feature plugin first might be a good way to start though, which we can eventually bring into the Site Health component.

[JamesDominy]

I also think carbon footprint should be front and centre with Page Health (eventually)

[LittleBigThing]

Another idea to add is around fonts, that may or may not become part of core. Preferably it would. :-)

The Font Library is a great new feature in WP 6.5. There are some opportunities there though.
Users can upload fonts and activate Google fonts or fonts from other collection that has been added by plugins. For now, although there are ongoing efforts (I believe that @matiasbenedetto is actively working around this for Gutenberg so he has maybe some more information about this?), there is no option to use system fonts (if the active theme does not provide them; the Twenty Twenty-Four team does). I believe that not having this option is a bit limiting.

• I think that core should provide some font sets as an alternative or fallback. You can find an example to implement something like this in this plugin. Basically it adds a Serif, a Sans Serif and a Monospace font stack to the Font Library as a collection, available for everyone to activate. These fonts are present on your operating system (OS), so no downloading is required on page load (obviously, nothing is saved in wp-content/fonts/ upon activation either).
• A similar plugin, that takes this idea a bit further is this one, adding complete (modern) font stacks. This could be kind of hard to support on the long run (especially in core), but it has all the advantages of the other plugin and above that, it is designed to make the difference for each font stack minimal between the OS used.

Another idea to add concerning the Font Library is that it could suggest to use the woff2 format when uploading fonts since it is well-supported in browsers and is the most lightweight format right now. The Font Library already mentions that using more fonts can make your website load slower; so that’s a great start already. Note that Google fonts are downloaded and loaded as ttf files, not the most ideal format.

[javiercasares]

I think may be a ticket (in Trac) and push that for WP 6.6.

The Font Library is going to change for that version (maybe before) so a new iteration can be good for testing, perhaps first with Gutenberg, and after that in core.

About the woof2, 100% with you https://caniuse.com/woff2

[LittleBigThing]

I found the relevant GitHub issue for editor (which I should have known of), but great to mention it here: WordPress/gutenberg#54186.

[LittleBigThing]

I'd love to see some more inline advice (for example on the media upload page) on image formats to use. I realise that it is not obvious, since there are so many ways to upload an image in WP.

Since images make up a large part of the assets, there is a lot of low hanging fruit there, worth looking at it.

[LittleBigThing]

Let’s also mention here that we’d really need to give actionable advice and thus trustworthy resources (like a handbook or at least some pages) about what one can do to improve their site (as already mentioned here by @YellowlimeNL). Especially if we surface carbon emission data.

[YellowlimeNL]

If i understand it correctly, Perfume.js has the functionality to share metrics with external analytics tools. (https://youtu.be/9DZAVpAubtQ?si=YH1yCHfM_yTKFv3I&t=412). The power of that would be that in case we embed Perfume.js in the plugin, we can push metrics from websites to our own database. This data can be used for our own independent bench mark tool. It even allows us to measure changes (savings of emission) over time.

[LittleBigThing]

I still need to find the time to test Perfume.js. I believe that you can measure the weight of assets loaded but I think, again, only for first-party assets (not for third-parties like CDNs for example).

[LittleBigThing]

Almost forgot to add: deferring the loading of embedded videos!

WP core takes care of lazyloading images and iframes by default. This means, however, that embedded videos (iframes , such as Youtube videos) will still load when they are (almost) in view. The problem with this is that they are accompanied by a giant amount of JavaScript (around 600 kb for Youtube) and often they won't even be viewed. Also, this can have privacy issues (depending on the cookie policy of the website) since the visitor might have never agreed loading the video.

Lazy loading could be taken a step further by loading the (assets of the) video only when it is clicked. This saves a large amount of data. There are some plugins available doing this. The one I use is Lazy Embed by Beleaf, which has no settings and simply defers the loading of embedded videos until clicked. There are other ones, such as Embed Privacy, which is more complex and more privacy focused.

This feature is also performance related. I believe that this is something that could be a core feature for a privacy-friendly software like WP.

[oldrup]

Lazy loading could be taken a step further by loading the (assets of the) video only when it is clicked. This saves a large amount of data. There are some plugins available doing this. The one I use is Lazy Embed by Beleaf, which has no settings and simple defers the loading of embedded videos until click. There are other ones, such as Embed Privacy, which is more complex and more privacy focused.

If you'd like to see this demonstrated IRL, I've made a small analysis on this approach in this blog post:

https://oldrup.dk/en/more-speed-less-tracking-with-embed-privacy/

_Embed Privacy helped reduce carbon emissions by 92%

According to Beacon the CO2 emissions per view of this very page are:

884 milligrams of CO2 by default, **grading F**
74 milligrams of CO2 with Embed Privacy, **grading A+**

This is, of course, true only as long as the videos are left unplayed._

Another thing I appreciate by Embed Privacy, is that it supports, if not all, then most of the embeds available in the block editor, including WordPress TV, Spotify, TikTok and so on.

Out of scope of a WP Sustainabilty Plugin; the embed "placeholder" can be styled to match the colours and size of the actual embed, avoiding layout shifts, and providing in my opinion, a pretty elegant solution. Screenshots from an article in production, where I embed Spotify content:

Before users consent to the embed:

After consent:

[LittleBigThing]

Nice, sounds great! I think that it is a great win, especially since there is also a privacy-related part. I am not sure if styling is out of scope.

A question: is the embed loaded automatically on consecutive page loads once the user has given consent? Or is it still some kind of placeholder (so there is still an emission win on new page loads)? I think, ideally, we should have the best of both worlds, consent separately from immediate loading.

[oldrup]

A question: is the embed loaded automatically on consecutive page loads once the user has given consent? Or is it still some kind of placeholder (so there is still an emission win on new page loads)? I think, ideally, we should have the best of both worlds, consent separately from immediate loading.

We can have the best of both worlds :)

By default, the placeholder loads no external assets at all, nor does it set any cookies. You'll have to click each individual placeholder to load the embed, that holds true after a page reload. (Embed A en screenshot below)

Unless, you click the "Always display embed" checkbox (Embed B in screenshot), in case a flag is stored (Local storage, I think), and the embed from this provider will always load on page load. This flag can be reset by the user.

Embed Privacy is really very flexible. You can extend it to your heart's content. Each embed type, is really just a title, a link to a privacy policy, and a regex pattern to target the embed. Works with popular multi-language plugins like PolyLang too.

[oldrup]

Oh, and sorry if derailing the thread. Maybe discussions reading embeds should be a thread on its own.

[LittleBigThing]

I’d like to add craw optimisation here as well.

In short: when bots crawl a website (which they do too often), they follow all the links (except 'nofollow's if they are nice), but websites happen to have too many, too irrelevant links in their headers, for example. There is a great talk about this by Joost de Valk. This is not so much a performance related thing either, but can be some low-hanging fruit with a huge impact.

There are plugins doing this, even Yoast SEO added a lot of default settings to minimise the number of links present.
Another example is (what's in a name) Crawl optimization.

What do you think?

[oldrup]

Hm, that interesting. I wasn't aware that there were that many. Asset Cleanup, another plugin for plugin and asset management, does offer to remove some of those, too. I experience good results with that, even with the free version of the "freemium" plugin.

https://wordpress.org/plugins/wp-asset-clean-up/

[JamesDominy]

Summary of thread so far 2024-05-20

This is now a fairly long running thread, and there are have been many ideas and suggestions. I thought it would be useful to summarise the contents and hopefully focus the discussion again so we can make some decisions/progress.

Obviously if I've missed something, or got something wrong, please feel free to @ me in the discussion, and I'll correct. Also, @YellowlimeNL, could you please copy this up into the discussion topic block. We could keep it up to date there then.

Proposed Requirements

1. Measure and display website emissions and compare to 'industry averages' by category (blogs, corporate websites, webshops etc)

   • N2H: collect measurements centrally to provide 'industry averages'
     • may conflict with aspiration to become a WP core plugin because of prohibition on interaction with external APIs/services

2. Provide educational material on an external website giving actionable advice

   • notable call outs for specific attention
     • fonts
     • crawl optimisation
     • deferred loading of embedded videos (or other large assets)
   • N2H: Collect anonymised emissions data over time to evaluate effectiveness of plugin in reducing emissions
     • may conflict with aspiration to become a WP core plugin because of prohibition on interaction with external APIs/services

3. Emissions should be reported in a standardised way, using recognised standardised units

   • provide an open method for hosting providers to surface carbon emissions information (e.g. by gCO_2_/Gb or request specific carbon grid intensity fraction); suggested options
     • injected HTML header
     • info placed by hosting provider in file in standard location (useful for more complex data with multiple variables)

4. Use and extend existing client side (JS) libraries/services

   • CO2.js
     • PROS:
       • Widely used
       • Open source
       • Carbon emission specific
     • CONS:
   • Google Lighthouse
     • PROS:
       • Widely used
       • Open Source, Extensible
       • Multiple existing WP plugin integrations
     • CONS:
       • Strongly integrated with Google and Chrome
   • Google Pagespeed API (used by Websitecarbon.com)
     • PROS:
       • widely used
     • CONS:
       • not extensible directly
       • not carbon emission specific
       • returns much more JSON data than we require
       • conflicts with aspiration to become a WP core plugin because of prohibition on interaction with external APIs/services
   • Google Web Vitals Library
     • PROS:
       • widely used
       • open and cross browser
     • CONS:
       • not extensible directly
       • not carbon emission specific
   • JS Performance API
     • PROS:
       • open and cross browser
     • CONS:
       • lot's of work to do on our side, mostly already done by other options
       • not extensible directly
       • not carbon emission specific
   • Perfume JS
     • PROS:
       • open and cross browser
     • CONS:
       • not carbon emission specific
   • Beacon
     • PROS:
       • Carbon emission specific
     • CONS:
       • not extensible directly
       • conflicts with aspiration to become a WP core plugin because of prohibition on interaction with external APIs/services

5. Carbon emissions/footprint should be part of the Site Health

Decisions Made

None so far

Open questions

1. Do we want to eventually be part of WP core?

2. Which requirements are we going to adopt?

3. For requirement 1 (measure and display) who do we want to display to? Visitors? Admins?

4. For requirement 1 (measure and display) what emissions do we want to display? All requests? Only home page requests? Average over a time period? Something else?

5. If we choose requirement 2, do we want to develop our own content or link out to a separate content provider. If the latter, which one(s)?