Edit : Suite à une visio avec Pierre Beyssac et Quentin Adam, je pense que cet article aurait besoin d’être mis à jour. Ce que je prendrais le temps de faire dans les semaines à venir.
#
L’éco-conception web
Un site internet par définition ne peut pas être écologique, tout comme le web d’ailleurs.
« Alors tout ce que l’on peut faire ».
C’est diminuer les impacts environnementaux, notamment via notre façon de concevoir nos applis.
C’est un peu comme la philosophie 0 déchet.
Tu pollues beaucoup (beaucoup ?) moins, mais tu pollues quand même…
Il est temps de commencer à réfléchir avec une optique low-tech numérique.
Même si, comme remontée dans les études, c’est la construction des terminaux qui pollue le plus.
Diminuer les besoins en ressources lorsque nous développons aura un effet positif sur l’impact environnemental des sites web.
Mieux encore, on rendra également le web accessible, une des missions du développeur.
Le but est de faire un pas vers l’écologie, même petit.
L’écologie c’est faire plus, mais avec moins.
Quentin Adam
On a tous une responsabilité envers le numérique, et les développeurs ont aussi leur rôle à jouer.
#
Comment construire un site internet écologique
Le but de cet article orienté GreenIT n’est pas de te montrer du doigt les datacenters de Google.
Ni de te dire que les objets connectés vont rajouter de la pollution numérique.
Que de toute façon c’est foutu.
Le but de cet article c’est de sensibiliser les développeurs à la conception web écologique.
Car par définition on ne peut pas construire un site internet écologique.
Un site internet ne peut pas être écologique. On peut en revanche écoconcevoir un service numérique pour réduire les impacts environnementaux associés.
Frédéric Bordage
#
3 principes clés pour un site web green
Avant de rentrer dans le vif du sujet, note que l’éco-conception d’un service numérique doit couvrir l’ensemble des acteurs du projet.
L’éco-conception d’un site internet doit être une décision commune entre les développeurs, les chefs de projet / PO, les UX/UI designers, le client…
Les objectifs sont annoncés d’entrée :
Réduire le nombre de requêtes
Diminuer le volume échangé
Limiter les traitements d’information (vive le cache)
Ces 3 points suffisent à engager la conversation vers la conception d’un site web éco responsable.
Encore une fois le but n’est pas d’avoir un site qui ne pollue pas, mais d’avoir un site qui pollue (beaucoup) moins.
Si tu n’es pas encore convaincu de l’utilité des éco-TIC, regarde ce graphique.
On voit là aussi que la moyenne du poids des pages ne fait qu’augmenter.
L’impact environnemental du web continue de s’accentuer.
Et les estimations sont pessimistes avec le web 3.0…
#
Les bonnes pratiques d’éco-conception web
Que peut-on faire pour limiter l’impact écologique de la création de site et d’applications web ?
La bonne pratique principale à suivre est ce que l’on appelle le Green UX.
L'idée est d'avoir une interface plus simple, plus sobre, plus épurée, sans nuire à l'expérience utilisateur.
Ceci inclut notamment :
Supprimer la complexité autant que possible
Choisir des technos légères et ciblées pour un besoin précis
N’utiliser que le strict nécessaire (on n’inclut plus du tout Bootstrap en CDN comme en 2011…)
Penser aux débits des connexions internet plus faible
Et ça inclut aussi de penser à ceux qui ont un téléphone à 50 €.
Tu concéderas que la vitesse d’exécution de JavaScript n’est pas la même avec un téléphone à 50 € à un autre à 300 €.
Un très bon test pour savoir si ton site internet est écologique
Et c’est tout bête.
Navigue sur ton site internet en 2G.
Tu rentres ainsi directement dans la sobriété numérique.
DOM Content Load : 1.82 s
Ce test permet de sensibiliser directement les clients à l’accessibilité générale de leur site internet.
Si ton site internet n’est pas chargeable sur de « vieux smartphones » ou depuis des endroits (un peu) reculés…
C’est sans doute qu’il mérite d’être optimisé.
Le but de l’éco-conception numérique n’est pas de retourner en 2004.
Mais d’arrêter de charger plein de trucs en pensant que nous sommes tous en 4G+.
#
Un site internet green n’est pas un site rapide
Un site web peut être super rapide mais pas green du tout !
À l’inverse un site green sera sûrement plus rapide.
Ce qui fait la performance n’est pas forcément le volume de données transféré ou le nombre de ressources.
La performance vient avant tout de la puissance du serveur, puis du système qui l’exploite, et enfin de la qualité de la connexion.
Si le serveur rend une page HTML avec un TTFB (time to first byte) très faible et que la majorité du contenu est chargée en asynchrone, cela peut être super rapide.
En revanche si mon serveur tarde à me renvoyer cette première page HTML mais qu’elle est super light, on pourra considérer le site comme « lent ».
C’est le paradoxe performance vs éco-conception web.
Mon TTFB n’est pas terrible, mon site est « lent ». Mais ça ne veut pas dire qu’il n’est pas écologique !
Enfin, c’est à relativiser…
Plus on fait attendre l’utilisateur, plus on consomme d’énergie.
Le TTFB ou temps de réponse serveur dépend énormément de ton hébergement.
Comme on vient de le voir, tu peux avoir un « site internet écologique » et super rapide avec un serveur lent.
Cependant un serveur lent nuira à l’écologie de ton site !
Il vaut peut-être mieux avoir un serveur légèrement plus puissant pour que le terminal utilisateur attende moins et consomme moins de batterie...
Cela se discute totalement, mais c’est compliqué à mesurer.
Temps de réponse serveur sur mon mutualisé chez OVH
Avec un hébergement à 39 € par an, on ne peut pas faire de miracle non plus.
Alors même si la vitesse n’est pas nécessairement au rendez-vous, ce serait pire avec un site internet « classique », ou en tout cas pas éco-conçu.
On n’a pas commencé que l’on voit déjà les avantages d’avoir un site web écoconçu !
#
Quelques exemples de sites internet
La performance n’est pas forcément liée à un site internet créé écologiquement.
Lent et pas écologique
http://usainbolt.com/
Des tonnes d’images et de JavaScript chargés
Pas de http2
Le lazyload n’existe pas
…
Rapide et écologique
https://sustywp.com/
Incroyablement rapide, une seule image en SVG
~6 KB seulement pour se connecter à ce site
C’est ça, la sobriété numérique
Site internet rapide mais pas écologique
https://www.amazon.fr/
Le site charge énormément de contenus tiers
Il est en revanche super rapide
L’éco-conception d’un site internet impacte son temps de chargement dans le bon sens.
Mais ce n’est pas pour autant qu’un site rapide est un site green.
#
Que penser des agences web qui proposent de planter des arbres ?
Ce n’est pas de l’éco-conception de site internet.
Au mieux, c’est un beau geste (un geste qui est top tout de même).
Une agence web green, elle pense avant tout Green UX, accessibilité du site aux faibles connexions, diminution des ressources utilisées, performances...
C’est cela qui importe.
De manière générale, 2 solutions sont disponibles pour compenser l’impact écologique.
L’utilisation de l’énergie « verte » : l’énergie « renouvelable », les parcs éoliens, le solaire…
La compensation carbone : Tu achètes des « crédits-carbones » auprès d’entreprises dont le but est de faire diminuer le CO2…
Le but de l’éco-conception de sites internet, c’est de réduire le poids d’internet et sa consommation en ressource.
Planter des arbres c’est top, mais le premier objectif est bien de « mettre son site internet au régime ».
Pas de compenser ses excès !
Attention au marketing…
1 projet = 1 arbre planté, c’est super !
Mais est-ce qu'un seul arbre planté absorbe la pollution numérique engendrée par la création d'un site internet, même s'il est écologique ?
J’en doute un peu.
#
L’éco-conception web pour les développeurs
Avoir un site internet éco-conçu est un avantage pour le client, dans tous les cas.
Mais aussi et surtout, c’est un avantage pour tous les utilisateurs !
Même si le client souhaite un design riche, rempli avec des animations…
Le développeur sensibilisé à l’éco-conception web pourra réduire le poids du site internet, tout en respectant le cahier des charges.
Concevoir un site écologique c’est avant tout mettre l’accent sur certaines bonnes pratiques.
En tant que freelance, je pense que tu aurais tout intérêt à te former à l’éco-conception web car c’est un vrai plus pour ton client.
#
✅ Les avantages de l’éco-conception web
Mettre en avant l’éco-conception d’un site internet à ton client c’est :
Une économie d’argent, car on met moins de tout
Se concentrer sur le besoin initial et sur le besoin utilisateur : on va à l’essentiel
C’est plus efficace pour convertir ? À débattre, mais comme l’idée est d’avoir moins de superflues sur le site, on distrait moins l’utilisateur
Avoir un site internet plus rapide = moins de taux de rebond, un utilisateur satisfait
Un meilleur référencement, le SEO est important
Une meilleure portée, davantage de personnes pourront accéder au site
Pour avoir accès à ses avantages, je te donne « quelques » conseils plus bas 👇
#
❌ Les inconvénients d’un site web écologique
Si la création d’un site internet a un inconvénient, c’est celui-ci :
L'UI (interface utilisateur) est impactée, les choix en termes de design sont plus restreints ; dans une moindre mesure.
Est-ce qu’Amazon peut diminuer son impact environnemental depuis son site internet ?
Sûrement.
Sans toucher à l’UI de la plateforme ?
C’est moins sûr.
Comme l’hébergement leur coûte beaucoup d’argent, même chez eux, j’imagine que leurs images sont compressées, leurs requêtes lazyloadées…
Mais dans ton cas :
Si ton client souhaite par exemple avoir beaucoup d'images sur son site (et c'est mon cas par exemple), tu vas devoir trouver le moyen de ne pas en impacter l'utilisateur (compression, changement de format, lazyload...).
Le but n’est pas de dire « non » à son client.
C’est de trouver des solutions pour être green sans pour autant nuire à la communication.
#
Niveau techno, tu profites toujours des dernières innovations
La hype du moment, c’est JavaScript (et ça fait un moment).
Le problème du JS côté client, c’est qu’il consomme davantage de CPU que le HTML et la plupart du CSS.
Est-ce qu’il faudrait éviter d’utiliser JavaScript sous prétexte que cela consomme des ressources ?
Je ne pense pas.
Tout dépend du site internet que l’on crée, la question à se poser est surtout…
Est-ce que j'ai besoin de JavaScript sur mon site ?
J’aurais pu construire mon blog avec NextJS et une génération statique.
Mais le contenu que je produis ne bénéficierait pas je pense de la couche JS, il y a peu d’interraction avec l’utilisateur, si ce n’est de naviguer de page en page.
Si on regarde le code du blog, il n’y a quasiment pas de JS, car je n’en ai pas besoin.
Quand on parle d’éco-conception web, réfléchir à ce dont on a besoin en amont est un excellent début.
Comparaison des technos utilisées par plusieurs sites
Y a-t-il une corrélation entre la techno utilisée et de mauvaises performances écologiques ?
J’ai été voir les quelques sites que j’ai consultés récemment, puis les ai passés sur WebPageTest.org depuis Paris.
Comparaison rapide des sites que j’utilise et des technos.
On se rend vite compte que la vitesse de chargement ne veut (presque) pas dire grand-chose ici, tout comme le langage utilisé.
Peu importe le nombre de requêtes et le volume transféré, la vitesse d’affichage est très similaire.
Encore une fois, le serveur y joue pour beaucoup.
Plus que la techno, j'ai l'impression que c'est surtout la manière de coder et les ressources utilisées qui déterminent l'empreinte écologique d'un site internet (côté front).
Nota Bene : Je n’ai pas pris en compte l’exécution du CPU dans mon tableau, ce qui serait un bel indicateur de plus ; je le ferai dans les semaines à venir.
Web Workers (on exécute du JS dans un thread séparé pour éviter de bloquer le thread principal)
Services Workers (un middleware qui met en cache les requêtes HTTPs, permet de profiter d’une navigation hors-ligne)
WebAssembly (exécuter du code bas niveau dans un navigateur (car JS est actuellement le seul langage supporté par tous les navigateurs))
Ces outils-là on peut dire qu’ils sont éco-friendly.
Comme les services workers permettent de mettre en cache les requêtes HTTP... Si tu fais une webapp, tu as tout intérêt à les utiliser.
Admettons que tu aies besoin de récupérer une liste de groupes utilisateurs pour une dropdown.
Requête HTTP avec React
Cette liste est globale, elle ne change jamais !
Tu as plusieurs choix.
🔴 Faire tes appels HTTPs à chaque fois qu’on en a besoin…
✅ Faire un appel HTTP, puis mettre en cache le résultat dans :
Le navigateur (Local Storage, Session Storage…)
L’état global de l’application
Un service worker
Pour le coup, le service worker rempli pleinement ses objectifs en termes de solution écologique et de performance !
Qui plus est, c’est relativement facile à utiliser.
Voici les résultats du benchmark
Benchmark : Avec et sans service workerBenchmark Web Workers : 1 thread vs 8 threadsBenchmark : Web Assembly VS JavaScript
En matière d’informatique verte et durable, le choix d’une PWA est tout à fait adapté.
Pour une application mobile ou une application web.
Bien entendu, il faut que tes besoins fonctionnels le permettent.
Pour développer un jeu ou une application qui demande des ressources, il vaut mieux s’engager sur une appli native.
PWA vs applications hybrides
Les PWA utilisent du code HTML, CSS, JS tout comme un site internet « classique ».
Les applications hybrides embarquent ou utilisent la webview du smartphone.
La différence est subtile mais bien présente : les PWA ne pèsent rien et utilisent l’API du navigateur.
Les applications hybrides utilisent des bridges pour pouvoir appeler les APIs de l’OS sur lesquelles elles sont installées.
Quand elles embarquent leur webview, le poids des apps hybrides monte en flèche.
En pensant à cela, on pourrait se dire que les PWAs ont ici aussi une empreinte écologique plus faible que les applications hybrides.
Pour un rendu visuel parfois très similaire.
#
Le développement d’application mobile
C’est aussi un sujet.
On a parlé de PWA, mais pas d’application native.
Tu le sais tout comme moi, la consommation énergétique des applications mobiles est de pire en pire.
Si ton tel n’a pas 4 GO de RAM, il rame…
C’est une honte.
Si nos téléphones n’avaient qu’un seul et unique gigaoctet de RAM, l’environnement s’en porterait bien mieux, en construction comme en consommation.
Certes, la RAM consomme peu, mais la manière dont nous abusons des ressources est flagrante.
En plus de leur consommation en énergie, en réseau, en CPU, le poids des applications mobiles est en constante progression...
Green Peace a fait une étude en 2017 pour mesurer quelles applications consommaient quel type d’énergie (charbon, nucléaire, gaz naturel, renouvelable…).
Pour une application censée être accessible… Ça craint.
Alors oui, le mieux serait bien évidemment de se passer d’applications sur son téléphone.
Mais c’est aujourd’hui impossible, ces apps, on en a « besoin ».
Je n’ai pas spécialement de conseils à donner car je ne suis pas développeur mobile et que les données me manquent sur ce terrain-là.
Cependant, les bonnes pratiques restent toujours les mêmes.
#
Les outils pour vérifier l’empreinte écologique de son site
Hormis le petit test que l’on a fait tout à l’heure en bridant le network du téléphone en 2G, des outils existent pour mesurer l’impact environnemental des sites internet.
La performance (qui joue tout de même dans l’éco-conception) n’est qu’une partie des 5 thèmes traités par l’application.
37 requêtes pour 300KB transférés
37 requêtes pour une page d’accueil avec quelques images, on peut dire que c’est déjà pas mal (peut-être trop ?).
On pourra optimiser un peu plus en termes d’éco-conception web (on peut toujours optimiser).
Quand on regarde de plus près, le site est déjà bien optimisé, le lazyload des images fonctionne au top.
Globalement, que penser des suggestions de Google ?
L’objectif pour Google c’est de fluidifier la navigation de l’utilisateur, et donc d’améliorer les performances.
L’objectif n’est pas l’écologie.
Fort heureusement pour nous, en améliorant les performances tu amélioreras certainement l'éco-conception de ton site web.
Web Vitals concernant ce site
Les conseils de Google en ce sens nous permettent de diminuer un peu plus l’empreinte carbone de nos sites web.
Modules CSS et JS splittés par page (chaque pas ne doit avoir que ce dont elle a besoin) ;
Réduire le temps de travail de JavaScript sur le thread principal, ou limiter JS tout simplement.
Ce sont généralement les deux conseils qui reviennent le plus souvent !
L’avantage est aussi d’améliorer ton Budget Crawl.
Plus ton site sera rapide, plus Google pourra parcourir de pages et pourra te référencer.
#
Ton site internet n’est pas que la page d’index
Chaque page ne se ressemble pas.
Tu disposes sans doute de plusieurs types de pages sur ton site :
Accueil
Page
Articles
Taxonomies
Produits
Recherche
Etc
Chaque affichage à l’intérieur de ces types de page peut être différent.
On a tendance à passer les outils de performance uniquement sur la page d'index.
Chaque page d’un site web a un temps de chargement différent. Dans Analytics sélectionne Comportements > Vitesse du site > Suggestions relatives à la vitesse
N’oublie pas que l’objectif de l’éco-conception, c’est d’avoir un site internet le plus léger possible dans son ensemble.
Avoir une page d’accueil super light et une page boutique super lourde, ça ne marche pas.
#
Quelle est la proportion de code inutilisé sur mon site ?
Chrome possède un outil appelé Code Coverage.
Comme son nom l’indique, il permet de vérifier la couverture des différents scripts et styles dans ta page.
Autrement dit!…
Quel pourcentage de mon CSS et de mon JS est utilisés sur cette page ?
Les publicités et les outils de tracking mettent à mal l’éco-conception numérique.
Ils sont une sacrée charge pour le navigateur. En poids, et en consommation.
Faut-il les enlever ?
J’imagine que pour le métier c’est impossible.
Mais il est possible d’engager une transition vers d’autres outils.
Privilégier une analyse de logs si l’analyse des analytics se concentre sur les pages vues
Utiliser des alternatives à Google Analytics, moins gourmandes (Matomo, Plausible…)
Changer son business model trop orienté publicité ? Perso, il y en a tellement que je la vois même plus…
Niveau conception de site internet écologique, on peut se poser ces questions :
A-t-on réellement besoin de tout cela ?
Va-t-on réellement exploiter ces données ? Ou c’est au cas où on en a besoin un jour ?
Sert-on vraiment l’utilisateur avec ?
Finalement, est-ce que ça ne fait pas plus de mals que de biens côté UX ?
Définir le cycle de vie de la donnée client permettra aussi à ton client de définir une vraie stratégie sur « quoi faire avec ces données ».
#
Critical Path : Ne charger que le strict nécessaire
Perso, je ne l’ai jamais fait, mais ça a un intérêt.
Tu divises ton CSS en deux parties.
La première est chargée dès que tu rentres dans le site, le site ne s’affiche pas sans elle, le CSS comporte tout le style au-dessus de la ligne de flottaison
La seconde est chargée plus tard, le CSS comporte le style du bas de la page
Certains outils en ligne te permettent de générer ce CSS Critical Path pour ton site.
La compatibilité IE reste un vrai sujet pour les entreprises françaises.
Pour ma part je n’utilise donc pas cette fonctionnalité native.
Trop de chance pour qu’elle ne soit pas supportée par le navigateur client…
Lazyload tout ce que tu peux
Les images
Les vidéos
Le JS (grâce à Webpack)
Les fonts ?
…
Sachant que les deux premiers sont super importants.
✅ Utilise une lib Vanilla JS légère et adaptée à tes besoins pour charger en différé toutes les images au-dessus de la ligne de flottaison, comme verlok/vanilla-lazyload.
⚠️ Si tu affiches des vidéos sur ta page, tu dois sûrement les lazy-loader aussi.
Faut-il toujours utiliser une spritesheet ?
À l’époque d’http1.1, ça avait tout son sens d’utiliser une spritesheet.
Comme les requêtes n’étaient pas exécutées en parallèles, il fallait éviter les allés-retours.
✅ Aujourd’hui avec http2, il semble plus intéressant de charger 10 x 150 KO qu’une seule fois 1.5 MO.
Notamment car :
Cela sera plus rapide pour l’utilisateur (il attend donc moins, consomme moins d’énergie)
Pour le serveur cela ne change pas grand-chose (qu’il soit utilisé ou non la facture énergétique ne fluctue pas énormément)
Le volume de données entre 1 grosse et 10 petites requêtes varie très peu (même connexion TCP, compression des entêtes…)
Le cache fonctionnera mieux (réutiliser d’une image, invalidation d’un seul élément…)
Plus il y a de connexions ouvertes, moins http2 consomme de l’énergie ?
C’est ce que l’on pourrait être tenté de déduire de cette étude.
On parle d’http2 plus bas. 👇
Qui plus est, lorsque l’on utilise la sprite de quelqu’un d’autre, on n’utilise jamais toute la feuille.
Exemple d’utilisation d’une Sprite Sheet avec des drapeaux
Si je prends l’utilisation des drapeaux ici, il y en a certains que je n’afficherai jamais, pourtant ils sont chargés.
Ce n’est pas très orienté éco-conception !
Le SVG est-il toujours meilleur ?
Comme tu le sais, le SVG est fait de XML, comme notre bon vieux HTML.
À ce titre, il ne pixélise pas et est super léger.
On l’utilise surtout pour les logos et les icônes.
Comparaison des performances : SVG inline vs Fonts vs Img ?
Je me suis posé la question en écrivant cet article, lequel des 3 est le plus performant ?
Comme à chaque fois, tout dépend des cas d’utilisation.
Techno
Utiliser quand
Performance
SVG Inline
Chargement synchrone avec la page, pas de scintillement
🙂 Pas mal, mais pas de mise en cache + interprétation du navigateur
SVG dans <img src="" />
Peu d’éléments à afficher
😐 Peut causer beaucoup de requêtes HTTP
Font
Envie d’afficher globalement des icônes sur le site
😀 Peut-être asynchrone
Cas d’utilisation entre SVG inline, SVG dans balise img et icônes dans une font
L'éco-conception web c'est aussi choisir le bon outil pour l'usage que l'on en fait.
À toi d’en faire bon usage.
Chargement des polices pour les icônes
Concernant les polices de caractères pour les icônes, évite d’inclure la totalité des éléments.
Je pense notamment à Font-Awesome qui est très souvent inclut dans sa globalité sur les projets.
https://icomoon.io/app/#/select/
✅ Tu peux utiliser des outils comme IcoMoon pour te créer ta propre bibliothèque d’icônes, et n’inclure que les images dont tu as besoin.
Redimensionne tes images
La question ici ne fait même pas débat.
Imagine une image de 1920 x 1200 pixels, magnifique.
Si tu l’affiches dans un conteneur avec une largeur de 960 px par exemple, tu gaspilles inutilement de la bande passante.
Une image en 960 x 600 pixels aurait suffi.
✅ Ne réduis pas la taille de tes images en CSS, utilise des alias !
L’idée est de définir une config avec la taille exacte que tu souhaites, puis d’utiliser un binaire qui va redimensionner l’image pour toi, à la volée ou non.
https://github.com/liip/LiipImagineBundle
C’est de loin la meilleure technique pour diminuer le poids de ses images.
J’illustre mes propos avec un lib PHP, mais le redimensionnement d’images ça existe sur tous les frameworks, tous les langages.
Compresse tes images
Sans être un expert, deux choses importantes concernant les images et l’éco-conception.
Le format « classique » utilisé (JPG, PNG, GIF, SVG)
Le format « converti » de l’image pour la performance (webp, avif, …)
Format
Utilisation
PNG
Images de très bonne qualité avec possibilité d’avoir un fond transparent.
JPEG
On peut l’utiliser pour des images converties avec ou sans perte, généralement le format le plus optimisé.
GIF
Compression sans perte uniquement mais seulement 256 couleurs.
SVG
Du XML interprété par le navigateur sous forme de vecteur, plus intéressant avec les images (logos, icônes etc), pas les photos.
Tableau des différents formats d’images utilisés sur le web.
Compression Lossless vs Loosy
Lossless : Sans perte (moins performant)
Loosy : Avec perte (plus performant)
C’est ce qu’il faut retenir.
Lossy (avec perte)
Lossless (sans perte)
Supprime des données dans l’image, on perd en qualité.
Supprime des données « non visibles » dans l’image, la qualité reste la même.
On l’utilise surtout pour les images, l’audio, la vidéo.
On l’utilise surtout pour le texte, le son, les images.
Beaucoup plus performant en termes de compression.
Bien moins performant en termes de compression.
Compression irréversible.
Compression réversible (on peut récupérer l’image d’avant)
Devant ses promesses, j’ai installé la conversion à webp sur tous les sites WordPress que j’utilise, car tous les navigateurs récents (ou presque) le supportent.
On parle aussi beaucoup d’Infomaniak, mais comme la seule expérience que j’ai eue avec eux n’était pas du tout concluante, je me garderai de donner mon avis.
#
Où héberger son site web ?
La bonne question à se poser avant tout est : où sont mes utilisateurs ?
Dans Analytics : Sélection Audience > Données géographiques > Zones géographiques
Sans surprise le plus gros de mon trafic est français.
Niveau GreenIT, j’ai tout intérêt à héberger mon site au plus proche de mes visiteurs.
Moins de bandes passantes utilisées, car moins de distance ;
De meilleures performances pour l’utilisateur final.
Une autre question intéressante à se poser est « comment mon énergie est-elle produite ».
https://www.electricitymap.org/map
Dans le cadre d’un hébergement dit « green », ça semble être une bonne idée.
https://www.electricitymap.org/zone/FR
Le nucléaire c’est « pas terrible », mais 23% d’énergie renouvelable c’est quand même pas mal du tout.
Dans tous les cas la production d’électricité est loin d’être écologique…
Alors faisons au mieux.
#
Serveur virtuel VS Serveur dédié
La virtualisation permet d’économiser de l’énergie, au lieu d’avoir un système d’exploitation par machine, tu peux t’en retrouver avec plusieurs.
Plusieurs sites et plusieurs clients peuvent être hébergés sur un seul et même serveur physique, grâce à la virtualisation.
La virtualisation permet notamment :
Réduction des coûts ;
Des performances de plus en plus bonnes ;
Une administration système plus facile ;
D’exploiter davantage de ressources sur le serveur (les serveurs ne sont pas tous utilisés à 100% de leur capacité) ;
✅ Pour le coup il n’y a pas de débat, la virtualisation est meilleure pour l’environnement que le serveur dédié.
De manière générale la mutualisation permet d’utiliser moins de serveurs ; ce qui j’espère diminue leur construction…
Voici ce qu’annonçait VMWare en 2008.
Chaque serveur physique virtualisé représente une économie annuelle de 7 000 (kWh), soit 4 tonnes de CO2.
Pour aller plus loin, je t’incite à regarder cet excellent article qui explique pourquoi il ne faut pas tout précharger.
Le préchargement des ressources est génial pour la performance.
Suivant comment il est utilisé, il peut potentiellement nuire à l’éco-conception.
#
Utilise le cache autant que possible
Le but du cache, c’est de ne pas exécuter une opération coûteuse plusieurs fois de suite.
Niveau performance et écologie, c’est top !
L’éco-conception web tire parti du cache, peu importe lequel.
Mais le cache n’est pas la solution à tous les maux.
L’utilisation du cache ne doit pas compenser le manque de rapidité d’un outil.
Si tu te dis « mon application est lente, mais pas grave, y’a du cache serveur », c’est que quelque chose ne va pas.
Et ce qui ne va pas, c’est ton code.
Le cache applicatif
Le cache applicatif t’aide à garder en mémoire le résultat d’une opération complexe et bien souvent plus longue.
Mémoïsation
Le but de la mémoïsation est de mettre en cache le retour d’une fonction si ses attributs en entrées ne changent pas.
Voici un exemple avec React :
Filtrage des « checkings » en fonction de leurs familles. Si `props.eventFamily.id` et `values.materialCheckings` ne changent pas, React n’exécutera les fonctions `filter()` et `map()` qu’une seule et unique fois. Il gardera en cache le résultat pour les futurs appels.
Ce type d’optimisation est très intéressant.
👉 J’utilise la mémoïsation lorsqu’une fonction est appelée plusieurs fois et que ses paramètres ne changent pas ou peu.
Redis etc
Redis est une base de données sans persistance qui a la particularité d’être super rapide.
Dans l’idée, elle garde en mémoire le contenu d’une variable.
Exemple d’utilisation de Redis en PHP pour stocker la récupération coûteuse de certifications depuis la base de données. Ces certifications sont demandées à de multiples endroits dans l’application.
👉 Je l’utilise par exemple lorsque :
Un service externe est appelé et que ses entrées ne changent pas ou peu ;
Une requête coûteuse est exécutée en base de données et que le résultat de cette requête est demandé à plusieurs reprises ou à plusieurs endroits.
L’idée est de mettre en cache une partie de ton document.
Si tu as une zone « Bonjour Alex, » sur ton site et que tu veux mettre en cache tous les autres éléments de la page, cela répond à ton besoin.
De même si tu fais un site e-commerce et que ton utilisateur a son panier dans le header, tu peux tout mettre en cache, sauf le panier : grâce aux ESIs.
Le cache sert en totalité l’éco-conception web et ses applications sont nombreuses, fais-en bon usage autant que possible.
Le cache navigateur
C’est ton navigateur qui garde en cache pour toi certaines ressources que le serveur lui envoie.
Par exemple si on regarde ce site.
Cache navigateur : Le navigateur ne re-demande pas certaines ressources après le premier appel.
La sélection en bleue correspond au rechargement de la page.
En rechargeant ma page, on voit que les ressources entourées en rouge ont été « mises en cache ».
Le navigateur n’interroge plus le serveur, il garde ces fichiers dans son cache.
Tout au long de ma navigation sur le site, je n’appellerais plus le serveur pour récupérer ces fichiers-ci.
L’éco-conception joue un rôle très important ici.
Le fait de mettre en cache des assets, c'est économiser beaucoup de bande passante, de la charge serveur...
Pour mettre en cache ces ressources, on passe par des entêtes HTTP (comme pour le cache serveur).
Pour illustrer un peu, voici une configuration .htaccesspour Apache HTTPD assez standard.
filesMatch
Ici on fonctionne par extension.
Les images sont mises en cache 1 mois
Les assets (CSS & JS) sont mis en cache 1 jour
<IfModule mod_headers.c>
<filesMatch ".(ico|jpg|jpeg|png|gif)$">
Header set Cache-Control "max-age=2592000, public"
</filesMatch>
<filesMatch ".(css|js)$">
Header set Cache-Control "max-age=86400, public"
</filesMatch>
</IfModule>
filesMatch est la directive « moderne ». Si spécifiée elle prend le pas sur la directive Expires.
ExpiresByType
Ici on fonctionne par type de fichier.
<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
...
</IfModule>
Les fichiers CSS & JS seront mis en cache par le navigateur pendant 1 an.
C’est tout naturellement comme cela que l’éco-conception rentre en compte dans les critères de positionnement.
Avoir un site web écologique plaît à Google, donc ça devrait te plaire aussi.
C’est aussi un argument de plus pour ton client.
#
Conclusion
Le but n’est pas de faire culpabiliser qui que ce soit.
D’ailleurs, je suis le premier à mettre plein d’images consommatrices de ressources dans mes articles de blog…
Je ne suis pas à prendre pour exemple, même si ce site se base sur SustyWP, j’ai encore du travail à fournir.
Pour moi, il faut avoir conscience que le web consomme énormément, et que trier tes emails ne va pas renverser la vapeur.
Il resterait d’ailleurs tellement d’autres sujets à aborder…
Par exemple, que comme la durée de vie des sites est en moyenne de 4 / 5 ans avant refonte (de mon expérience), les développeurs ont l’impression de faire du code jetable.
Mais chaque chose en son temps.
Sensibilisons déjà nos amis, nos collègues, tes clients…
L’éco-conception web appliquée au développement, ce n’est pas si compliqué.
Avec cet article, je souhaitais aller un peu plus loin sur l’écologie des sites internet, et m’enrichir aux passages de connaissances qui me serviront en tant que dev.
On est tous capables, en tant que développeur web, de faire de petits efforts qui ont de gros impacts pour la planète 🌍.
#
Note à toi
J’ai fait au mieux pour écrire cet article avec la plus grande neutralité.
J’ai passé des semaines à faire des recherches, pour mettre au total 3 mois à écrire ceci.
Mon interprétation n’est peut-être pas la meilleure, les données récoltées ne sont peut-être pas toutes véridiques…
J’aurais fait de mon mieux pour sensibiliser les développeurs web à l’éco-conception.
Je dis ça car le sujet est très sensible.
Les fausses informations sur internet n’aident pas, et j’espère ne pas être tombé dans le greenwashing.
Sens-toi libre d’apporter des précisions en commentaires 🙂
#
Ressources
Cet article sur un sujet aussi complexe ne s’est pas fait tout seul.
Alors merci aux différents acteurs cités tout au long de cet article.
(Je ne veux pas les re-mentionner pour éviter d’oublier du monde).
Développeur remote, les meilleurs conseils pour apprendre à aimer le télétravail, être efficace, devenir productif et éviter le burn-out.
Progresser en code
41 commentaires
Un grand BRAVO pour cet article vraiment, mais alors VRAI-MENT, complet !
Tu fais le tour du sujet, tu poses les questions et y apportes des réponses tout en précisant humblement, et logiquement, qu’il y a peu être des contre-vérités à encore apporter.
Content aussi d’avoir pu échanger avec toi sur le sujet de l’éco-conception durant tes recherches : ne connaissant pas d’avance le résultat d’aujourd’hui, je te félicite d’avoir poussé autant le curseur des détails !
MERCI de la citation pour le webinaire WebAssoc de décembre 2020 :))
Bonjour,
Merci pour l’article super complet
Que se passe t-il si je lazy-load les images de mon site pour les navigateurs qui ne le supportent pas encore ?
Si tu ne lazy-load pas tes images, ton navigateur va les charger au fur et à mesure qu’il les voit dans la page. Sauf qu’en faisant cela, il va bloquer le rendu de la page, te faisant attendre un peu plus sur ton terminal. Avec http2, on peut multiplexer l’envoie des images, donc ça ira « vite ». Mais si tu en as beaucoup ou si le contenu est long, ça risque de nuire au temps de chargement, qui est directement lié à la consommation énergétique.
Tu consommes ainsi des ressources que tu ne vois pas (en dessous de la ligne de flottaison) et qui pénalise le parcours de l’utilisateur.
Re,
Et est-ce que spécifier l’attribut poster dans la balise video HTML5 fait gagner qqch en termes écologiques ? On sait qu’à défaut, le navigateur affiche la 1re image de la vidéo.
Merci !
Bon, alors pour commencer déjà 👍, gros pouce en l’air. Tu as abordé le sujet sous tellement d’angle que tu as pas laissé un seul angle mort.
J’essaye également de faire de l’éco-conception de plusieurs manières : en minimisant mon site au maximum acceptable sans même que cela impact l’utilisateur et d’autre part en faisant tourner sur du matériel basse consommation (voir presque low-tech à un certain niveau).
Je voulais revenir sur 2 points auxquels j’ai été confronté et auquel j’ai trouvé une solution au top :
– Le problème du pré-chargement en http2, il est vrai que si on lui dit pas que le client a déjà les ressources en cache, il renvoie des données déjà connues du client (un gros problème de conception du protocole, je comprends même qu’il ait pu faire une erreur pareil), mais une simple ligne de code permet de résoudre le problème.(sous nginx pour moi, mais il doit y avoir son équivalent apache)
Cela permet tous simplement d’envoyé les données une première fois avec un cookie tous simple (session=1). Si le client est de retour avec le cookie, on lui pré-charge rien.(il demandera lui-même en cas de ressource manquante.)
– Pour la compression, il y a encore une technique (2 en 1) encore plus efficaces. C’est d’avoir une double version d’un même fichier sur le disque, la version originale et la version déjà compresser en avance. Comme ça le serveur envoie de lui-même la version déjà compressée si elle existe au lieu de la recompresser à chaque fois.
(avec nginx: gzip_static on;)
Et encore, il y a un autre protocole de compression compatible gzip/deflate, qui s’appelle zopfli, qui mets très longtemps à compresser les gros fichiers, mais qui est beaucoup efficaces que juste gzip.
En gros, sur mon serveur, je me balade avec 3 versions d’un même fichier (la non compresser, la compresser avec zopfli compatible gzip, et la version de brotli pour les quelques navigateurs compatibles).
Normalement, si tu gères bien tes processus de compilation (pour la génération statique), cela réduit énormément la bande passante utilisé pour les gros fichiers (genre les vidéos *sifflote*)
Il y a aussi un point que tu as pas évoqué et qui très TRÈS sujet à controverse : c’est le cryptage et la sécurité…
On est rentré dans un monde numérique totalement crypter mais un cryptage presque futile dans certains cas (comme des articles de blog) ou rien n’est personnel et individuelle, et les méta-données suffisent amplement pour savoir ce que vous êtes allés voir sur internet.
Du coup, dans un but d’éco-conception, est-il bien sage de tout sécurisé par TLS qui prend des ressources processeur, au niveau du serveur et du client, qui empêche la mise en cache par des proxy, alors qu’il ne s’agirait que de contenu statique.
Ben non, merci à toi pour cet énorme commentaire 🙂
Pour commencer, ta solution de contournement pour le server push, c’est malin ! Tu n’es pas embêté avec un quelconque cache serveur ? Il faudrait peut-être que ton Varnish (si tu en as un), vary sur la session=1 j’imagine ?
En tout cas c’est une alternative, je vais prendre le temps de la tester !
Concernant la compression, c’est ce que font les fournisseurs de streaming je crois. Niveau espace disque tu t’en sors ? Niveau eco-conception j’imagine que c’est pas trop mal en tout cas.
Si jamais tu as une conf NGINX, j’aimerais bien regarder à quoi elle ressemble.
Enfin sur la sécurité, tu as tellement raison (de mon point de vue). Surtout que le réseau mobile lui n’est pas chiffré, et tout le monde s’en tape. Pour le coup j’ai lu quelques articles là-dessus et je ne sais pas quoi en penser. De notre côté on a même pas le choix, si tu veux bosser avec http2 tu es obligé d’avoir un certificat… Une belle piste à creuser en attendant que quelqu’un trouve p = n * p !
En tout cas je vois mal tout le monde faire machine arrière. Google et d’autres ont poussés dans ce sens alors, qu’est-ce que tu veux faire 🙂
Encore merci pour ton commentaire super intéressant, et au plaisir !
Bonjour,
Très bon article
Je reste sur ma faim niveau outil.
On est à la recherche d’une application capable de calculer en Joule la consommation réelle d’une application
et là… j’avoue.. je trouve rien
Je pense qu’il faudrait une sandbox adapté de type VMWARE à ça.. mais on a rien
une idée ?
Si tu veux mon avis ce n’est que le début, les outils vont arriver. Greenspector devrait je pense, pouvoir donner des équivalents de consommation dans les mois / années (?) à venir.
« je pense que l’utilisation d’ srcdoc est plus appropriée »
Merci !
Si je comprends bien, ce que tu proposes c’est dans le cas de vidéos hébergées chez des tiers à la YouTube ? (sinon je vois pas l’intéret d’ajouter une iframe ?)
Pour les petites vidéos que j’héberge, ce serait plutôt d’utiliser l’attribuer preload avec la valeur none ?
Hey !
J’ai ajouté preload= »none » à mes balises audio et video – on peut vérifier sa prise en compte en regardant le compteur du bandeau de contrôles du média qui affiche 0:00 en dénominateur (0:00 / 0:00) – et loading= »lazy » à certaines de mes balises img (s’agissant des images qui ne sont pas en début de billet) – on peut vérifier sa prise en compte avec l’outil capture de la page complète intégré à Firefox.
Excellent, merci !
« Yes c’est une bonne idée le preload= »none » . Pense tout de même à rajouter une image par-dessus pour décorer un peu. »
J’avais hésité, je suis vraiment dans une optique minimaliste. Au final j’ai décidé de choisir une image pour toutes les vidéos (https://www.flickr.com/photos/daskerst/2256561258/)
Avantage : ça donne une identité à mon site : toutes les vidéos sont présentées derrière un rideau.
Inconvénient : les proportions de l’image unique que j’utilise ne correspondent pas toujours à celles de la vidéo.
Mais ça reste un compromis acceptable, je souhaite vraiment encombrer le moins possible mon espace de stockage en ligne.
A+ !
Je n’ai pas de cache comme Varnish, car j’ai que des sites statiques pour la production. Donc j’ai pas le potentiel problème des variables qui sont gardés dans un cache logiciel.
Pour ce qui est de l’espace disques:
Les fichiers originaux font 467Mo alors que les versions compresser font 569Mo (pour les 2 versions gzip et brotli)
272Mo pour le brotli et 297 Mo pour le gzip.
Après avoir mis mon commentaire, je me suis rendu compte que la totalité des navigateurs moderne supporte brotli (94% des navigateurs utilisé d’après CanIUse.com), ce qui rend la compression gzip un peu obsolètes.
Effectivement si tu manques de place ou que tu as des fichiers vraiment de très grandes taille (mon plus gros fichier fais 250Mo), il peut être problématique de tout compresser en statiques en 2 versions.
Mais rien que la compression des fichiers statique (images, vidéos, css,js) aident grandement la Raspberry pi.
Je travaille uniquement sur des sites 100% statique, donc je n’ai pas de problèmes avec WP ou autres. Mais sinon pour les CMS, il faudrait déjà commencer par compresser l’équivalent du dossier « uploads » pour WordPress.
En vrai c’est 3 fois rien la pré-compression et ça soulage tout le monde.
Pour fournir un fichier nginx, ça va être un peu compliqué, car j’ai plein de règle de sécurité dispersée dans plein de fichier, mais en soi il n’a rien d’extraordinaire (j’ai effacé les informations sensibles): https://paste.chapril.org/?607a27155ea4ffd1#5qH96krtWWRcgxyTdv2S6u3vybbW6kPFJcULKxE3Gp3z
Pour ce qui concerne l’éco-conception, sur nginx il y a ses lignes de code qui sont importantes (mais c’est exactement ce que tu as dis dans ton article):
########## Pour la compression ###########
gzip on;
gzip_static on;
brotli on;
brotli_static on;
########## Pour le cache client ###########
map $sent_http_content_type $expires {
default off;
text/html epoch;
text/css max;
application/javascript max;
~image/ max;
}
expires $expires;
########## Pour l’agrafage de l’OSCP (évite que plusieurs clients requête Let's encrypt) ###########
ssl_stapling on;
ssl_stapling_verify on;
########### La mise en cache des poignées de main TLS pour éviter de redemander de nouveau paramètres de transaction au serveur ###########
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m; # about 40000 sessions
######################
Super retour d’expérience de faire majoritairement du site statique ! Tu utilises quoi comme technos ?
De ce que j’ai vu sur Brotli, ce n’est pas forcément adapté aux petits fichiers pour le traitement à la volée. Il faudrait faire comme toi, pré-compresser les assets en amont, ce qui est plus facilement implémentable avec un site statique, c’est propre.
Merci beaucoup pour le nginx, je ne suis pas forcément à l’aise avec sa config, je suis plus httpd comme tu as du le voir dans l’article.
Très honnêtement faire du static me tente de plus en plus, notamment avec Next et Nuxt pour les applications qui demandent un peu plus d’interactions.
Il faut juste que je regarde de près tout ce bundling JS en plus qui m’effraie un peu…
Un grand merci pour cet article hyper complet ! Il faut du temps pour le décortiquer, mais c’est une mine d’or quand on s’intéresse à l’écoconception. C’est du concret, du vécu, bourré de petites recettes pour faire au mieux.
Franchement, bravo !
Merci beaucoup pour ce partage de tes réflexions et recherches sur l’éco-conception web !
En effet on peut arriver à concevoir des sites éco-responsables qui ne sont pas « moches » et même élégants, et je pense que c’est toujours une question d’équilibre entre sobriété et attractivité pour ne pas tomber dans les extrêmes 🙂
Bonjour, Merci beaucoup pour cet article ! Super intéressant et très bien construit il m’apporte bon nombres d’éléments pour continuer sur une voie toujours plus verte !
Super article BRAVO ! 👏👏👏
Pour ma part je suis toute jeune développeuse web qui a encore tellement à apprendre et j’aurai aimé avoir ton point de vue sur les animations lottie (https://lottiefiles.com/what-is-lottie) qui sont générées via un fichier .json. Leur poids est minime et il me semble que leur utilisation se prête bien à l’éco-conception… Non ?
Salut! Super article hyper complet et intéressant !
Je cherche à faire une présentation courte dans ma société (esn dev web et mobile) sur l’eco conception web, pour présenter à mes collègues le concept et les principaux axes sur lesquels chacun d’entre nous peut faire un effort.
A vrai dire, j’ai l’impression que le plus dur va être, après avoir lu ton article, de retenir les points clés et ne pas lister simplement une armée de points différents.
Est-ce que tu as fait dans ton étude une sorte de hiérarchie, un ordre de priorité des points que tu abordes ? L’idée est de convaincre le plus grand nombre en donnant les leviers les plus significatifs !
Merci encore pour ce travail formidable, ma 1ere lecture sur le sujet et un sacré beau morceau.😄
Alors là comme ça… Dur de donner un point par où commencer. Si tu parles uniquement à des devs il vaut vraiment parler d’UX et d’élimination de code inutile (libs importés et autres trucs overkills).
Le temps de chargement est aussi un bon indicateur.
Enfin mutualiser les serveurs est toujours une bonne chose si tu veux ouvrir sur certaines idées.
Bon courage en tout cas, n’hésite pas à venir partager ta présentation, je serai ravi de la lire.
Alors par contre, dire que « le nucléaire c’est pas terrible », c’est littéralement notre meilleur outil pour produire de l’énergie décarboné, c’est pour ça que l’électricité est autant bas carbone en France… Et citer Greenpeace dans un article sur l’écologie, alors qu’en matière d’énergie et de technologie ils sont tout sauf pertinents, ça laisse pas mal douter du reste de l’article, vous semblez mal informé sur l’écologie.
Un grand BRAVO pour cet article vraiment, mais alors VRAI-MENT, complet !
Tu fais le tour du sujet, tu poses les questions et y apportes des réponses tout en précisant humblement, et logiquement, qu’il y a peu être des contre-vérités à encore apporter.
Content aussi d’avoir pu échanger avec toi sur le sujet de l’éco-conception durant tes recherches : ne connaissant pas d’avance le résultat d’aujourd’hui, je te félicite d’avoir poussé autant le curseur des détails !
MERCI de la citation pour le webinaire WebAssoc de décembre 2020 :))
Toujours un plaisir de lire tes commentaires Christophe.
Merci à toi pour ton travail qui m’a permis d’écrire cet article !
Au plaisir de discuter ensemble 🙂
Très complet bravo !
Merci à toi !
Merci infiniment pour cet article très complet.
Merci à toi !
Super article, merci pour ce beau rassemblement d’infos, vraiment chouette !
Merci beaucoup d’avoir pris le temps de laisser ce joli commentaire 🙂
Bonjour,
Merci pour l’article super complet
Que se passe t-il si je lazy-load les images de mon site pour les navigateurs qui ne le supportent pas encore ?
Hello,
Bonne question !
Si tu ne lazy-load pas tes images, ton navigateur va les charger au fur et à mesure qu’il les voit dans la page. Sauf qu’en faisant cela, il va bloquer le rendu de la page, te faisant attendre un peu plus sur ton terminal. Avec http2, on peut multiplexer l’envoie des images, donc ça ira « vite ». Mais si tu en as beaucoup ou si le contenu est long, ça risque de nuire au temps de chargement, qui est directement lié à la consommation énergétique.
Tu consommes ainsi des ressources que tu ne vois pas (en dessous de la ligne de flottaison) et qui pénalise le parcours de l’utilisateur.
Double pénalité 🙂
Re,
Et est-ce que spécifier l’attribut poster dans la balise video HTML5 fait gagner qqch en termes écologiques ? On sait qu’à défaut, le navigateur affiche la 1re image de la vidéo.
Merci !
Pour le coup je n’en suis pas certain.
Dans tous les cas le navigateur va charger la vidéo, avec ou sans
poster
.Donc dans ce cas-ci tu chargerais une image en plus de la vidéo ?
À vérifier, mais je pense que l’utilisation d’
srcdoc
est plus appropriée 🙂https://developer.mozilla.org/fr/docs/Web/HTML/Element/video
Bon, alors pour commencer déjà 👍, gros pouce en l’air. Tu as abordé le sujet sous tellement d’angle que tu as pas laissé un seul angle mort.
J’essaye également de faire de l’éco-conception de plusieurs manières : en minimisant mon site au maximum acceptable sans même que cela impact l’utilisateur et d’autre part en faisant tourner sur du matériel basse consommation (voir presque low-tech à un certain niveau).
Je voulais revenir sur 2 points auxquels j’ai été confronté et auquel j’ai trouvé une solution au top :
– Le problème du pré-chargement en http2, il est vrai que si on lui dit pas que le client a déjà les ressources en cache, il renvoie des données déjà connues du client (un gros problème de conception du protocole, je comprends même qu’il ait pu faire une erreur pareil), mais une simple ligne de code permet de résoudre le problème.(sous nginx pour moi, mais il doit y avoir son équivalent apache)
add_header Set-Cookie "__Host-session=1; path=/; secure; HttpOnly; SameSite=Strict";
add_header Link $resourcesPush;
map $http_cookie $resourcesPushLLC {
"~*__Host-session=1" "";
default "; as=style; rel=preload, ; as=script; rel=preload, [...]"
}
Cela permet tous simplement d’envoyé les données une première fois avec un cookie tous simple (session=1). Si le client est de retour avec le cookie, on lui pré-charge rien.(il demandera lui-même en cas de ressource manquante.)
– Pour la compression, il y a encore une technique (2 en 1) encore plus efficaces. C’est d’avoir une double version d’un même fichier sur le disque, la version originale et la version déjà compresser en avance. Comme ça le serveur envoie de lui-même la version déjà compressée si elle existe au lieu de la recompresser à chaque fois.
(avec nginx: gzip_static on;)
Et encore, il y a un autre protocole de compression compatible gzip/deflate, qui s’appelle zopfli, qui mets très longtemps à compresser les gros fichiers, mais qui est beaucoup efficaces que juste gzip.
En gros, sur mon serveur, je me balade avec 3 versions d’un même fichier (la non compresser, la compresser avec zopfli compatible gzip, et la version de brotli pour les quelques navigateurs compatibles).
Normalement, si tu gères bien tes processus de compilation (pour la génération statique), cela réduit énormément la bande passante utilisé pour les gros fichiers (genre les vidéos *sifflote*)
Il y a aussi un point que tu as pas évoqué et qui très TRÈS sujet à controverse : c’est le cryptage et la sécurité…
On est rentré dans un monde numérique totalement crypter mais un cryptage presque futile dans certains cas (comme des articles de blog) ou rien n’est personnel et individuelle, et les méta-données suffisent amplement pour savoir ce que vous êtes allés voir sur internet.
Du coup, dans un but d’éco-conception, est-il bien sage de tout sécurisé par TLS qui prend des ressources processeur, au niveau du serveur et du client, qui empêche la mise en cache par des proxy, alors qu’il ne s’agirait que de contenu statique.
Voilà ^^ et encore merci pour cet article !
Hello,
Ben non, merci à toi pour cet énorme commentaire 🙂
Pour commencer, ta solution de contournement pour le server push, c’est malin ! Tu n’es pas embêté avec un quelconque cache serveur ? Il faudrait peut-être que ton Varnish (si tu en as un),
vary
sur la session=1 j’imagine ?En tout cas c’est une alternative, je vais prendre le temps de la tester !
Concernant la compression, c’est ce que font les fournisseurs de streaming je crois. Niveau espace disque tu t’en sors ? Niveau eco-conception j’imagine que c’est pas trop mal en tout cas.
Si jamais tu as une conf NGINX, j’aimerais bien regarder à quoi elle ressemble.
Enfin sur la sécurité, tu as tellement raison (de mon point de vue). Surtout que le réseau mobile lui n’est pas chiffré, et tout le monde s’en tape. Pour le coup j’ai lu quelques articles là-dessus et je ne sais pas quoi en penser. De notre côté on a même pas le choix, si tu veux bosser avec
http2
tu es obligé d’avoir un certificat… Une belle piste à creuser en attendant que quelqu’un trouvep = n * p
!En tout cas je vois mal tout le monde faire machine arrière. Google et d’autres ont poussés dans ce sens alors, qu’est-ce que tu veux faire 🙂
Encore merci pour ton commentaire super intéressant, et au plaisir !
Bonjour,
Très bon article
Je reste sur ma faim niveau outil.
On est à la recherche d’une application capable de calculer en Joule la consommation réelle d’une application
et là… j’avoue.. je trouve rien
Je pense qu’il faudrait une sandbox adapté de type VMWARE à ça.. mais on a rien
une idée ?
Bonjour Sébastien !
Merci pour ton message.
Si tu veux mon avis ce n’est que le début, les outils vont arriver. Greenspector devrait je pense, pouvoir donner des équivalents de consommation dans les mois / années (?) à venir.
Est-ce que tu connais Argos ? https://marmelab.com/blog/2020/11/26/argos-sustainable-development.html
Je pense que c’est quelque chose qui pourrait te convenir.
Je n’ai pas eu le temps de le tester, mais c’est dans ma todo ! Si jamais tu l’utilises je serais ravi d’avoir ton avis 🙂
Au plaisir
« je pense que l’utilisation d’ srcdoc est plus appropriée »
Merci !
Si je comprends bien, ce que tu proposes c’est dans le cas de vidéos hébergées chez des tiers à la YouTube ? (sinon je vois pas l’intéret d’ajouter une iframe ?)
Pour les petites vidéos que j’héberge, ce serait plutôt d’utiliser l’attribuer preload avec la valeur none ?
Très bon article, vraiment intéressant et qui amène à se poser de réelles bonnes questions et habitudes. Merci.
Merci à toi pour ton commentaire !
Hey !
J’ai ajouté preload= »none » à mes balises audio et video – on peut vérifier sa prise en compte en regardant le compteur du bandeau de contrôles du média qui affiche 0:00 en dénominateur (0:00 / 0:00) – et loading= »lazy » à certaines de mes balises img (s’agissant des images qui ne sont pas en début de billet) – on peut vérifier sa prise en compte avec l’outil capture de la page complète intégré à Firefox.
Excellent, merci !
Hello !
Yes c’est une bonne idée le
preload="none"
. Pense tout de même à rajouter une image par-dessus pour décorer un peu.Sinon c’est pas très beau et on a même l’impression que la vidéo bug 🙂
C’est cool en tout cas que tu aies commencé à changer ton site, belle démarche !
Merci pour ton retour.
« Yes c’est une bonne idée le preload= »none » . Pense tout de même à rajouter une image par-dessus pour décorer un peu. »
J’avais hésité, je suis vraiment dans une optique minimaliste. Au final j’ai décidé de choisir une image pour toutes les vidéos (https://www.flickr.com/photos/daskerst/2256561258/)
Avantage : ça donne une identité à mon site : toutes les vidéos sont présentées derrière un rideau.
Inconvénient : les proportions de l’image unique que j’utilise ne correspondent pas toujours à celles de la vidéo.
Mais ça reste un compromis acceptable, je souhaite vraiment encombrer le moins possible mon espace de stockage en ligne.
A+ !
Tu as bien raison, c’est sobre à souhait et c’est propre, du Green UX quoi 🙂
Je n’ai pas de cache comme Varnish, car j’ai que des sites statiques pour la production. Donc j’ai pas le potentiel problème des variables qui sont gardés dans un cache logiciel.
Pour ce qui est de l’espace disques:
Les fichiers originaux font 467Mo alors que les versions compresser font 569Mo (pour les 2 versions gzip et brotli)
272Mo pour le brotli et 297 Mo pour le gzip.
Après avoir mis mon commentaire, je me suis rendu compte que la totalité des navigateurs moderne supporte brotli (94% des navigateurs utilisé d’après CanIUse.com), ce qui rend la compression gzip un peu obsolètes.
Effectivement si tu manques de place ou que tu as des fichiers vraiment de très grandes taille (mon plus gros fichier fais 250Mo), il peut être problématique de tout compresser en statiques en 2 versions.
Mais rien que la compression des fichiers statique (images, vidéos, css,js) aident grandement la Raspberry pi.
Je travaille uniquement sur des sites 100% statique, donc je n’ai pas de problèmes avec WP ou autres. Mais sinon pour les CMS, il faudrait déjà commencer par compresser l’équivalent du dossier « uploads » pour WordPress.
En vrai c’est 3 fois rien la pré-compression et ça soulage tout le monde.
Pour fournir un fichier nginx, ça va être un peu compliqué, car j’ai plein de règle de sécurité dispersée dans plein de fichier, mais en soi il n’a rien d’extraordinaire (j’ai effacé les informations sensibles):
https://paste.chapril.org/?607a27155ea4ffd1#5qH96krtWWRcgxyTdv2S6u3vybbW6kPFJcULKxE3Gp3z
Pour ce qui concerne l’éco-conception, sur nginx il y a ses lignes de code qui sont importantes (mais c’est exactement ce que tu as dis dans ton article):
########## Pour la compression ###########
gzip on;
gzip_static on;
brotli on;
brotli_static on;
########## Pour le cache client ###########
map $sent_http_content_type $expires {
default off;
text/html epoch;
text/css max;
application/javascript max;
~image/ max;
}
expires $expires;
########## Pour l’agrafage de l’OSCP (évite que plusieurs clients requête Let's encrypt) ###########
ssl_stapling on;
ssl_stapling_verify on;
########### La mise en cache des poignées de main TLS pour éviter de redemander de nouveau paramètres de transaction au serveur ###########
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m; # about 40000 sessions
######################
Hey Clément, merci d’être revenu dans le coin 🙂
Super retour d’expérience de faire majoritairement du site statique ! Tu utilises quoi comme technos ?
De ce que j’ai vu sur Brotli, ce n’est pas forcément adapté aux petits fichiers pour le traitement à la volée. Il faudrait faire comme toi, pré-compresser les assets en amont, ce qui est plus facilement implémentable avec un site statique, c’est propre.
Merci beaucoup pour le nginx, je ne suis pas forcément à l’aise avec sa config, je suis plus httpd comme tu as du le voir dans l’article.
Très honnêtement faire du static me tente de plus en plus, notamment avec Next et Nuxt pour les applications qui demandent un peu plus d’interactions.
Il faut juste que je regarde de près tout ce bundling JS en plus qui m’effraie un peu…
Au plaisir,
Alex
Un grand merci pour cet article hyper complet ! Il faut du temps pour le décortiquer, mais c’est une mine d’or quand on s’intéresse à l’écoconception. C’est du concret, du vécu, bourré de petites recettes pour faire au mieux.
Franchement, bravo !
Merci beaucoup pour ce joli commentaire !
Au plaisir de discuter ensemble 🙂
Merci beaucoup pour ce partage de tes réflexions et recherches sur l’éco-conception web !
En effet on peut arriver à concevoir des sites éco-responsables qui ne sont pas « moches » et même élégants, et je pense que c’est toujours une question d’équilibre entre sobriété et attractivité pour ne pas tomber dans les extrêmes 🙂
Je te rejoins totalement, la sobriété n’oblige en rien le manque d’attractivité !
Bonjour, Merci beaucoup pour cet article ! Super intéressant et très bien construit il m’apporte bon nombres d’éléments pour continuer sur une voie toujours plus verte !
Avec plaisir, merci beaucoup Romain pour ton commentaire !
Super article BRAVO ! 👏👏👏
Pour ma part je suis toute jeune développeuse web qui a encore tellement à apprendre et j’aurai aimé avoir ton point de vue sur les animations lottie (https://lottiefiles.com/what-is-lottie) qui sont générées via un fichier .json. Leur poids est minime et il me semble que leur utilisation se prête bien à l’éco-conception… Non ?
Salut Delphine,
Merci pour ton message.
Là comme ça, ça génère des SVG animés… Si tu regardes dans le navigateur, tu dois que le DOM est sens cesse re-render…
Alors je ne sais pas ce que ça implique en termes de consommation, mais la différence avec du SVG non animé doit être palpable.
Dans un but purement ecoconception il vaut mieux éviter les « extras » 🙂
Salut! Super article hyper complet et intéressant !
Je cherche à faire une présentation courte dans ma société (esn dev web et mobile) sur l’eco conception web, pour présenter à mes collègues le concept et les principaux axes sur lesquels chacun d’entre nous peut faire un effort.
A vrai dire, j’ai l’impression que le plus dur va être, après avoir lu ton article, de retenir les points clés et ne pas lister simplement une armée de points différents.
Est-ce que tu as fait dans ton étude une sorte de hiérarchie, un ordre de priorité des points que tu abordes ? L’idée est de convaincre le plus grand nombre en donnant les leviers les plus significatifs !
Merci encore pour ce travail formidable, ma 1ere lecture sur le sujet et un sacré beau morceau.😄
Hey, merci beaucoup Adelin !
Alors là comme ça… Dur de donner un point par où commencer. Si tu parles uniquement à des devs il vaut vraiment parler d’UX et d’élimination de code inutile (libs importés et autres trucs overkills).
Le temps de chargement est aussi un bon indicateur.
Enfin mutualiser les serveurs est toujours une bonne chose si tu veux ouvrir sur certaines idées.
Bon courage en tout cas, n’hésite pas à venir partager ta présentation, je serai ravi de la lire.
C’est une mine d’or bravo pour le travail, juste c’est assez difficile d’utiliser une seule page…
Merci pour ton message ! Tu as raison c’est assez difficile sur une seule page, on cherche des solutions 🙂
Excellent article me permettant de découvrir l’éco-conception.
Merci Frederic 🙏
Alors par contre, dire que « le nucléaire c’est pas terrible », c’est littéralement notre meilleur outil pour produire de l’énergie décarboné, c’est pour ça que l’électricité est autant bas carbone en France… Et citer Greenpeace dans un article sur l’écologie, alors qu’en matière d’énergie et de technologie ils sont tout sauf pertinents, ça laisse pas mal douter du reste de l’article, vous semblez mal informé sur l’écologie.
Bonjour
Bien sûr que le nucléaire n’est pas terrible, rejeter des déchets radioactifs, c’est quand même pas la panacée.
Pour moi c’est la meilleure source d’énergie qu’on ait actuellement, faute de mieux, c’est loin d’être parfait.
Il m’a fait sourire ton commentaire, merci pour ton temps 🙂