Issue with the 2022 sustainability chapter - Clarification on Recommended Page Weight Threshold

[LarsFlieger]

In page weight, you write:

Page weight represents the amount of data transferred to access the web page (based only on HTTP requests). As explained before, it is here used as a proxy to calculate Greenhouse Gas Emissions.

It is recommended to keep this metric as low as possible. 1 MB should be a maximum when you get started but 500 kB should be your ultimate threshold.

How did you arrive at the conclusion that 1 MB should be the maximum? Is there any calculation or data supporting this recommendation?

[rviscomi]

Tagging the coauthors

[timfrick]

I didn't write this specific section of the chapter, but it seems to me that the recommendation may have been pulled from the calculator embedded in the post you linked to. The post also links to Core Web Vitals data, which has clear recommended benchmarks as well.

Regardless, in our day-to-day agency work, these aren't hard and fast rules. While we may target a 500 kb performance budget at the beginning of a project, the end result might be slightly higher or lower based on decisions we make together with our team and clients. If we got hung up on the numbers, we'd never finish a project or the product wouldn't end up meeting desired goals, which are an important measure of success.

To that end, we weigh performance budget against page purpose, business goals, user needs, client intent, estimated emissions, and other factors to make project and page recommendations. Our goal is always to make the most sustainable recs, but this is often different for every client based on these varying factors.

With that being said, this approach does help us help our clients understand the potential ramifications of a 250 kb page vs. a 1 MB page vs. a 2.4 MB page, etc. In our experience, unless team training and maintenance are also included with these engagements, it's not long before a 500 kb page becomes a 3 MB page. Then all your good work is for naught and the performance budget numbers don't matter.

Related, we used HTTP Archive data when devising digital carbon ratings, the threshold for which is based on total transfer size. The median for this on mobile is 2.4 MB (a digital carbon rating of 'F'). The threshold for an 'A' rating is 531.15 kb, so a 500 kb page would get you an 'A+'. However, this isn't reflected in the 2022 chapter, FWIW. I'm just sharing to show how thinking has evolved—and continues to evolve—on this topic.

@ldevernay or @gerrymcgovernireland may have different opinions or thoughts to add here.

[LarsFlieger]

@timfrick Thanks for your reply.

I appreciate your insights and agree with your point. However, I'm still unclear on how the 1 MB goal is defined.

• If the calculator was used to determine this goal, what parameters were considered and why?
• While Core Web Vitals have timing data limits, they don't specify page weight limits.

For the upcoming study, it might be beneficial to include explanations for how limits or recommendations are calculated.

[gerrymcgovernireland]

