Notes précises sur un web plus léger

Images : le format ne suffit pas

Les images représentent environ la moitié du poids du web. Convertir en AVIF ou en WebP est devenu un réflexe, et c'est un bon réflexe : à qualité perçue égale, AVIF économise couramment 40 à 50 % par rapport au JPEG. Mais le format n'est que le troisième levier par ordre d'impact.

Le premier levier est l'existence même de l'image. La question « cette image apporte-t-elle une information ? » supprime plus d'octets que n'importe quel encodeur. Une décoration qui peut être un dégradé CSS ou un SVG de 2 Ko n'a pas à être une photo de 200 Ko.

Le deuxième est la dimension servie. Servir 2 560 pixels de large à un écran de téléphone est un gaspillage pur : srcset et sizes alignent la résolution transférée sur la résolution affichée. Nos mesures sur des sites clients montrent des économies de 60 à 85 % sur ce seul poste, avant toute conversion de format.

Ensuite seulement viennent le format, la compression (qualité 75 à 82, rarement plus) et le chargement différé : loading="lazy" sur tout ce qui est sous la ligne de flottaison, jamais sur l'image principale, et des attributs width et height systématiques pour ne rien faire sauter à l'écran.

Une galerie de trente photos n'est pas un problème de format : c'est un choix éditorial qui engage 1 à 2 Mo par visite. L'éco-conception commence au moment du choix, pas au moment de l'encodage.

Le JavaScript qu'on ne voit pas

Le JavaScript est l'octet le plus cher du web : téléchargé, puis analysé, compilé et exécuté, il mobilise le processeur du visiteur là où une image ne mobilise que le réseau. À poids égal, son coût énergétique réel est plusieurs fois supérieur, surtout sur les appareils modestes, précisément ceux qui durent.

Le premier suspect est le script tiers. Analytics, pixels publicitaires, gestionnaires de consentement, widgets de chat : le poids médian des scripts tiers dépasse celui du code applicatif sur une grande partie du web commercial. Chacun ouvre des connexions, exécute du code opaque et échappe à votre budget de performance. L'alternative existe presque toujours : mesure d'audience côté serveur, boutons de partage en liens simples, chat remplacé par une adresse qui répond.

Le deuxième est l'hydratation par défaut. Les frameworks modernes rendent le HTML côté serveur puis rejouent l'application entière côté client, même pour une page qui n'a qu'un menu à ouvrir. Les architectures en îlots inversent la logique : du HTML d'abord, du JavaScript uniquement là où l'interaction l'exige. Un menu mobile s'écrit avec un élément dialog natif, un accordéon avec details et summary : zéro script, accessibilité incluse.

Le troisième est le code mort. Un audit de couverture (l'onglet Coverage des outils de développement) révèle régulièrement 40 à 60 % de code jamais exécuté. Le supprimer ne dégrade rien, par définition.

Notre règle d'atelier : chaque kilo-octet de JavaScript doit acheter une interaction que HTML et CSS ne savent pas offrir. Le reste est de la dette énergétique.

DOM profond, planète lourde

Le poids transféré ne dit pas tout : une page peut être légère sur le réseau et coûteuse à l'écran. La complexité du DOM, le nombre et l'imbrication des éléments HTML, détermine la mémoire consommée, le temps de calcul des styles et le coût de chaque repaint. C'est pourquoi elle pèse 30 % dans notre note, comme dans les référentiels GreenIT.

Les seuils que nous utilisons sont simples : moins de 200 éléments, exemplaire ; au-delà de 700, pénalisant. Or les gabarits générés (constructeurs de pages, frameworks CSS utilisés sans retenue) produisent couramment des pages de 1 500 à 3 000 éléments, où chaque carte est une poupée russe de div sans rôle.

La cure est d'abord sémantique. Un élément mérite d'exister s'il porte du sens (article, nav, table) ou une contrainte de mise en page réelle. Les enveloppes de commodité, wrapper de wrapper, div de marge, span de couleur, se remplacent par des propriétés CSS sur l'élément qui existe déjà : gap plutôt que colonnes vides, pseudo-éléments plutôt que balises décoratives, grilles plutôt qu'échafaudages.

Le bénéfice dépasse l'écologie : un DOM court est plus rapide à lire pour les technologies d'assistance, plus stable pour les tests, plus simple à maintenir. Sur ce site, la page la plus dense reste sous 450 éléments, rapport d'analyse compris. La structure la plus durable est celle qu'on n'a pas construite.

Cache et CDN : servir sans recalculer

L'octet le plus sobre est celui qu'on ne transfère pas ; le calcul le plus sobre, celui qu'on ne refait pas. Entre les deux se trouve la discipline la moins spectaculaire et la plus rentable de l'éco-conception : la politique de cache.

Pour les ressources fingerprintées (CSS, JavaScript, polices dont le nom change à chaque version), la réponse tient en une ligne : Cache-Control: public, max-age=31536000, immutable. Le navigateur ne redemandera jamais un fichier qu'il possède. Toute autre valeur sur ces fichiers est une erreur de configuration.

Pour les pages HTML, le rendu statique à la construction transforme chaque visite en simple lecture de fichier : zéro exécution serveur par requête. Quand le contenu doit vivre, s-maxage avec stale-while-revalidate sur le CDN offre la fraîcheur perçue sans recalcul systématique : le visiteur reçoit la copie du bord, la revalidation se fait en coulisse.

Pour les contenus générés coûteux, la règle vaut double. Notre badge d'éco-score est mis en cache 24 heures sur le CDN : mille affichages ne déclenchent qu'une seule analyse du site mesuré. Le certificat reste vivant, la charge reste constante.

Ajoutez la compression moderne (Brotli plutôt que gzip : 15 à 20 % de mieux sur le texte) et les en-têtes conditionnels (ETag, réponses 304), et une part substantielle de votre trafic cesse simplement d'exister. C'est la forme la plus pure de sobriété : l'infrastructure qui ne travaille que lorsqu'elle a quelque chose de neuf à dire.