Astro et éco-conception : de 0,45 g à 0,01 g de CO2 par page

En mars 2022, j’avais mesuré ce site avec le Website Carbon Calculator et publié le résultat sans le maquiller : 0,45 g de CO2 par page vue, plus propre que 72 % du web. C’était honorable pour un WordPress, et j’en étais plutôt content.
Je viens de refaire la mesure, le 2 août 2026, sur le même domaine — devenu entre-temps un site Astro. 0,01 g par page, note A+, plus propre que 98 % des pages testées. Quarante-cinq fois moins de carbone pour le même contenu. Voilà ce qu’il y a derrière ce chiffre, ce qu’il vaut vraiment, et ce qu’il ne dit pas.
Le même site, quatre ans plus tard
En 2022, l’article que j’avais écrit posait le calcul suivant : pour 10 000 pages vues par mois, ce site représentait environ 45 kg de CO2 par an. Avec le chiffre d’aujourd’hui, le même trafic tombe à un peu plus d’un kilo par an. On ne parle plus d’une optimisation, on parle d’un changement d’ordre de grandeur.

Le second point du rapport compte autant que le premier : la page est reconnue comme servie par de l’énergie durable. J’y reviens plus bas, parce que ce n’est pas mon code qui le mérite.
Ce que mesure vraiment un calculateur de carbone
Avant de se réjouir d’une note, il faut savoir sur quoi elle repose. Website Carbon n’inspecte pas votre serveur et ne compte pas vos requêtes SQL. Il applique un modèle — le Sustainable Web Design model — à une donnée principale : le nombre d’octets qu’une page fait transiter. Ces octets sont convertis en énergie (transport réseau, centre de données, terminal du visiteur), l’énergie en carbone selon l’intensité moyenne du réseau électrique, avec une hypothèse sur la part de visiteurs récurrents dont le navigateur a déjà tout en cache. Enfin, l’outil vérifie l’hébergeur dans l’annuaire de la Green Web Foundation pour décider s’il affiche « énergie durable ».
Autrement dit : le poids transféré est la variable, tout le reste est un coefficient. C’est une approximation assumée, et elle a ses angles morts — elle mesure une URL, pas votre site ; elle ignore ce que coûte la fabrication du site, les vidéos que le visiteur ne lance pas, ou l’appel d’API que votre formulaire déclenche après coup. L’EcoIndex de GreenIT prend le problème autrement, en pondérant aussi la complexité du DOM et le nombre de requêtes : deux modèles, deux résultats, aucun des deux n’est une facture d’électricité.
Ça reste utile, à condition de lire la note pour ce qu’elle est : un indicateur de sobriété du transfert. Et sur ce terrain précis, l’architecture d’un site fait presque tout.
Pourquoi une architecture statique fait chuter le chiffre
Un WordPress qui répond à une visite exécute du PHP, interroge une base de données, assemble la page à travers un thème et une pile d’extensions qui injectent chacune leur CSS et leur JavaScript. Astro génère tout à l’avance : au moment du build, pas au moment de la visite. Ce qui part vers le visiteur, c’est du HTML et du CSS déjà prêts, servis depuis un CDN.
La différence de poids ne vient pas d’un CSS mieux écrit. Elle vient d’un poste entier qui disparaît. J’ai lancé la recherche sur le dossier de build de ce site, par curiosité en écrivant cet article :
$ find dist -name "*.js" | wc -l
0
Aucun fichier JavaScript dans tout le site. Pas un seul .js à télécharger, sur l’ensemble des pages. Le peu de comportement dont le site a besoin — le filtre par catégorie du blog, par exemple — tient en quelques lignes écrites directement dans le HTML de la page concernée. Astro n’envoie aucun JavaScript par défaut : il faut le demander explicitement, composant par composant.
C’est ce qui pèse le plus lourd dans un bilan carbone de page, et pour une raison qu’on oublie souvent : un kilo-octet de JavaScript ne coûte pas seulement son transfert. Il doit être analysé et exécuté par le processeur du téléphone du visiteur — c’est le seul type de fichier qui consomme de l’énergie deux fois. La page d’accueil de ce site part en environ 11 Ko compressés, feuille de style comprise (le CSS est inliné dans le HTML, il n’y a même pas de requête pour aller le chercher). C’est le poids d’une seule photo mal redimensionnée.
Cette légèreté n’est pas propre à Astro, d’ailleurs. C’est exactement ce qui m’avait attiré vers Oxygen Builder en 2020 : sortir du thème et de ses couches d’abstraction suffisait déjà à décrocher des A et des B sur ce même calculateur. Astro pousse simplement la logique à son terme, en supprimant le serveur applicatif de l’équation.
Le poste que personne ne regarde : les polices
Voilà l’endroit où le discours de l’éco-conception devient inconfortable, et c’est justement pour ça qu’il vaut la peine d’être dit.
Ce site précharge quatre graisses de police, celles qui apparaissent en haut de page. Elles pèsent 108 Ko à elles seules — dix fois le poids de la page HTML qu’elles habillent. Toute l’ingénierie du contenu ne fait pas le poids face à quatre fichiers de typographie.
Ces 108 Ko sont déjà le résultat d’un travail : chaque .woff2 est sous-ensemblé, c’est-à-dire élagué des glyphes que le site n’utilisera jamais, ce qui divise à peu près par deux les fichiers d’origine. Sans ce passage, on serait au double. La leçon est générale et vaut pour n’importe quel site, quel que soit le CMS : le poids d’une page, ce n’est presque jamais le texte, c’est ce qui l’accompagne. Les polices, les images non redimensionnées, les scripts tiers — un widget d’avis, une carte, un pixel publicitaire — pèsent chacun plus lourd que tout le contenu réunis.
Et c’est aussi pour ça que le chiffre de 0,01 g doit être lu avec sa nuance : le modèle suppose qu’une bonne partie des visiteurs reviennent avec les polices déjà en cache. La toute première visite d’un internaute coûte, elle, une centaine de kilo-octets de plus.
L’hébergement compte autant que le code
Le « énergie durable » de la capture n’est pas un mérite de développeur. Il vient du fait que ce site est déployé sur Cloudflare Pages, et que Cloudflare figure dans l’annuaire des hébergeurs verts consulté par l’outil. Le même code, servi depuis un mutualisé alimenté par un mix électrique carboné, donnerait un chiffre nettement moins flatteur pour un HTML rigoureusement identique.
Ça mérite d’être dit clairement, parce que c’est le levier le plus rapide de tout le domaine : changer d’hébergeur améliore un bilan carbone en une après-midi, là où alléger un site demande des semaines. Les deux se cumulent, évidemment — et c’est la combinaison des deux qui fait passer de A à A+.
Ce que l’éco-conception ne règle pas
Je termine par où j’ai commencé en 2022, avec quatre ans de recul en plus.
D’abord, un aveu que j’ai déjà fait ailleurs : les pages que j’avais écrites à l’époque sur l’éco-conception n’ont jamais attiré grand monde. La performance carbone est un excellent argument technique ; ce n’est pas ce qui fait décrocher le téléphone à un dirigeant. Je continue pourtant d’y tenir, parce que la note A+ n’est jamais l’objectif — elle est le symptôme d’un site bien construit. On ne l’obtient pas en la visant : on l’obtient en servant du HTML léger depuis un bon hébergeur, ce qui donne accessoirement un site rapide, robuste et pas cher à héberger. Le carbone est la conséquence, pas la cause.
Ensuite, une note ne vaut que pour la page testée. Un site A+ sur son accueil et catastrophique sur ses fiches produit — parce qu’elles chargent six images de 2 Mo et un script de chat en direct — reste un site lourd. Si votre sujet est la lenteur plus que le carbone, le diagnostic commence ailleurs, et il commence toujours par mesurer avant de changer quoi que ce soit.
Enfin, et c’est la limite honnête de cet exercice : le statique n’est pas la réponse à tout. Un site dont trois personnes modifient le contenu chaque semaine a besoin d’un back-office, et ce que WordPress fait très bien, Astro ne le remplace pas — au mieux, les deux se combinent, WordPress en coulisses pour la rédaction, Astro en façade pour le visiteur.
Si vous voulez savoir ce que pèse réellement votre site, et surtout si le chantier en vaut la peine dans votre cas, la mesure prend deux minutes et la conversation qui suit est le genre d’audit que je mène. On regarde d’abord ce qui pèse, avant de parler de ce qu’il faut refaire.