Comment sauver le climat en tant que développeur web ?
Les émissions de CO2 directement provoquées par l’informatique augmentent de plus en plus rapidement. D’ici 2025, elles devraient être supérieures aux émissions des transports. Le numérique peut sembler immatériel, mais repose pourtant sur des infrastructures bien réelles. Par exemple, le cloud n’est pas une technologie magique, mais simplement l’ordinateur de quelqu’un d’autre. En tant que développeur web, il est possible d’agir sur ces problèmes.
La première idée reçue sur l’informatique est que la pollution vient des centres de données et des GAFAM, nous laissant impuissants. Mais si on considère un service numérique comme ayant trois composantes principales (centres de données, réseaux et terminaux), la première source de pollution est en fait de loin celle des terminaux ! Les émissions de gaz à effets de serre générées par ceux-ci représentent environ 2/3 des émissions du numérique. Et c’est principalement à cause de leur fabrication, pas de leur utilisation.
Pour les fabriquer, il faut des métaux et des minéraux. Leur extraction est très gourmande en ressources et émet beaucoup de gaz à effets de serre. Ils viennent de partout dans le monde, et doivent voyager sur de longues distances pour être combinés en composants électroniques, assemblés pour fabriquer des appareils, et finalement vendus. Ce problème est également lié à des risques géopolitiques (par exemple avec la Chine), aux droits de l’homme (des enfants meurent pour miner du cobalt au Congo) et à la dégradation de l’environnement (des régions entières du Chili sont polluées).
Afin de réduire le nombre de terminaux fabriqués (et leur pollution associée), il faut examiner les raisons pour lesquelles les utilisateurs changent leurs équipements numériques.
Les utilisateurs changent leurs terminaux principalement à cause d’une batterie défectueuse ou d’un logiciel lent. Et c’est beaucoup plus un problème logiciel que matériel. En tant que développeurs, nous avons un grand biais : nous codons sur les machines les plus récentes et les plus puissantes. Même si nous travaillons sur la compatibilité (ce qui n’est pas toujours le cas…), nous créons du code inefficace lorsqu’il n’est pas exécuté sur les derniers appareils. Ces sites web lents et consommateurs de batterie poussent les utilisateurs à changer de plus en plus leurs appareils, ce qui entraîne la pollution décrite ci-dessus.
Alors, que pouvons-nous faire en tant que développeurs web?
1 - Coder moins de fonctionnalités
La première chose (peut-être la plus difficile) à faire sur un produit numérique est d’en limiter le nombre de fonctionnalités. L’optimisation des fonctionnalités existantes peut être longue et complexe, alors il ne faut tout simplement pas les créer. Plus de 70% des fonctionnalités d’un site Web ne sont pas utilisées. Il faut donc veiller à ne pas faire de fonctionnalités juste pour satisfaire un collègue, et s’assurer que l’utilisateur final en a vraiment besoin.
2 - Réduire le nombre de publicités et de trackers
Une grande partie de l’impact d’un site vient des publicités et des trackers. Certains évoquent même jusqu’à 70% de l’empreinte d’un site venant de ces éléments. Tout comme la suppression de fonctionnalités, cela peut être très difficile à réaliser, mais pourrait bien être un important levier de réduction d’impact. Sur un site web, les requêtes réseau et l’affichage de contenu sont les deux opérations les plus coûteuses à exécuter. Et c’est exactement ce que font les publicités et les trackers. Ne pas avoir de publicités ou de trackers est compliqué, mais réduire leur nombre est possible. Pour aller plus loin sur le tracking, voilà un article sur le sujet.
3 - Compresser les assets
La plupart des applications manipulent des assets comme des images, des polices d’écriture ou des svgs. Un “quick-win” consiste simplement à les compresser.
- Pour les images, les formats webp et avif limitent la taille d’une image, mais attention à la compatibilité : gagner des performances pour les navigateurs modernes ne doit pas se faire au détriment des plus anciens. Il faut donc prévoir un fallback en jpeg. TinyPNG est un service simple pour compresser les images sans perdre beaucoup de qualité. Pour aller plus loin, Squoosh propose plus d’options à modifier.
- Pour les polices, la plupart du temps, on peut supprimer des caractères inutiles avec un outil comme Glyphr. Il faut aussi penser à limiter le nombre de polices téléchargées au minimum, une seule si possible. Encore mieux, on peut utiliser une police qui est déjà dans le système d’exploitation de l’utilisateur.
- Les SVG peuvent également être optimisés, par exemple avec SVGOMG.
Enfin, à la génération de documents (pdf, docx, csv ou autre) pour les utilisateurs, on peut les compresser à la volée.
4 - Supprimer les embeds de réseaux sociaux
Ce point est très proche du deuxième parce que les embeds de réseaux sociaux sont pleins de trackers. En intégrant un tweet ou un post Instagram, on n’ajoute pas seulement du HTML et du CSS, mais on fait aussi télécharger à l’utilisateur final des scripts de réseaux sociaux. C’est mauvais pour la vie privée et la performance. L’alternative la plus simple serait un lien, mais on peut également recréer un composant qui affiche le contenu des réseaux sociaux.
5 - Avoir plus de pages statiques
En tant que développeurs web, nous utilisons parfois des solutions exagérément compliquées, avec l’utilisation de beaucoup de Javascript.
Nos navigateurs sont très performants pour interpréter du HTML et du CSS, mais l’ajout de JavaScript a un coût élevé. Il doit être téléchargé, parcouru et exécuté, et peut parfois modifier le DOM, entraînant des repaints, mauvais pour la performance. Dans certains cas, un simple site statique est la meilleure solution. Hugo.io est un exemple d’outil pour y parvenir.
6 - Ajouter du cache
La mise en cache est un sujet très compliqué, mais si elle est pertinente, elle est à utiliser autant que possible. Il peut s’agir de cache de base de données (par exemple avec Redis), de cache serveur (par exemple avec Nginx) ou même de cache en frontend. Par exemple, pour des requêtes GraphQL, Apollo permet d’utiliser du cache. En React, useCallback et useMemo permettent aussi une forme de cache. L’objectif est d’utiliser moins de CPU et de faire moins de requêtes. Pour aller plus loin sur le caching, voilà un article sur le sujet.
7 - Penser au lazy-loading
Lorsqu’on arrive sur une page web, on a juste besoin de charger le contenu visible du haut de la page. Et même ce contenu peut être lazy-loadé, s’il contient des images par exemple. La façon la plus simple de lazy-loader une image est l’attribut « loading » :
<img src="image.webp" loading="lazy" alt="…" width="200" height="200">
Une autre façon de le faire est d’utiliser l’API Intersection Observer, supportée par tous les navigateurs modernes. Par exemple, on peut l’utiliser pour déclencher une requête liée au contenu affiché en bas de page. De cette façon, on réduit le nombre de requêtes au chargement initial et on charge uniquement les données nécessaires.
8 - Utiliser moins de paquets
Il faut penser à utiliser moins de bibliothèques JavaScript, et des bibliothèques plus légères. On peut vérifier leur taille sur Bundle Phobia. Sur ce site, il faut observer deux indicateurs : le temps de chargement en “Emerging 3G” (s’il est supérieur à 400-500 ms, c’est probablement déjà trop), et le “tree-shaking”. Cette option, si disponible, peut considérablement réduire la taille d’une bibliothèque en important uniquement le code nécessaire.
9 - Travailler la rétrocompatibilité
C’est probablement la partie la moins sympathique de cet article 😅. Et pourtant c’est peut-être l’une des plus importantes. Le travail sur la rétrocompatibilité est un levier important pour éviter le renouvellement des terminaux utilisateur. Sur un service largement utilisé, exclure même un petit pourcentage d’utilisateurs peut représenter beaucoup de monde.
Il faut s’assurer qu’un site web fonctionne sur les navigateurs plus anciens et faire attention à ne pas utiliser du HTML, du CSS ou du JavaScript qui ne soit pas pris en charge par les anciens navigateurs. CanIUse donne beaucoup d’informations sur la compatibilité navigateur.
Aussi, on peut utiliser des polyfills pour une compatibilité « simple », par exemple avec Polyfill.io.
10 - Mesurer la performance et ajouter des mesures « vertes »
Pendant et après avoir appliqué les conseils ci-dessus, on peut mesurer. De nombreux outils existent, mais il faut les utiliser avec un regard critique. Tous les chiffres donnés sont approximatifs, et peut-être même faux. Par exemple, le populaire GreenIT Analysis donne un « score EcoIndex », une estimation du CO2 et de l’eau de votre site Web, mais ces chiffres ne sont pas très précis. C’est une bonne première étape de sensibilisation, mais pas un véritable outil de mesure. Avec cette extension, il vaut mieux se concentrer sur les conseils donnés par l’analyse.
Pour les mesures frontend, Google Lighthouse est un très bon outil qui donne métriques et conseils précis d’amélioration. Combiné avec GreenIT Analysis, on peut consolider ses résultats. On peut même ajouter Lighthouse CI à ses pipelines afin d’éviter les régressions et définir des seuils de performance acceptables. PAGIEL et Fruggr sont également des solutions intéressantes.
Pour le backend, Scaphandre permet de mesurer la consommation électrique d’un serveur et peut aussi être intégré dans une CI pour surveiller les régressions.
Côté infrastructure, il existe des calculateurs carbone AWS, GCP et Azure. Ils déduisent les émissions CO2 d’une infrastructure mais il faut rester prudent : au moment où j’écris ces lignes, aucune méthode de calcul normalisée n’est utilisée, et le résultat n’est pas basé sur tous les services utilisés. Cloud Carbon Footprint est une alternative qui utilise la même méthode pour tous les fournisseurs cloud.
Il faut donc garder à l’esprit qu’un seul indicateur n’est pas une mesure fiable : il faut les combiner depuis différentes sources afin d’obtenir le résultat le plus solide possible. Pour aller plus loin sur les mesures, voilà un article sur le sujet.
Conclusion
Pour tout résumer en quelques mots : sobriété avant optimisation. L’optimisation sans sobriété peut mener au paradoxe de Jevons : ce qui est gagné avec les améliorations de performance est annulé par l’augmentation de l’utilisation. La fonctionnalité la plus facile à optimiser est celle qu’on ne code pas. Vous avez tous les outils, maintenant c’est à vous. Gardez l’essentiel, mesurez et optimisez.
Sources
Les 115 bonnes pratiques d'éco-conception web
Comment sauver la planète en ne faisant rien
Quels outils pour mesurer la consommation énergétique de vos applications ?
Everything that's inside your iPhone
Everything You Need to Know About Green IT