Category: Sobriété du web

Analyze site overconsumptions 

The measurements were carried out on a Samsung Galaxy S9 phone, in WIFI (3 iterations).

After measurements, the results confirm the initial suspicions:

• EcoScore: 59/100 (Network: 82, Client: 35)
• Data transferred: 292 kB
• Total battery discharge: 5.28 mAh
• CPU process (1.11%)

Data transfers are indeed low and, as a result, the score on the Network side is very good.

On the other hand, the Client-side score is low, which correlates with high battery discharge and high CPU impact (especially for such a light, static page). Generally speaking, this can be due to third-party services, animations or even calculations (mainly JS) performed in a loop.

Let’s start by looking at what happens when the user is inactive, via Greenspector Studio :

We noticed 3 data peaks that are probably directly linked to Chrome (which collects usage metrics and regularly checks the functionalities offered by the browser version).

This hypothesis was then investigated using a web proxy (as the requests in question did not appear in the browser). This confirmed that these requests were indeed linked to Chrome.

On a heavier site, these requests may go unnoticed, but not here.

The methodology used is based on that described here: https://greenspector.com/en/how-to-audit-android-mobile-application-requests/

But above all, we need to question the strong fluctuations of the CPU. There are a few animations on the site, but most of them are only triggered by scrolling. So they shouldn’t have a direct impact on the CPU when the user is inactive and the animations are not triggered.

We therefore fall back on the Performance tool in Chrome’s developer tools: https://developer.chrome.com/docs/devtools/performance

If we look at what happens during 10 seconds of inactivity, we can see that the processor is very busy, with a large number of events to be processed continuously. This quickly gives rise to a large number of JS processes (listening or observing) waiting for certain user interactions to trigger animations.

All this is managed by a widely-used library: GSAP.

Having reached this point, and before going any further, I contacted Julien-Antoine directly to schedule a time to present my findings to his team.

After a few exchanges, it appeared interesting to work together on this subject. The aim is to see how we can reduce the impact of the page through analysis and action. To do this, we decided to proceed in an iterative way: proposing an initial list of recommendations and applying them one by one, so as to be able to estimate the impact of each one through measurement.

Experimentation around the site

First of all, we need to make sure that the badge displayed on the site, taken from Website Carbon Calculator, is not involved (which would be the last straw). To do this, such a badge is integrated into an empty HTML page and measured using a benchmark.

The EcoScore is 95, the data transferred is very low (a simple JS script of less than 2 Kb retrieves everything needed for display in a single operation) and the impact on the processor is negligible (around 0.25% CPU load).

The badge is therefore found not-guilty.

At the same time, the Konfiture team is deploying the site we want to study on a separate server, which will host the different versions produced. An initial measurement is carried out to set the benchmark for the rest of the project, as certain metrics may vary depending on the site’s hosting conditions.

The first version measured removes the Lenis library, which partly manages animations.

Version 1.0.2 corresponds to the further optimization of SVG (vector graphics). The result is a slight reduction in transferred data.

Version 1.0.3 adds native progressive loading for SVGs, as well as the implementation of a CDN and compression (brotli) of text files (including SVGs). The result is a significant reduction in data transfer.

Version 1.0.5 removes all animations. For the end customer, this is not an option, as animations are considered essential to make the site more attractive. But once the other elements have been optimized, this measure gives us a target to aim for. Here, we can see a reduction in data transfer (less JS required), but above all in CPU usage (which remains one of the metrics most affected by animations, due to the calculations required).

To go further on this subject, I refer you to two other articles on this blog:

• https://greenspector.com/en/does-a-sober-site-have-to-be-ugly/
• https://greenspector.com/en/reduce-the-weight-of-a-web-page-which-elements-have-the-greatest-impact/

Version 1.0.6 does away with the need for JS code to manage animations. The problem is that animations are continuous. Even if, technically, this approach has less impact on the processor (which can easily be verified using Chrome’s Performance tool), it degrades the user experience and poses a problem for accessibility.

After discussion of the subject, this point appears to be prohibitive. While CSS-only animation management is a good compromise for environmental impacts, accessibility degradation must be avoided.

Initial results do not correspond exactly to expectations. After analysis, it appeared that having continuous animations hindered the detection of inactivity during measurements and artificially prolonged the scroll time.

