Compress Your Files and let a million CPUs/GPUs deal with it.

[Internetthought]

4.3 Compress Your Files Environmental: Reduced data consumption and energy consumption (with a slight increase in visitor CPU decompression with server-side techniques).

This suggestion should be reviewed. It appears the authors think that sending less bits saves energy in the network, probably based on mistaken kwh/GB metrics that are widely quoted but unscientific. Networks don't care about traffic and don't use more energy when there are few more bits. This is why fixed networks in France use less energy now than two years ago. This is why KPN has 20x more traffic to consumers and uses 40% less energy in a decade. It also forgets that DVB-C in cable networks is always on and transmitting and Docsis doesn't do much traffic in comparison.

By compressing files you've just forced a million CPU's to burn energy because you flatpacked the file. It's a common mistake, but it hurts the planet.

I explained it recently here https://mailarchive.ietf.org/arch/msg/e-impact/t9lzF7j2DQWi4EDp7Pe2JKlcQdg/ and https://mailarchive.ietf.org/arch/msg/e-impact/j3_lD1LqTFPFsCu6XjumAF3cWmQ/

Rudolf van der Berg

[AlexDawsonUK]

I need to address the issue regarding the kWh/GB measurement based upon assumptions you have posted (It's something Dom Robinson - whom you appear to also know also mentioned in the mailing list).

Our specification takes into account more than a simple calculation when weighing up evidence in justification of a guideline. While it's indeed true that the simple transferring of data between nodes does not have enough weighted evidence to suggest that energy savings can be made, research does suggest that depending on the type of data, once it is being transformed into it's final form, this can have an energy impact.

Research I undertook this year citation, for example showcased that for each added piece of code, it compounds and increases the overall energy demands upon the visitors device (and it's hardware) which thereby will have a resounding effect upon emissions in the same way that you are proclaiming here that we're forcing CPU's to burn energy. As such, page bloat does matter depending upon what form it takes.

Furthermore, as our guidelines closely adhere to ESG practices (which are a standard practice in sustainability), there is a social factor which needs to be taken into account. Of course, a website needs to be good for the planet, but it also needs to be good for people, and matters such as performance, accessibility, and privacy are intrinsically connected to the equation and to exclude them would be detrimental to sustainable practices. Getting such a balance will always be tricky and the discussion for getting a better unit of measurement is nuanced as research is still ongoing and it's a nuanced issue with multiple variables to account for (and naturally we will take your comments under review and discuss it further).

Note: If you could cite the research / sources for each of the items you mentioned, I'd love to include them.

[AlexDawsonUK]

As this issue will await further discussion and research to form an objective decision upon, I will close it as unresolved. Evidence, citations, or other related material posted may re-open this case (beyond our own exploration).

[i-a-i-n]

As previously flagged in this issue, the reliance on the assumption that data has a linear relationship with energy is problematic.

The environmental impact of many recommendations are justified by statements which rely upon this misconception. This does not mean the recommendations are not worthwhile for other reasons (such as accessibility), but they are not going to result in absolute energy reductions through this mechanism and are inaccurate.

We suggest replacing recommendations/benefits that rely on this assumption with recommendations based around concrete evidence-based energy reductions.

See (2.15, 2.16, 2.18, 2.19, 2.23, 2.26, 3.1, 3.2, 3.3, 3.4, 3.9, 3.11, 3.15, 3.17, 3.23, 3.24, 4.2, 4.3, 5.27)

Here are some citations relating to data transfer and energy:

Does not compute: Avoiding pitfalls assessing the Internet's energy and carbon impacts

electricity used by operating network equipment is roughly constant, regardless of whether it is used or not

The power consumption of mobile and fixed network data services

Energy per data figures (kWh/GB) are typically network wide metrics that can be used to understand a network and how it evolves, but further use is limited. Such figures should not be used to calculate an energy consumption related to a specific data service based on amounts of data

Rethinking Allocation in High-Baseload Systems

the existing electricity intensity metrics used for carbon footprints of digital services do not support the stakeholders in taking causally informed action during design and use of digital services

ICT sector electricity consumption and greenhouse gas emissions – 2020 outcome (pre print)

No intensity metric including data traffic is constructed in the present study… allocating electricity consumption and GHG emissions to services or any type of use based on data traffic, e.g., datacenters footprints, is not recommended.

Additionally, in https://github.com/w3c/sustyweb/issues/27#issuecomment-1740833535, you say:

While it's indeed true that the simple transferring of data between nodes does not have enough weighted evidence to suggest that energy savings can be made, research does suggest that depending on the type of data, once it is being transformed into it's final form, this can have an energy impact.

If this is the case, then recommendations should be formed around specific energy impacts – I would be interested in seeing more citations around this. I have concerns around the methodology of the provided citation, which I can provide more feedback on separately if wanted. An interesting study I’m aware of in this area is Native vs Web Apps by Horn et al, but I think there is much more work to be done in this area before concrete recommendations can be given.

[AlexDawsonUK]

I take onboard your comments that clarification should be made regarding optimizing data is unlikely in itself to reduce emissions, but the benefits may be located elsewhere in the stream (such as the social aspect of the ESG cycle). I'll see what adjustments can be made to provide more clarity and include the citations you provided (though I'll need to be careful regarding scope as our work only covers a certain part of this, the infrastructure and measurement is more in the IETF rather than W3C territory and we can't cross over certain lines).

Out of interest @i-a-i-n, you say "we recommend", do you represent an organisation or body?

[i-a-i-n]

Cheers Alex. I represent BBC R&D along with @chrisn. Specifically I work in the Sustainable Engineering research team

[AlexDawsonUK]

I've made dozens of changes throughout the spec reflecting the above, removing direct references to "data-transfer = emissions savings" and replacing it with more tangible emissions benefits or rewording it to explicitly specify other ESG or state outright that data transfer (where mentioned) will not provide an emission benefit but will still prove useful for the user-experience as a holistic benefit for web performance. I've also cited those papers within guideline 3.1 as that guideline is explicitly about examining variables which have either a performance / sustainability / wider-scoping aspect.

Hopefully this will help to improve the specification (and focus it's attention where it needs to be). The next draft will be published with these changes on the week of the 27th so I'll mark this as closed (again) as it has been addressed, however, if further tweaks need attention, we will be allowing pull requests from the next drafts publication as well as the issue system (details to be published) so feel free to add more comments, add further fixes via a PR, create a further issue, etc, and we will be sure to take a look to see if we can hone the document further (without making it too abstract or out of scope).