Hi Tim, I agree with what you say below. It’s practical and makes sense. Best Gerry From: Tim Frick ***@***.***> Sent: Friday, July 26, 2024 5:15 PM To: HTTPArchive/almanac.httparchive.org ***@***.***> Cc: gerrymcgovernireland ***@***.***>; Mention ***@***.***> Subject: Re: [HTTPArchive/almanac.httparchive.org] Issue with the 2022 sustainability chapter - Clarification on Recommended Page Weight Threshold (Issue #3710) I didn't write this specific section of the chapter, but it seems to me that the recommendation may have been pulled from the calculator <https://infrequently.org/2021/03/the-performance-inequality-gap/chart/index.html> embedded in the post you linked to. The post also links to Core Web Vitals data <https://web.dev/articles/vitals#core-web-vitals> , which has clear recommended benchmarks as well. Regardless, in our day-to-day agency work, these aren't hard and fast rules. While we may target a 500 kb performance budget at the beginning of a project, the end result might be slightly higher or lower based on decisions we make together with our team and clients. If we got hung up on the numbers, we'd never finish a project or the product wouldn't end up meeting desired goals, which are an important measure of success. To that end, we weigh performance budget against page purpose, business goals, user needs, client intent, estimated emissions, and other factors to make project and page recommendations. Our goal is always to make the most sustainable recs, but this is often different for every client based on these varying factors. With that being said, this approach does help us help our clients understand the potential ramifications of a 250 kb page vs. a 1 MB page vs. a 2.4 MB page, etc. In our experience, unless team training and maintenance are also included with these engagements, it's not long before a 500 kb page becomes a 3 MB page. Then all your good work is for naught and the performance budget numbers don't matter. Related, we used HTTP Archive data when devising digital carbon ratings <https://sustainablewebdesign.org/digital-carbon-ratings/> , the threshold for which is based on total transfer size <https://httparchive.org/reports/state-of-the-web#bytesTotal> . The median for this on mobile is 2.4 MB (a digital carbon rating of 'F'). The threshold for an 'A' rating is 531.15 kb, so a 500 kb page would get you an 'A+'. However, this isn't reflected in the 2022 chapter, FWIW. I'm just sharing to show how thinking has evolved—and continues to evolve—on this topic. @ldevernay <https://github.com/ldevernay> or @gerrymcgovernireland <https://github.com/gerrymcgovernireland> may have different opinions or thoughts to add here. — Reply to this email directly, view it on GitHub <#3710 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQGRE34QASIQJJBP34YEF6TZOJRYLAVCNFSM6AAAAABLQSPWZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJSHE3TOMBTHA> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AQGRE3473EVRJJBPBRN735TZOJRYLA5CNFSM6AAAAABLQSPWZWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUGJGZY4.gif> Message ID: ***@***.*** ***@***.***> >

[timfrick]

@LarsFlieger, the fact that we're struggling to create consensus on the content of a linked source underscores how important it is that chapter recommendations be clear and easy to understand. Thanks again for highlighting this issue. @ldevernay, if I can help review the new chapter with an eye on this specific issue, please let me know.

@4upz or @fershad, in analyzing the 2022 chapter, do you happen to recall how this linked post translated to a 500 kb to 1 MB page weight threshold recommendation?

[LarsFlieger]

@timfrick I totally agree.

The 500 KB comes from this section: https://infrequently.org/2021/03/the-performance-inequality-gap/#:~:text=For%20%22modern%22%20pages%2C%20half%20a%20megabyte%20is%20a%20decent%20hard%20budget.

For "modern" pages, half a megabyte is a decent hard budget.

Only the 1 MB I can't find.

[gerrymcgovernireland]

Agreed here. 500 KB is plenty From: Michael ***@***.***> Sent: Tuesday, July 30, 2024 7:06 PM To: HTTPArchive/almanac.httparchive.org ***@***.***> Cc: gerrymcgovernireland ***@***.***>; Mention ***@***.***> Subject: Re: [HTTPArchive/almanac.httparchive.org] Issue with the 2022 sustainability chapter - Clarification on Recommended Page Weight Threshold (Issue #3710) @timfrick <https://github.com/timfrick> I totally agree. The 500 KB comes from this section: https://infrequently.org/2021/03/the-performance-inequality-gap/#:~:text=For%20%22modern%22%20pages%2C%20half%20a%20megabyte%20is%20a%20decent%20hard%20budget. For "modern" pages, half a megabyte is a decent hard budget. Only the 1 MB I can't find. — Reply to this email directly, view it on GitHub <#3710 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQGRE3YU5KYGJFPY2UZXINDZO7BYDAVCNFSM6AAAAABLQSPWZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJYHAYTMMJWGM> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AQGRE32LRJYARG6CS2N7S43ZO7BYDA5CNFSM6AAAAABLQSPWZWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUGULGKG.gif> Message ID: ***@***.*** ***@***.***> >

[ldevernay]

Hi all,
Thanks @timfrick for your answers. Your review is always welcome.
@LarsFlieger : the main elements were mentioned above : some articles point at a 500 kB threshold (https://infrequently.org/2021/03/the-performance-inequality-gap/) but, for many websites, this might prove tough. 1 MB is usually a good compromise : easy to remember and usually easy to reach by applying some basic efficiency best practices.
In my opinion, you can't have data to support this :

• Averages for existing web pages are way too high
• It depends on lots of factors (type of page, type of website, etc)

Each sustainability threshold should be adjusted for each website (and evolve in time) to make sure it keeps the team motivated. But, usually, 1 MB could be a good starting point (especially for teams who have never heard of sustainability before). 500 kB and under should be the final purpose. But that shouldn't prevent you from starting higher on really heavy websites when you don't want the team to be frustrated.

Measuring websites for sustainability is still challenging : transferred data, DOM size and number of HTTP requests are far from enough. Simply loading a page is not enough either. However we can get started with simple metrics (measurable through browsers) and simple thresholds to get started. With continuous improvement in mind, things will be ok.