Open chrisn opened 3 months ago
AlexDawsonUK
commented
1 month 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 weeks 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.
Is the script/image/ resource popular? I guess jQuery is indeed quite popular, and used by a massive amount of website. But does the photo from the company even from last week need to be on the cdn?
How many times is the content/resource updated? If it is updated every day, distributing it across a global CDN would significanly reduce the impact on the sustainability score.
Is it really accessed all over the world? Do we really need to distribute the photo of the local bakery across the globe?? Does it make sense to have the photo from the company event from last week available on a cdn in South-America?
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 weeks 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.
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:
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.