w3c / sustyweb

Sustainable Web Design Community Group
https://www.w3.org/community/sustyweb/
Other
175 stars 12 forks source link

Define the system boundaries #101

Open chrisn opened 4 months ago

chrisn commented 4 months ago

There is an assumption in the guidelines that saved time converts into emissions savings. In one example of many, https://w3c.github.io/sustyweb/#assess-and-research-visitor-needs says:

which will help reduce emissions as developers will spend less time building a product with unnecessary features

This is only potentially true if we consider a system boundary that stops at the immediate concerns of a given website (or its development), and does not consider developers' or visitors' existences beyond that point. For example, a developer may move onto another project rather than switch off their computer or the lights in their office; a website visitor may be browsing to fill time and move onto the next website.

Similarly, https://w3c.github.io/sustyweb/#rigorously-assess-third-party-services contradicts this by recommending that you "create your own clickable icons and widgets, rather than relying on third-party services to host or allow embedding within your product or service". Should we assume from this that emissions resulting from data transfer are considered to be greater than the emissions generated by developer time? What criteria or metrics should we use to make such a decision?

The system boundary should be clearly stated when looking at what effect the guidelines will have. Consideration is important when assessing the overall effect of a change on a system and potential rebound effects (see Earles & Halog).

We suggest defining clear system boundaries that your guideline works within, be clear about the limitations of this, and to avoid making assertions where there isn't adequate proof or certainty.

AlexDawsonUK commented 3 months ago

Agreed, this is an area we need to provide a lot more clarity upon, both in the introduction and within guidelines themselves (where necessary). Consider this added to the future improvement list.

astuanax commented 2 months ago

I'd like to point out a similar concern about the use of Content Delivery Networks (CDNs) even when the infrastructure provider practices sustainability.

The use of CDNs presents a complex trade-off between performance and energy consumption. While CDNs can improve content delivery speed and reduce latency for users, whether the impact is really beneficial and sustainable depends on a number of factosr.

Benefits might be:

Reduced latency and improved user experience Lower bandwidth consumption for origin servers Potential energy savings from optimized content delivery

Potential Drawbacks:

Increased infrastructure requirements Duplication of data across multiple servers Continuous energy consumption from always-on CDN nodes

Whether hosting something on a CDN make sense, depends on the treshold and balance of the benefits and drawbacks listed above.

Lately I am seeing a trend where very simple websites are put on gcloud or aws using all kinds of cdi, cdns, cloud compute, s3 like storage and proxies in order to deliver very small and local websites that will only be usefull for very a geographically limited audience.

Sure all these guidelines make sense for the youtubes and newyorktimes of the internet, but I would add clear usage requirements and justifications for using a CDN.

AlexDawsonUK commented 2 months ago

Thanks for the feedback! You've given me some ideas for potentially some added Success Criteria we can add in terms of requirements for CDN inclusion, but agreed, with many of our guidelines (CDNs especially) there are a number of potential trade-offs with their usage. We're hoping to be a lot more explicit about this in the future.

AlexDawsonUK commented 1 month ago

I've provided some clarifications within SC 4.1 and SC 4.10 around Redundancy & Provisioning, Update Regularity & Local Audiences to cover the points you've made. Hopefully it addresses some of the gaps that existed in the draft.

They will go live in the next published version of the specification.

Note: We're still working on the system boundaries issue and it will be addressed in due course.