Notes précises sur un web plus léger

Le poids caché des polices web

Une identité typographique se paie en octets, et la facture est souvent démesurée : quatre graisses d'une famille classique en WOFF2, c'est facilement 400 Ko, soit davantage que le HTML, le CSS et le JavaScript réunis d'un site sobre. Trois leviers ramènent ce poste à la raison, sans renoncer au caractère.

La police variable d'abord. Une seule ressource couvre tout l'axe des graisses : là où quatre fichiers statiques dépassent 350 Ko, une variable sous-ensemble latin en pèse quelques dizaines. À charge égale, l'espace de design s'élargit, du plus fin au plus gras, sans multiplier les requêtes.

Le sous-ensemble ensuite. Un site français n'a pas besoin des glyphes cyrilliques, grecs ou vietnamiens. Le découpage unicode-range (que next/font applique automatiquement à la construction) évite de charger ce qui ne sera jamais affiché. Gain courant : 60 à 80 % du poids initial.

La discipline enfin. Deux à trois familles suffisent à une hiérarchie complète : une voix pour les titres, une pour le texte, une monospace pour les données chiffrées. Chaque graisse supplémentaire doit justifier sa présence, et font-display: swap garantit que le texte reste lisible pendant le chargement : la typographie est un raffinement, jamais un préalable à la lecture.

Sur ce site, tout le poste typographique tient dans une seule superfamille auto-hébergée, IBM Plex : la Sans, variable, porte les titres comme le texte ; la Mono cadence les données chiffrées. Le tout servi depuis notre propre domaine et mis en cache pour toute la durée de la visite, sans aucune requête vers un service tiers : une police ne devrait jamais être un traceur.

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.