The RGESN (General guidelines for the eco-design of digital services) requires limits to be set on page size and the number of HTTP requests on a page via criterion 6.1 (‘Does the digital service respect a maximum weight and a limit on requests per screen?’). While these two metrics give an idea of the impact of transferring elements on the page, they do not reflect the complexity or duration of the processes involved (and the same applies to the DOM). You will find some examples of this in our article on the weight of page elements.Consequently, criteria 6.1 of the RGESN would benefit from being improved by focusing on energy consumption. Historically, these elements have often been overlooked due to the complexity of retrieving them via the browser, but things are changing.
Consequently, criteria 6.1 of the RGESN would benefit from being improved by focusing on energy consumption. Historically, these elements have often been overlooked due to the complexity of retrieving them via the browser, but things are changing.
For now, let’s look at how to define thresholds and limits for a digital service.
Definition
An environmental budget can take two forms:
- Targets to be achieved (reduction of environmental impacts)
- Thresholds not to be exceeded (control of environmental impacts, limiting regression)
It is recommended not to rely exclusively on environmental indicators or scores, even though these indicators are obviously useful for monitoring over time. This is because the methods used to calculate a model may differ or even change, which can affect monitoring over time. In addition to encouraging optimisation, this may risk damaging other aspects. For all these reasons, it is better to rely on flow or measurable metrics.
With Greenspector Studio, it is possible to take into account not only the calculated Ecoscore but also other indicators that can be measured via the transition to CI/CD. If certain thresholds are exceeded, it is possible to block the offending modification.
To set thresholds, it is best to rely on initial measurements and identified areas for improvement. For example, in the case of a redesign, the initial digital service serves as the reference point. The same applies to the maintenance of a website or digital service. When creating a digital service, the logic is somewhat different. The simplest approach is to base your measurements on similar or competing services and define your ambitions accordingly (what you are aiming for, what you want to avoid, all within the environmental budget).
The difficulty with environmental budgeting is finding the right balance so that it is neither discouraging (too difficult to achieve) nor demotivating (too easy to achieve). Thresholds must therefore evolve over time, in line with changes in results. In addition, it is useful to set milestones in terms of planning, accompanied by an action plan that prioritises recommendations.
Metrics
Here we will look at the various metrics that can be used for environmental budgeting, starting with those suggested by the RGESN. Each one comes with suggested thresholds.
Weight per screen
Website
The ideal threshold could be 500 KB for the first load of a web page, 50 KB for other pages or returning to the same page (taking into account client-side storage via the cache).
Mobile application
The ideal threshold could be 500 KB for launching the application, then 50 KB per screen/action.
Requests per screen
Please note: for this indicator, values can increase very quickly regardless of the site’s content. This is because third-party services are virtually ubiquitous, both on the web and in mobile applications. That is why it is important to take into account the nominal scenario (depending on whether the majority of users tend to accept or refuse all cookies) or the worst-case scenario (acceptance of all cookies). In addition, it is important to check that the site works correctly if the user refuses all cookies (and, if possible, that the user’s choices are respected).
Website
The ideal threshold could be 25 HTTP requests when a web page is first loaded, and 5 requests for subsequent pages or when returning to the same page (taking into account client-side storage via the cache).
Mobile application
The ideal threshold could be 5 HTTP requests per screen/action.
Battery discharge
This metric is related to energy consumption and serves as a proxy for terminal wear, which is directly linked to its environmental impact.
The fact that it is measured at the terminal level means that there should be as few other processes running as possible. Similarly, it is important to have a reference measurement (what happens when the browser is running alone or when the mobile application is not launched) in order to have a basis for comparison. This is because the battery discharge rate depends heavily on the measurement terminal used, but can also vary over time.
Site web / application mobile
In order to evaluate battery discharge, it is compared to the discharge during the reference step (on the selected terminal, with the same internet connection settings). Regardless of the step or page, battery drain should, for example, be less than double that of the reference step. This is particularly true for pause steps (in order to limit terminal usage when the user is inactive).
APK/IPA size
The APK/IPA should not exceed 25 MB.
Similarly, it may be beneficial to reduce the frequency and size of updates, taking into account their nature (security, functionality, user experience improvement, etc.).
OS compatibility
In the case of a mobile application, it must be compatible with the oldest possible OS version.
For Android, this reference may help: https://apilevels.com/
Unit thresholds
Finally, it is possible to define size thresholds for each type of element that can be found on a screen. This article by Temesis provides numerous examples: https://www.temesis.com/blog/des-seuils-dalertes-pour-la-performance-web-environnementale/ [FR]
- SVG: 10 KB
- Image: 100 KB
- Font file: 50 KB
- CSS file: 50 KB
- Client cache duration less than 365 days
If a file size exceeds these thresholds, it is generally a sign that optimisations are still possible (see the eco-design best practices reference guide for more information). It is also advisable (in all cases) to adjust these thresholds if necessary.
For CSS and JS files, this can be more complicated because JS/CSS code is often split into several files and loaded at different times. A more comprehensive approach is required, as indicated in this article: https://infrequently.org/2024/01/performance-inequality-gap-2024/
Conclusion
It is increasingly recognised that continuous improvement is an essential aspect of eco-design. To achieve this, it is essential to put an action plan in place and to implement regular audits and measurements of the digital service whose environmental impact we want to reduce. On this last point, the environmental budget sets objectives and identifies what constitutes a regression or an alert.
The environmental budget can also be used to frame expectations in terms of deliverables from a service provider or third party. It must be shared with all project stakeholders and can even be included in the Definition of Done for tasks or even in acceptance criteria.
To conclude, I refer you to an article that details the use of performance-based budgets: https://www.speedcurve.com/blog/performance-budgets/
So, as with ecology, not everyone has the same level of maturity. While best practices are always a good thing, setting concrete limits allows us to better manage our efforts and monitor them over time.
