Web hors-ligne : Des métriques positives pour l’utilisateur comme pour la planète

Disclaimer :
Cet article est le cinquième de la série d’articles sur le web hors-ligne et les services workers. Sommaire :
Web hors-ligne : l'alliance entre l'optimisation utilisateur et les pratiques éco-responsables
Web hors ligne : Précacher votre application pour un usage hors ligne dégradé avec des fallback
Web hors-ligne : Stratégies de cache du plus green au plus simple, entre offline first et online first
Web hors-ligne : Stale While Revalidate ou le meilleur de l’UX pour le pire de l’écoresponsabilité

Introduction : Les responsabilités environnementales et l’efficacité des service workers mises en lumière

Dans un monde où l'empreinte écologique de la technologie numérique devient de plus en plus préoccupante, l'évaluation des performances des technologies que nous utilisons est importante. Évaluer les services workers sous un prisme éco responsable est donc essentiel. De ces agents dépend une grande partie de l'expérience utilisateur moderne, permettant aux applications web de fonctionner de manière fluide même sans connexion Internet. Toutefois, leur performance et leur impact écologique ne sont pas uniquement jugés par les fonctionnalités qu'ils fournissent, mais également par la manière dont ils consomment les ressources du système. Jetons un œil approfondi à deux aspects cruciaux : les métriques de performance et les principes d'écoconception.

Efficacité et Rapidité : Les Metrics de Performance des Service Workers

Vitesse et Réactivité comme Priorité

Les services workers, agissent comme des intermédiaires entre le réseau et l'utilisateur, offrant ainsi des gains de performance significatifs. L'un des indicateurs clés ici est le temps de réponse. Une étude de Vrije Universiteit Amsterdam, réalisée sur 9 PWA différentes, démontre que l'utilisation d'un service worker peut réduire le temps de chargement initial d'une application web. Ce gain est crucial pour les entreprises, car chaque milliseconde économisée contribue à une meilleure rétention des utilisateurs et à l'amélioration de leur expérience.

Ensuite, la réactivité joue un rôle fondamental. Les serveurs sont souvent sollicités, mais avec un bon service worker en place, les requêtes peuvent être satisfaites directement à partir du cache. Ce mécanisme non seulement diminue la charge serveur mais optimise aussi l'utilisation de la bande passante, une ressource qui, rappelons-le, n'est pas infinie et que chaque économie contribue à la durabilité.

Mémoire et Utilisation des Ressources

Outre la vitesse, la manière dont les service workers utilisent la mémoire et les ressources du système mérite attention. En effet, l’optimisation de l'utilisation du cache peut réduire l'empreinte mémoire grâce à une gestion fine du cache, efficace dans le stockage et la récupération des ressources fréquemment demandées.

On pourrait être tenté de penser qu’une application web avec un service worker bien conçu consomme moins d’énergie. Cette étude démontre qu’en réalité, il n’y a pas de réelle différence entre l’énergie consommée par une application classique et celle consommée par une PWA.

Écoconception : Vers une Technologie Durable

Principes Fondamentaux de l’Écoconception

Lorsque l'on parle d'écoconception, il est impératif de penser à des solutions durables qui minimisent l'impact environnemental tout en maximisant l'efficacité. Les services workers, au centre des flux de données, peuvent être conçus pour réduire le gaspillage numérique. Par exemple, en optimisant la fréquence et la quantité de données mises en cache, on peut éviter une surcharge inutile des réseaux de distribution de contenu (CDN) ou des API REST, ce qui réduit considérablement l'empreinte carbone associée.

L'usage de techniques de compression des données avant leur mise en cache est une autre pratique vertueuse qui permet d’abaisser la consommation de bande passante, allégeant ainsi la charge environnementale.

Approche Intégrée

Pour adopter l'écoconception, une approche intégrée est essentielle. Une approche intégrée est une manière d’analyser un projet sous toutes ses facettes afin de le concevoir en une réponse complète à un besoin : dans notre cas, une application se doit d’allier utilité, performance, efficacité et faible consommation d’énergie/ressources pour le bien-être de la planète.

Cette approche implique donc la collaboration entre concepteurs, développeurs et ingénieurs pour repenser les processus de conception des services workers. Cette collaboration permettrait d’améliorer l'efficacité des services numériques afin d’augmenter chaque année le potentiel de réduction du coût énergétique ainsi que des émissions de CO2. En effet, transmettre une donnée, ne serait-ce même qu’une fois, a le même coût énergétique que si elle était stockée pendant une année. Ça amène à réfléchir, non ?

Conclusion : Une réflexion pour l'avenir

En conclusion, les services workers représentent une opportunité majeure d'amélioration de la performance des applications web tout en ajoutant une responsabilité environnementale. Leur rôle ne se limite pas à l'optimisation de l'expérience utilisateur, mais s'étend à la réduction de la consommation des ressources et à la promotion d'une conception plus durable. Alors que l'impact écologique des technologies numériques est de plus en plus scruté par les institutions et le public, un engagement ferme en faveur de l'écoconception dans le domaine des services workers mènera à une technologie résiliente et durable, bénéfique pour tous.

Pour améliorer l’expérience utilisateur tout en impactant positivement notre impact numérique, les services workers sont une solution envisageable, mais d’autres approches liées au web hors-ligne (cache, utilisation de la mémoire locale…) répondent à la même problématique. Ces approches sont bien connues depuis des années sur le mobile pour la création d’applications hors-ligne.

Bonus : des métriques calculables pour aller plus loin

Comme vous l’avez compris, toutes les requêtes réseau passent par les services worker, que celles-ci soient cachées ou non. À partir de ce fait, nous avons fait un constat : il est donc possible de calculer sur chaque machine la taille des ressources récupérées en ligne pour chaque ressource, mais aussi calculer avec le nombre d’appel et le poid des ressources la quantité de données économisée grâce au cache ainsi que les quantités que nous pourrions économiser sur chaque ressource si nous la mettions en cache.

Pour cela pour chaque appel il suffit de récupérer la taille de la ressource dans le header (ou de la calculer si le header n’est pas disponible). Une fois cette taille enregistrée, il suffit dans un deuxième “faux cache” (pour rappel le local storage n’est pas accessible au service worker) d’aller récupérer la taille des données en cache pour la ressource, de l’additionner puis de la réenregistrer. Il suffit ensuite régulièrement d’envoyer les données de ce cache et de le remettre à zéro (via un message du serveur par exemple ou à une certaine heure) vers un serveur de tracking. En mettant cette solution en place, vous pouvez calculer exactement les données économisées par vos worker et quelles routes prioriser dans vos prochains cache avec de vraies données utilisateur. En pensant plus loin qu’un simple cache vos service worker, vous pouvez les voir comme un vrai enabler de votre stratégie green dans le front.

En attendant de développer une solution clef en main vous pouvez trouver un poc minimaliste de cette idée sur notre github avec des console.log : https://github.com/LiquidITGuy/demo-workbox-octo/blob/main/public/sw.js