Zeste de Savoir est écolo !

Je viens de découvrir un nouvel outils, et il indique que Zds est écolo !

Lien intéressant : Comment penser à l’écologie dans le domaine du web !

Ah zut, je me suis laissé berné ?

Edit : Mais alors, sur quoi ce base cet outil à votre avis ? Il ne doit pas mettre des chiffres au hasard quand même.

https://www.websitecarbon.com/how-does-it-work/

When a website is loaded, the energy used is roughly proportional to the amount of data transferred.

En gros, ils le disent eux même, c’est très très approximatif.

Bon, c’est très approximatif, mais c’est quand même pas mal comparé à d’autres sites.

Cependant, l’idée de faire des sites "verts" m’intéresse pas mal. Non pas que je sois à fond dans l’écologie, mais c’est quelque chose qui me fait de plus en plus réfléchir.

Pensez-vous qu’il soit possible de créer des sites écolo, et si oui, cela peut-il avoir un impact significatif (non pas mondiale, mais à l’échelle d’un site) ? Je veux dire par là, la différence entre un site non pensé pour, et un site pensé pour l’écologie sera-t-elle assez importante ?

Ma question est un peu vague, et je n’ai moi même pas vraiment d’idée plus précise en tête…

Alors ceci peu certainement t’intéresser (si tu ne l’as pas déjà lu).

Comment fabriquer un site internet à basse technologie ?

Va sur ton média grand public préféré sans bloqueur de pub, regarde ta consommation CPU, puis fait de même avec bloqueur. Le Gabbro’s Institue of Pifometry affirme que l’énergie consommée par l’affichage d’une page (production, envoi, chargement) peut être réduit très fortement et simplement.

Les études qui donnent des couts carbone très importants pour les sites ajoutent souvent la consommation du PC local, y compris l’affichage de la page pendant sa lecture. C’est-à-dire qu’une minute de page très chargée pourrait être moins polluante qu’une demi-heure d’une page de texte chargée une fois pour toute. La méthodologie de ces études est à vérifier au cas par cas mais est souvent très douteuse.

Ces probablement le cas ici, puisque les estimations sont de l’ordre de 20 mg d’équivalent CO₂ par seconde (estimation Wissner-Gross en 2012) sans compter le client final. Comme le pointe la page d'@ache, le client final compte pour 40 % dans leur estimation. Sauf que l’électricité ne pollue pas pareil en Suisse ou en France et aux États-Unis. Bref, à prendre avec beaucoup de recul.

Ça peut par contre servir quand même de comparatif. Savoir où est fait le mieux, en terme de charge de la page, et du coup par où chercher.

Oups…

Je vois pas comment on peut avoir ne serait-ce qu’un début de précision.

Je vais prendre un exemple extrême, mais imaginons une page statique qui au clic sur un bouton lance une tâche asynchrone sur le serveur impliquant au choix : du minage de cryptomonnaies, du rendu graphique, de la factorisation de nombres premiers, du traitement vidéo, etc, etc.

D’après ce site, la consommation est proportionnelle à la taille de la réponse. Donc on aura une consommation très faible alors que ce sera loin d’être le cas.

En fait la mesure est bonne, si elle ne donne pas lieu à interprétation.

L’unique constat qu’on peut en tirer est que ZdS est assez économe en bande passante pour afficher ses pages, même s’il pourrait mieux faire (CDN ?). En tout cas, il utilise HTTP/2, positionne les headers permettant au navigateur de mettre en cache la réponse, etc. Y’a qu’à voir la floppée de 304 arriver quand on recharge cette page.

Il s’affiche sans doute plus vite que d’autres sites, d’autant plus dans des conditions de réseau dégradées, et en limitant les aller-retour HTTP entre client et serveur, consomme nécessairement moins d’énergie dans le transport de la donnée que s’il renvoyait systématiquement l’intégralité des réponses HTTP avec des headers "no-cache" ou "must-revalidate" (merci Lapalisse).