As a result, version 1.0.7 already offers a first option: use the browser’s preferences-reduced-motion parameter to, at the very least, disable animations for users who wish to do so. Failing the ability to disable automatic playback of animations, it would be necessary (to be compliant) to reduce their duration to less than 5 seconds (or even 4 seconds, if we comply with criterion 4.1 of the RGESN [FR] : https: //www.arcep.fr/mes-demarches-et-services/entreprises/fiches-pratiques/referentiel-general-ecoconception-services-numeriques.html#c36264 ) and/or propose a means of control to pause them. This point is still under discussion.

To take things a step further, version 1.08 seeks to reconcile ecodesign and accessibility. To this end, it has been decided to limit the duration of animations and, consequently, to trigger them only on scroll to ensure that they are still visible.

Results

The following results have been obtained from measurements taken over time:

First of all, it’s worth remembering that the impact on CPU, memory and battery discharge is highly dependent on the model of device used for the measurement, but can also vary between two devices of the same model. For this reason, each measurement also includes a reference step, not shown here. For web pages, this reference step consists in measuring what happens when the user is inactive on a Chrome tab displaying an entirely black page (minimal energy impact, especially compared with the empty Chrome tab, which is very bright and therefore more impactful when using a device with an OLED screen).

Measurements on such light sites are often more complicated, as deviations and overconsumption may be slight or even difficult to distinguish from measurement artifacts, for example. Sometimes, it’s possible to get around this by adapting the methodology. For example, to measure a very light component, we integrate it 100 or 1000 times on the page and proceed in the same way with other components we want to compare.

The increase in scroll time resulting from the continuous application of animations has led to a consequent lengthening of scroll time (17 seconds instead of 6), which directly increases energy and environmental impact.

For such lightweight sites, Chrome’s “parasitic” requests (telemetry, variant checking) appear all the more impactful, even if only a few or tens of Kb of data are transferred.

In our case, the best solution for limiting the impact of animation integration is version 1.0.8. This benefits from the implementation of the following best practices:

• Extensive SVG optimization (including compression and lazy-loading)
• Limiting the duration of animations, stopping them for users who choose to do so, and triggering them only on scroll.

Overall, in terms of the number of requests and transferred data, the gains are undeniable (even if the site was originally very light).

In terms of battery discharge speed, the gains are not negligible. Even if environmental impact and energy consumption appear to be the same overall, or even slightly higher (due to the increase in scroll time), the results are encouraging.

Conclusion

As already emphasized in the article on sober sites, estimating a site’s sobriety is a complex task, since it takes into account many factors as well as a specific methodology. Even on a site announced as sober, there are often improvements to be made (even if not all of them are worthwhile).

Once again, the subject of animations comes up. Sometimes used to compensate for the reduction in the number of images, they very often have an impact, even if free tools hide this impact (by concentrating on the data transfers carried out during page loading). When we want to go further to integrate them as efficiently as possible, the results to date are not necessarily conclusive. The priority should be frugality (getting rid of animations), then sobriety (reducing their number) and finally efficiency (optimizing their integration). However, for accessibility reasons in particular, their use should be prohibited (based on criterion 4.1 of the RGESN).

As for the efficient integration of animations, everything remains to be done. This is a very complex area to tackle, as the metrics to be taken into account are numerous and complex to measure and compare (CPU, GPU, battery discharge, etc.). Add to this the risks of impact transfers (opting for CSS rather than JS or vice versa) and you end up with a technical subject that is thorny, to say the least. However, here we note that limiting their duration, coupled with simple logic for triggering them, brings the best results.

Today’s standards and knowledge allow us to set out how to make an animation compliant from the point of view of accessibility. For ecodesign, however, this is not yet the case (even if the RGESN suggests a few insights). To my knowledge, there is no universal solution for proposing animations that do not lead to over-consumption.

So, from a very pragmatic point of view, it’s best to return to a simple but important approach: avoid integrating animations whenever possible, for reasons of accessibility as well as ecodesign (and more generally, user experience).  

Laurent DEVERNAY

Laurent Devernay Satyagraha has been an expert consultant at Greenspector since 2021. He is also a trainer, speaker and contributor to the W3C’s Web Sustainability Guidelines, INR’s GR491, greenit.fr’s 115 best practices and various working groups, notably around the RGESN.

ldevernay.github.io/

REEN law framework

The REEN law requires towns and cities with more than 50,000 inhabitants to define their Responsible Digital strategy by 2025. This necessarily includes elements linked to the eco-design of digital services. However, local authorities are often confronted with a first obstacle: the subject of eco-design of digital services is still relatively recent. As a result, it can be difficult to find one’s way around, whether it’s a question of choosing a measurement tool or a guide or repository that will enable effective progress to be made on the subject.

This is why another aspect of the REEN law is eagerly awaited by many: the definition of legal obligations for the eco-design of digital services. This should take the form of 2 items:

• The RGESN, which we’ll look at in more detail in this article.
•  An implementing decree that defines who is subject to these obligations, and with what constraints (what types of digital services, what deadlines for implementation, what deliverables are expected, etc.).

The reference to bind them all together: the RGESN

Its origins

In 2020, the INR (Institution du Numérique Responsable) is bringing together a hundred (!) experts to work on a reference framework for the eco-design of digital services. The aim: to offer recommendations covering all types of digital services, at all stages of the lifecycle and for everyone involved. In short, a holistic approach. It’s a colossal project, but it’s nearing completion in the summer of 2021. It will give rise to GR491, which currently comprises 61 recommendations and 516 criteria. It is due to be updated once again in the near future. To date, it represents a unique reference worldwide.

Just before the repository went online, DINUM (Direction interministérielle du numérique) intervened. Its objective was simple, and entirely relevant: to build on the work already done, and to create its own repository. This is how, in autumn 2021, two repositories came into being: GR491 and RGESN.

There have already been two versions of the RGESN: the first proposed by DINUM, then a new version put out to public consultation by ARCEP (Autorité de régulation des communications électroniques, des postes et de la distribution de la presse) at the end of 2023.

The final version is scheduled for release in early 2024, and may already have been released by the time you read this.

Its role

Existing versions of the RGESN referential already highlight its specific features. In the case of accessibility, the RGAA (Référentiel général d’amélioration de l’accessibilité) enables us to check the accessibility of a digital service, based on criteria derived from the WCAG (Web Content Accessibility Guidelines) issued by the W3C (World Wide Web Consortium). The French legal framework also requires compliance to be demonstrated by means of an accessibility declaration, as well as the publication of a multi-year plan for the digital accessibility of the entity. All these elements can be consulted here: https://accessibilite.numerique.gouv.fr/

In the case of the RGESN, the notion of ecodesign declaration is included directly in the standard, and its content is detailed throughout the criteria. However, this standard is not based on an international benchmark. Indeed, the WSGs (Web Sustainability Guidelines: Web Sustainability Guidelines (WSG) 1.0 [EN]) were published by the W3C after the RGESN. As a result, the WSG are partly based on the RGESN and not vice versa.

In the case of the RGESN, the ambition is not so much to “verify” that a digital service is eco-designed, as to check that an eco-design approach has indeed been implemented. This makes it possible to involve all stakeholders in the process (including the host and third-party service providers, as well as questioning the strategy and even the business model), and to adopt a continuous improvement approach. This approach is ambitious, but it is also linked to the fact that it is complicated, if not impossible, to establish factually (via purely technical criteria) whether a digital service is eco-designed or not. Rather, it’s a matter of ensuring that it is part of an eco-design approach.

Contents

V1 (the DINUM version)

In its first version, the RGESN proposes 79 recommendations divided into 8 families:

• Strategy
• Specifications  
• Architecture  
• UX/UI  
• Contents  
• Frontend  
• Backend  
• Hosting 

Each recommendation takes the following form:

• Objective
• Implementation 
• Means of testing or checking

So, for example, the first recommendation of the standard is entitled “1.1 Has the digital service been favorably evaluated in terms of utility, taking into account its environmental impacts?”

• Its “Objective” is to ensure that the digital service we are seeking to eco-design does indeed contribute to the Sustainable Development Goals (SDGs).
• To this end, the “Implementation” section suggests a few ways of checking this, as well as the elements to be specified in the ecodesign declaration.
• The “Means of testing or checking” section summarizes what to look for to ensure that this criterion is met.

Here we come to one of the limits of this version of the standard: the objective is laudable, but it lacks concrete means of verification and implementation.

Other points have been raised by experts in the field, but the tool remains important, and many are taking it up to test it in the field.

The standard defines a number of elements for structuring the eco-design approach, in particular by :

• Appointment of a referent
• Drawing up an ecodesign declaration (with full details of its content)
• Implementation of a measurement strategy. In particular, the definition of an environmental budget, aiming among other things at wider service compatibility in terms of browsers, operating systems, terminal types and connectivity.

The tools that accompany the repository (a browser extension, Excel spreadsheet templates as audit grids) are welcome, but sometimes insufficient in the field. This is particularly true when it comes to carrying out multiple audits on different digital services, or building a comprehensive action plan.

To take all this into account, here is the version of the RGESN proposed by ARCEP [PDF, 1.6 Mo].

V2 (ARCEP’s version)

This version was put out to public consultation two years after the first version.

It introduces a number of significant changes:

• The number of criteria has risen from 79 to 91, notably thanks to the addition of a “Learning” section (relating to machine learning) which introduces 5 new criteria.
• In addition to “Objective”, “Implementation” and “Means of test or control”, 3 new attributes appear:

• difficulty level
• priority level
• Non-applicability criteria

As a result of the addition of the priority level, the recommendations are first grouped by priority. 20 of them have been identified as priorities, in particular all those related to the new Learning section.

Beyond these contributions, the new version differs from the previous one in being more operational: it aims to provide concrete elements to facilitate the implementation of recommendations.

For example, we find the same 1.1 criterion presented in a more complete way:

• Action identified as a priority and easy to implement, no cases of non-applicability
• Objective more or less identical
• More contextual information to go further in the process of verifying the contributions of the digital service in terms of environmental (and societal) impacts.
• Concrete control tools: the Designers Éthiques questionnaire and the consequence tree as formalized by ADEME (Agence de l’Environnement et de la Maîtrise de l’Energie). This consequence tree is used again later, in Criteria 2.1, as part of design reviews.

The criterion relating to the ecodesign declaration has disappeared. The ecodesign declaration is nonetheless essential, and its content has been defined in various recommendations.

Another element emerging from this new version of the standard is the implementation of a measurement strategy via the definition of environmental indicators (at least primary energy, greenhouse gas emissions, blue water consumption and depletion of abiotic resources) as well as a strategy for their reduction and an environmental budget via thresholds. This measurement strategy should also include elements for verifying that the digital service functions correctly on older terminals and operating systems (or even older browsers), and in degraded connections. Through the changes made to recommendation 4.4, this measurement strategy should be extended to include user paths.

This is where Greenspector can help, both in strategy development and implementation. This includes not only the measurement itself, but also the definition of environmental indicators and their calculation, as well as the definition of routes, terminals and connection conditions. Today, this approach can be applied to websites, mobile applications and connected objects alike.

Some of the new criteria make the link with the RGPD (Réglement général sur la protection des données), the RGS (Référentiel général de sécurité), the IoT (Internet of Things) and open source. Recommendation 2.6 also requires that the environmental impact of software bricks such as AI and blockchain be taken into account. That said, this recommendation could have been placed directly in the Strategy section.

The Content section provides a wealth of information on content compression formats and methods, enabling us to go even further into the technical aspects of a sober editorial approach.

New criteria also provide information on blockchain, as well as on the asynchronous launch of complex processes.

This is clearly a step in the right direction. There’s no doubt that the public consultation will have yielded an enormous amount of input for an excellent repository, as well as the tools that must accompany it (by improving the browser extension, but above all the Excel template for conducting compliance audits and monitoring them over time via an action plan).

It is already clear from these additions and clarifications that carrying out an ESMR audit will take longer than with V1, which is important in order to take account of the criteria as a whole and thus remove any ambiguities as far as possible. While the intentions of RGESN V1 were already good, V2 provides the necessary elements to facilitate its adoption and implementation. This version also reflects a high degree of maturity on the subject, making it a resource that can already be read to facilitate skills upgrading.

What to expect next?

Already, the final version of the RGESN is expected (which is in itself a very positive sign).

It will undoubtedly be an essential tool for structuring eco-design initiatives for digital services. This will enable everyone’s practices to evolve in this area.

The accompanying tools are also eagerly awaited, as they should facilitate audits as well as compliance monitoring over time, notably through the definition of an action plan.

Among other things, the standard requires the publication of a complete ecodesign declaration, which not only raises awareness more widely, but also enables practices to be compared. In other words, to help this field of expertise evolve.

The big unknown remains the forthcoming application decree, which will set out the framework for the application of the REEN law, based on the RGESN. There are still several unknowns in this respect. Based on what is being done for accessibility (and in particular following the decree of October 2023), questions indeed remain unanswered:

• Will the use of RGESN be limited to the web or extended to other types of digital services (mobile applications, street furniture, etc.)? At the very least, it would be important to include mobile applications in addition to web sites and applications.
• What will the penalties be?
• How long will it take to implement?
• Which structures will be concerned? Public structures will be the first to be affected, but as with accessibility, it would be interesting to target businesses too. In fact, some of them have already begun to take up the subject, recognizing the value of this reference framework in guiding their eco-design initiatives for digital services.
• What means will be officially put in place to facilitate the adoption of the RGESN (training, guides, tools, etc.)?

Other, more general questions arise. In particular, how will certain companies and professionals evolve their practices and offers, perhaps for some of them by evolving towards auditor roles (or even by training future auditors). It is also to be hoped that a more complete definition of the eco-design of digital services will lead to the emergence of training courses leading to certification (i.e., skills repositories validated by France Compétences).

One point of concern remains the declarative nature of the recommendations. The advantage of the RGAA is that it offers a technical and even factual approach (even if certain criteria are sometimes open to interpretation). In the case of the RGESN, the criteria are less factual and less easy to verify, which can sometimes make them rely on the auditor’s objectivity. The question of defining methods for validating certain criteria through measurement also remains open.

It will also be interesting to see how all these elements will find an echo beyond France, and how the RGESN will fit in with the possible introduction of new standards and other reference frameworks.

Where does Greenspector fit into all this?

The RGESN is an unprecedented, but above all indispensable, basis for improving our own practices and providing our customers with the best possible support. All the more so as they will soon be obliged to use these standards.

To this end, a number of actions have been carried out:

• Integrate V1 of the RGESN into our own internal repository of best practices. As the time between V2 and the final version has been announced as being rather short, we have decided to wait for the final version before implementing the modifications. However, this does not prevent us from incorporating these changes into our day-to-day practices, and from taking V2’s contributions further.
• Incorporate the RGESN into the training courses we offer: present the standard and its context, and propose activities based on it, notably via the rapid and supervised implementation of an RGESN audit. Other standards are also presented for comparison purposes, as well as their use cases.
• We regularly carry out RGESN audits on behalf of our customers, and centralize information that enables us to track compliance rates and their evolution over time. What’s more, these audits enable us to develop our use of RGESN.
• We systematically rely on the RGESN during audits and design reviews. Our Ecobuild offer is also evolving. The original aim of this offer was to support a project team from the outset, through training, design reviews, audits, monitoring and, more broadly, expertise. We are now proposing to back up this offer with the RGESN, enabling us to go even further in setting up or consolidating our customers’ eco-design approach.
• In addition to the approach of using RGESN to audit/improve a site, we also use it as part of our support for a site creation solution, in order to have more global levers, but also to start thinking about the RGESN criteria that can be taken into account directly at this level. This type of reasoning could subsequently be extended to other tools such as WordPress, Drupal and other CMS. The interest here is manifold:
• Raising customer and user awareness on the subject of RGESN
• Reassure customers by taking responsibility for part of the criteria, which could ultimately have a differentiating effect (we can imagine customers opting for “RGESN-compliant” solutions to more easily meet their legal obligations on the subject).
• Provide the means for users/customers to create less impactful sites

Conclusion 

The RGESN has already established itself as an essential tool not only for the eco-design of digital services, but also for structuring eco-design approaches. As such, it should help everyone to develop their skills in this area. It remains to be seen how the legal framework will facilitate this evolution and, in time, bring about what we hope will be far-reaching changes in the structures concerned.

Laurent DEVERNAY

Laurent Devernay Satyagraha has been an expert consultant at Greenspector since 2021. He is also a trainer, speaker and contributor to the W3C’s Web Sustainability Guidelines, INR’s GR491, greenit.fr’s 115 best practices and various working groups, notably around the RGESN.

ldevernay.github.io/