L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2025 !
Réduire les émissions de carbone sur le Web —
Les sites Web, malheureusement, ne sont pas aussi respectueux de l'environnement que nous le souhaiterions. Cet article contient quelques réflexions et expériences en essayant de les nettoyer.
Comme c'est le cas avec de nombreux autres développeurs, les rapports des dernières années sur les énormes besoins énergétiques du Web m'ont incité à jeter un œil à mes propres sites Web et à voir ce que je peux faire pour minimiser leur impact. Cet article couvrira certaines de mes expériences dans ce domaine, ainsi que mes réflexions actuelles sur l'optimisation des sites Web pour les émissions de carboneet quelques exemples pratiques de choses que vous pouvez faire pour améliorer vos propres pages.
Mais tout d'abord, un aveu : lorsque j'ai entendu parler pour la première fois de l'impact environnemental des sites Web, je n'y croyais pas vraiment. Après tout, le numérique est censé être meilleur pour la planète, n'est-ce pas ?
Je suis impliqué dans divers groupes verts et environnementaux depuis des décennies. Pendant tout ce temps, je ne me souviens pas consciemment que quelqu'un ait jamais discuté des possibles impacts environnementaux du Web. L'accent a toujours été mis sur la réduction de la consommation et l'abandon de la combustion de combustibles fossiles. La seule fois où Internet a été mentionné, c'était comme un outil pour communiquer les uns avec les autres sans avoir besoin d'abattre plus d'arbres, ou pour travailler sans se déplacer.
Ainsi, lorsque les gens ont commencé à parler d'Internet similaire émissions de carbone à l'industrie du transport aérienj'étais un peu sceptique.
Émissions
Il peut être difficile de visualiser l'énorme réseau de matériel qui vous permet d'envoyer une demande de page à un serveur puis de recevoir une réponse en retour. La plupart d'entre nous ne vivons pas dans des centres de données et les câbles qui transportent les signaux d'un ordinateur à un autre sont souvent enfouis sous nos pieds. Lorsque vous ne pouvez pas voir un processus en action, le tout peut sembler un peu magique – quelque chose qui n'est pas aidé par l'insistance de certaines entreprises à ajouter des mots comme «cloud» et «serverless» à leurs noms de produits.
De ce fait, ma vision d'Internet a longtemps été un peu éphémère, une sorte de mirage. Cependant, lorsque j'ai commencé à écrire cet article, j'ai effectué une petite expérience de pensée : Combien de pièces matérielles un signal traverse-t-il depuis l'ordinateur sur lequel j'écris pour sortir de la maison ?
La réponse a été assez choquante : 3 câbles cat, un commutateur, 2 adaptateurs CPL, un routeur et un modem, un câble RJ11 et plusieurs mètres de câblage électrique. Soudain, ce mirage commençait à paraître un peu plus solide.
Bien sûr, le Web (tous, par extension, les sites Web que nous créons) a une empreinte carbone. Tous les serveurs, routeurs, commutateurs, modems, répéteurs, armoires téléphoniques, convertisseurs optique-électrique et liaisons montantes par satellite d'Internet doivent être construits à partir de métaux extraits de la Terre et de plastiques raffinés à partir de pétrole brut. Pour fournir ensuite des données aux 20 milliards d'appareils connectés estimés dans le monde, ils doivent consommer de l'électricité, qui libère également du carbone lorsqu'elle est générée (même l'électricité renouvelable n'est pas neutre en carbone, bien qu'elle soit bien meilleure que l'électricité fossile). carburants).
Il est probablement impossible de mesurer avec précision ce que sont ces émissions – chaque appareil est différent et l'énergie qui les alimente peut varier au cours d'une journée – mais nous pouvons avoir une idée approximative en en regardant les chiffres typiques de la consommation d'énergie, les bases d'utilisateurs, etc. Un outil qui utilise ces données pour estimer les émissions de carbone d'une seule page est le Website Carbon Calculator. Selon lui, la page moyenne testée « produit 1,76 gramme de CO2 par page vue ».
Si vous avez l'habitude de penser que le travail que vous faites est essentiellement inoffensif pour l'environnement, cette prise de conscience peut être assez décourageante. La bonne nouvelle est qu'en tant que développeurs, nous pouvons faire beaucoup à ce sujet.
Lecture recommandée : Comment améliorer les performances du site Web peut aider à sauver la planète
Plus après le saut ! Continuez à lire ci-dessous ↓
Performance And Emissions
Si nous nous souvenons que la visualisation de sites Web utilise de l'électricité et que la production d'électricité libère du carbone, alors nous saurons que les émissions d'une page doivent fortement dépendre de la quantité de travail que le serveur et le client doivent effectuer pour afficher la page. En outre, la quantité de données requise pour la page et la complexité de l'itinéraire qu'elle doit parcourir détermineront la quantité de carbone libérée par le réseau lui-même.
Par exemple, le téléchargement et le rendu exemple. com consommera probablement beaucoup moins d'électricité que la page d'accueil d'Appleet ce sera également beaucoup plus rapide. En effet, ce que nous disons, c'est que des émissions élevées et des chargements de pages lents ne sont que deux symptômes des mêmes causes sous-jacentes.
C'est très bien de parler de cette relation en théorie, bien sûr, mais avoir des données réelles. le sauvegarder serait bien. Pour ce faire, j'ai décidé de mener une petite étude. J'ai écrit un programme d'interface de ligne de commande simple pour dresser une liste des 500 sites Web les plus populaires sur Internet, selon MOZ et vérifier leurs pages d'accueil par rapport à PageSpeed Insights de Google et au Website Carbon Calculator.[19659003]Certaines vérifications ont expiré (souvent parce que la page en question prenait simplement trop de temps à charger), mais au total, j'ai réussi à collecter des résultats pour plus de 400 pages le 14 juillet 2021. Vous pouvez télécharger le résumé de résultats pour vous examiner mais pour fournir une indication visuelle, je les ai tracés dans le graphique ci-dessous :
![Graphique montrant une tendance de près de 6 grammes de carbone à 0 PageSpeed, tombant à 1 gramme de carbone à 100 PageSpeed.[19659026] Carbone contre PageSpeed de 400 sites Web populaires. (<a href=](https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/92553f73-8a45-4830-b666-e74671313616/1-reducing-carbon-emissions-on-web.jpeg)
Grand aperçu
Comme vous pouvez le voir, alors que la variation entre les sites Web individuels est très élevée, il existe une forte tendance à la baisse des émissions des pages plus rapides. Les émissions moyennes moyennes pour les sites Web avec un score PageSpeed de 100 sont d'environ 1 gramme de carbone, ce qui s'élève à près de 6 grammes projetés pour les sites Web avec un score de 0. les vitesses et les émissions élevées, la plupart des résultats sont regroupés en bas à droite du graphique.
Passer à l'action
Une fois que nous comprenons qu'une grande partie des émissions d'une page proviennent de mauvaises performances, nous pouvons commencer à prendre des mesures pour les réduire. Bon nombre des éléments qui contribuent aux émissions d'un site Web échappent à notre contrôle en tant que développeurs. Nous ne pouvons pas, par exemple, choisir les appareils à partir desquels nos utilisateurs accèdent à nos pages ou décider de l'infrastructure réseau à travers laquelle leurs demandes transitent, mais nous pouvons prendre des mesures pour améliorer les performances de nos sites Web.
L'optimisation des performances est un vaste domaine. sujet, et beaucoup d'entre vous qui lisez ceci ont probablement plus d'expérience que moi, mais j'aimerais mentionner brièvement quelques choses que j'ai observées récemment lors de l'optimisation de la vitesse de chargement et des émissions de carbone de diverses pages. [19659031]Le rendu est beaucoup plus lent sur mobile
J'ai récemment retravaillé le design de mon blog personnel afin de le rendre un peu plus convivial. L'un de mes passe-temps est la photographie, et le site Web comportait auparavant une image d'en-tête pleine hauteur.
Bien que la conception ait fait un bon travail pour mettre en valeur mes photographies, il était très difficile de faire défiler, en particulier lors du déplacement dans les pages des articles de blog. Cependant, je ne voulais pas perdre l'impression d'avoir une photo dans l'en-tête et j'ai finalement décidé de l'utiliser comme arrière-plan pour le titre de la page.
L'en-tête pleine hauteur utilisait srcset afin de rendre le chargement aussi rapide que possible, mais les images étaient toujours très grandes sur les écrans haute résolution et mon plus long temps de peinture à contenu (LCP) sur mobile pour l'ancien design était de près de 3 secondes. Un gros avantage de la nouvelle conception était qu'elle me permettait de rendre les images beaucoup plus petites, ce qui réduisait le temps LCP à environ 1,5 seconde.
Sur les ordinateurs portables et les ordinateurs de bureau, les gens n'auraient pas remarqué de différence, car les deux versions étaient bien moins d'une seconde, mais sur des appareils mobiles beaucoup moins puissants, c'était assez dramatique. Quel a été l'effet de ce changement sur les émissions de carbone? 0,31 gramme par vue avant, 0,05 gramme après. Le décodage et le rendu des images sont très gourmands en ressourceset cela augmente de façon exponentielle à mesure que les images grossissent.
La taille des images n'est pas la seule chose qui peut avoir un impact sur le temps de décodage ; le format est également important. Le phare de Google recommande souvent de diffuser des images dans des formats de nouvelle génération pour réduire la quantité de données à télécharger, mais les nouveaux formats sont souvent plus lents à décoderen particulier sur mobile. L'envoi de moins de données sur le fil est meilleur pour l'environnement, mais il est possible que consommer plus d'énergie pour décoder puisse compenser cet avantage. Comme pour la plupart des choses, les tests sont essentiels ici.
D'après mes propres tests en essayant d'ajouter la prise en charge de l'encodage AVIF au générateur de site statique Zola, j'ai trouvé qu'AVIF, qui promet des tailles de fichiers beaucoup plus petites que JPG au même qualité prenait des ordres de grandeur plus longs à coder ; quelque chose que l'observation de bunny.net selon laquelle WebP surpasse AVIF jusqu'à 100 fois prend en charge. Ce faisant, le serveur consommera de l'électricité et je me demande si, pour les sites Web à faible nombre de visiteurs, le passage au nouveau format pourrait en fait augmenter les émissions et réduire les performances.
Les images, bien sûr, ne sont pas les meilleures. seul composant des pages Web modernes qui prennent beaucoup de temps à traiter. Les petits fichiers JavaScript, selon ce qu'ils font, peuvent prendre beaucoup de temps à s'exécuter et les mêmes pièges potentiels que les images s'appliqueront.
Lecture recommandée : The Humble img Éléments et éléments essentiels du Web
Les allers-retours s'additionnent
Une autre chose qui peut avoir un impact surprenant sur les performances et les émissions est la provenance de vos données. La sagesse conventionnelle dit depuis longtemps que servir des actifs tels que des frameworks à partir d'un réseau de diffusion de contenu (CDN) central améliorera les performances, car l'obtention de données à partir de nœuds locaux est généralement plus rapide pour les utilisateurs qu'à partir d'un serveur central. jQuery, par exemple, a la possibilité d'être chargé à partir d'un CDN, et ses responsables disent que cela peut améliorer les performances, mais les tests en conditions réelles par Harry Roberts ont montré que les ressources d'auto-hébergement sont généralement plus rapides .
C'est aussi mon expérience. J'ai récemment aidé un site Web de jeux à améliorer ses performances. Le site Web utilisait un framework CSS assez volumineux et chargeait tous ses actifs tiers via un CDN. Nous sommes passés à l'auto-hébergement de tous les actifs et avons supprimé les composants inutilisés du framework.
Aucune des optimisations n'a entraîné de modifications visuelles du site Web, mais ensemble, elles ont augmenté le score Lighthouse de 72 à 98 et a réduit les émissions de carbone de 0,26 gramme par vue à 0,15.
Envoyez uniquement ce dont vous avez besoin
Cela mène bien au sujet de l'envoi aux utilisateurs uniquement des données dont ils ont réellement besoin. J'ai travaillé sur (et visité) de très nombreux sites Web dominés par des images de stock de personnes en costume souriant les unes aux autres. Il semble y avoir une mentalité au sein de certaines organisations selon laquelle ce qu'elles font est vraiment ennuyeux et que l'ajout de photos convaincra le grand public du contraire. ]le temps que les gens passent à lire diminue. Le texte, nous dit-on à maintes reprises, se démode ; tout ce qui intéresse désormais les gens, ce sont les vidéos et les expériences interactives.
De ce point de vue, les photos d'archives pourraient être considérées comme un outil utile pour animer les pages, mais des études de suivi oculaire montrent que les gens ignorent les images qui ne sont pas 'pas pertinent . Lorsque les gens ne regardent pas vos images, les images peuvent tout aussi bien être des espaces vides. Et quand chaque octet coûte de l'argent, contribue au changement climatique et ralentit les temps de chargement, ce serait mieux pour tout le monde s'ils l'étaient réellement.
Encore une fois, ce qui peut être dit pour les images peut être dit pour tout le reste qui ne l'est pas. le contenu principal de la page. Si quelque chose ne contribue pas de manière significative à l'expérience d'un utilisateur, il ne devrait pas être là. Je ne préconise pas un instant que nous commencions tous à servir des pages sans style – certaines personnes, comme celles qui souffrent de dyslexie, trouvent les gros blocs de texte difficiles à lire, et d'autres utilisateurs trouveraient presque certainement de telles pages ennuyeuses et iront ailleurs – mais nous devrions examiner de manière critique chaque partie de nos sites Web pour déterminer s'ils gagnent leur vie.
Accessibilité et environnement
Un autre domaine où les performances et les émissions convergent est celui de l'accessibilité. Il existe une idée fausse commune selon laquelle rendre les sites Web accessibles implique d'ajouter des attributs aria à une page, mais souvent ce que vous omettez est plus important que ce que vous y mettez, ce qui rend un site Web accessible relativement léger et performant.[19659056]Utilisation d'éléments standard
MDN Web Docs propose de très bons tutoriels sur l'accessibilité. Dans "HTML : Une bonne base pour l'accessibilité", ils expliquent comment la meilleure base d'un site Web accessible réside dans l'utilisation des éléments HTML corrects pour le contenu. L'une des sections les plus intéressantes de l'article est celle où ils essaient de recréer la fonctionnalité d'un élément button à l'aide d'un div et d'un JavaScript personnalisé.
C'est évidemment un exemple minimal, mais j'ai pensé qu'il serait intéressant de comparer la taille de cette version de bouton à celle utilisant des éléments HTML standard. L'exemple de faux bouton dans ce cas pèse environ 1 403 octets non compressé, alors qu'un véritable bouton avec moins de JavaScript et sans style pèse 746 octets. Le bouton div sera également dénué de sens sémantiquement et, par conséquent, beaucoup plus difficile à utiliser pour les utilisateurs de lecteurs d'écran et pour les robots à analyser.
Lecture recommandée : SVG accessibles. : Modèles parfaits pour les utilisateurs de lecteurs d'écran
Lorsqu'ils sont mis à l'échelle, ce genre de choses fait la différence. L'analyse du balisage minimal et de JavaScript est plus facile pour un navigateur, tout comme pour les développeurs. suppression des attributs de titre redondants et remplacement des divs par des équivalents plus sémantiques. La page d'origine avait une structure semblable à la suivante (contenu supprimé par souci de confidentialité et de concision) :
En-tête de la pièce de contenu
Certains éléments ;
Article 1
Article 2
Article 3
Avec le contenu complet, cela pesait 34 168 octets.
Après refactorisation, la structure ressemblait à ceci :
En-tête de la pièce de contenu
Certains éléments ;
- Élément 1
- Élément 2[19659070]Item 3
Il pesait 32 805 octets.
Les modifications sont actuellement en cours, mais le balisage est déjà beaucoup plus accessible selon WebAIM, Lighthouse et les tests manuels. La taille du fichier a également diminué et, en faisant la moyenne du temps de cinq profils dans Chrome, le temps d'analyse du code HTML a diminué d'environ 2 millisecondes.
Ce sont évidemment de petits changements et ne feront probablement aucune différence perceptuelle. aux utilisateurs. Cependant, il est bon de savoir que chaque octet coûte aux utilisateurs et à l'environnement — rendre un site Web accessible peut également le rendre un peu plus léger.
Vidéos
La version HTML du projet Gutenberg de [19659077] L'œuvre complète de William Shakespeare fait environ 7,4 Mo non compressés. Selon Android Authority dans "Combien de données YouTube utilise-t-il réellement ?", une vidéo YouTube 360p pèse environ 5 à 7,5 Mo par minute de séquence et 1080p environ 50 à 68. Donc, pour la même quantité de bande passante comme toutes les pièces de Shakespeare, vous n'obtiendrez qu'environ 7 secondes de vidéo haute définition. L'encodage et le décodage de la vidéo sont également très intensifs, et c'est probablement l'un des principaux facteurs qui expliquent que les estimations des émissions de carbone de Netflix atteignent 3,2 KG par heure.
La plupart des vidéos reposent à la fois sur des éléments visuels et auditifs. composants pour communiquer leur message, et les fichiers volumineux nécessitent un certain niveau de connectivité. Cela impose évidemment des limites à qui peut bénéficier d'un tel contenu. Rendre la vidéo accessible est possible mais loin d'être simple, et de nombreux sites Web ne s'en soucient tout simplement pas.
Si la vidéo n'était jamais traitée que comme une forme d'amélioration progressive, ce ne serait peut-être pas un problème, mais J'ai perdu le compte du nombre de fois où j'ai recherché quelque chose sur le Web, et la seule façon de trouver l'information que je voulais était de regarder une vidéo. Sur YouTube, le nombre moyen d'utilisateurs mensuels est passé de 20 millions en 2006 à 2 milliards en 2020. Vimeo dispose également d'une base d'utilisateurs en constante augmentation.
Malgré le grand nombre d'utilisateurs visiteurs de sites Web de partage de vidéos, dont bon nombre des plus populaires ne semblent pas entièrement conformes à la législation sur l'accessibilité . Contrairement à cela, de nombreux types de technologies d'assistance sont conçus pour rendre le texte brut accessible au plus grand nombre de personnes possible. Le texte est également facile à convertir d'un format à un autre, il peut donc être utilisé dans un certain nombre de contextes différents. empreinte carbone bien inférieure à celle de toute autre forme d'information conviviale transmise sur le Web.
La vidéo peut être géniale, et de nombreuses personnes apprennent mieux en regardant un processus en action, mais elle laisse également certaines personnes de côté et a un coût environnemental . Pour que nos sites Web soient aussi légers et inclusifs que possible, nous devons traiter le texte comme la principale forme de communication dans la mesure du possible et proposer des éléments tels que l'audio et la vidéo en plus.
Lecture recommandée : [19659085]Optimisation de la vidéo pour la taille et la qualité
En conclusion
J'espère que ce bref aperçu de mon expérience en essayant d'améliorer les sites Web pour l'environnement vous a donné quelques idées de choses à essayer sur vos propres sites Web. Il peut être assez décourageant de parcourir une page du Calculateur de carbone du site Web et de se faire dire qu'il pourrait émettre des centaines de kilogrammes de CO2 par an. Heureusement, la taille même du Web peut amplifier des changements positifs aussi bien que négatifs, et même de petites améliorations s'ajoutent rapidement sur les sites Web avec des milliers de visiteurs par semaine.
Même si nous voyons des choses comme un site Web de 25 ans dont la taille a été multipliée par 39 après une refonte, nous voyons également des sites Web conçus pour utiliser le moins de données possible et des gens intelligents découvrent comment pour livrer WordPress en 7 Ko. Ainsi, pour que nous puissions réduire les émissions de carbone de nos sites Web, nous devons les rendre plus rapides – et cela profite à tout le monde.
Autres lectures
(vf, yk, il, al)Source link