C’est déjà pas si mal cela dit !

Par contre de là à estimer une conso en CO2, y’a un gouffre intersidéral.

Pensez-vous qu’il soit possible de créer des sites écolo, et si oui, cela peut-il avoir un impact significatif (non pas mondiale, mais à l’échelle d’un site) ? Je veux dire par là, la différence entre un site non pensé pour, et un site pensé pour l’écologie sera-t-elle assez importante ?

Ca dépend forcément du nombre de pages affichées par ton site web.

On pourrait donner des conseils assez génériques, au cas où…

• Bien utiliser le protocole HTTP, HTTP/2. Les en-têtes de Cache notamment. Bref, être fair-play avec le navigateur du client en lui disant ce qu’il peut éviter d’aller chercher, et ce qu’il doit effectivement redemander à chaque fois.
• Comme SpaceFox l’a mentionné : utiliser des CDN pour les "assets". Surtout s’il y a de fortes chances que le navigateur du client ait déjà téléchargé certains de ces assets (les polices, par exemple) sur d’autres sites
• Limiter les traitements sur le serveur. Theo parle de cryptomonnaies, c’est évidemment un exemple extrême, mais si une page est énormément consultée (la page d’accueil ?) et qu’elle contient un traitement côté serveur très lourd et inutile, forcément, c’est un énorme gâchis de ressources.
• Faire confiance au navigateur du client pour lui donner une "boucle de retour" (feedback-loop ?) rapide. Même s’il est indispensable de contrôler ses saisies côté serveur, si on SAIT qu’il a fait une erreur, autant lui épargner de faire un aller-retour (round-trip) HTTP pour savoir qu’il a fait une erreur.
• Limiter la taille des assets : spécialement s’ils sont chargés sur TOUTES les pages d’un site (hi Javascript bundlers, I hate you too). Y’a des outils, notamment via webpack, qui permettent de regarder quelles bibliothèques prennent le plus de place dans le bundle final envoyé au client, on a parfois de sacré surprises. Parfois c’est un bête truc qu’on a ajouté un jour et jamais supprimé, parfois c’est pour une bête fonction qu’on a ajouté 10Ko de JS compressé, ça valait sans doute pas le coup
• Eviter de faire pédaler le navigateur du client pour rien… Le dynamisme, les "Single Page Application" tout ça c’est top dans certains contextes, mais c’est à bien utiliser. Pas la peine de faire calculer au client des décimales de PI… Ou juste de lui faire redimensionner ou traiter des images. Tout ce que le serveur peut faire. En gros : mettre en facteur les traitements utiles à tous les utilisateurs sur le serveur, mettre en cache le résultat si c’est pertinent, et ne le transférer qu’au besoin
• Et évidemment : nettoyer. Nettoyer du code (surtout s’il est transféré sur le réseau), nettoyer des données en BDD, nettoyer des assets. Tout ce qui n’existe pas ne coûte rien, en quelque sorte

Bon, tout ça c’est 100% captain obvious hein, je pense que c’est principalement deux trucs à avoir à en permanence à l’esprit :

• KISS : est-ce vraiment nécessaire ? Est-ce-que le ratio fonctionnalité apportée <-> traitement nécessaire est vraiment favorable ?
• Est-ce-qu’il existe une fonctionnalité du langage ou protocole que j’utilise (PHP / HTTP, Rust / TCP, etc.) qui me permettrait d’optimiser les échanges, ou les traitements. Est-ce-que je suis assez feignant (lazy), c’est-à-dire : est-ce-que je pourrais déférer mon traitement uniquement au moment opportun.

Je pense qu’un bon début pour aller dans ce sens là serait de faire une utilisation raisonnable du JS, des animations, etc.
Côté serveur, opter pour des machines basse consommation s’il n’y a pas de nécessité de puissance de calcul. Ou bien, choisir un datacenter "vert".