Sites en formation 🚧
Je travaille en freelance comme ingénieur pédagogique pour des formations de l'enseignement supérieur dans le domaine du design numérique et de la communication. Nos étudiant·es ne sont pas des développeur·ses, mais doivent savoir créer des sites. Et sans surprise, c'est à WordPress que nous les formons.
À l'heure des jurys, défilent alors sous nos yeux des sites composés de quelques pages et d'un blog, souvent très jolis, bien écrits, mais embarquant un thème plein de Javascript sophistiqué ainsi qu'une vingtaine d'extensions au bas mot. Effectivement, la sobriété de conception ne fait pas partie des objectifs fixés. Au contraire : effet waouh bienvenu !
Par conséquent, je m'interroge : quel est l'impact environnemental, et notamment énergétique, des méthodes de création de site que nous apprenons à nos jeunes ?
Comparons ce qui n'est pas comparable
À quoi reconnaît-on qu'un site web est écoconçu ? Je lis et j'entends beaucoup de choses à ce sujet, mais plus je sonde le problème, plus la réponse me semble complexe. Par exemple : mon a priori sur la lourdeur de WordPress mérite d'être fortement nuancé.
Il se trouve qu'entre fin 2022 et fin 2024, j'ai créé quatre sites personnels en utilisant quatre technologies différentes. Bien que ces sites soient assez peu comparables, j'ai quand même jugé bon de les comparer 😅
Aux vallées du puy Mary
Dans mes temps de loisirs, je crée des itinéraires de slow-rando culturelle dans les vallées du puy Mary, et j'ai le souhait de les partager. Le site s'appuie à dessein sur les solutions enseignées à mes étudiants, afin de savoir un peu mieux de quoi je parle ! En revanche, aucune recherche de sobriété dans la conception du site...
Techno : WordPress / Astra / Elementor
Hébergement : OVH Perso option CDN
Taille core + plugins : 193 Mo + MySQL
Jeux de mots 15
Dans le prolongement de mon site de rando, j'ai publié 3 livres avec l'association Jeux de mots 15. Un jour, pour un dossier de partenariat, il fallait fournir l'adresse d'un site. Nous n'en avions pas : dans la soirée, j'ai téléchargé un template Bootstrap gratuit, et me suis contenté de changer texte pour texte et image pour image. Au final, cela fait beaucoup de (vieux) Javascript pour pas grand chose...
URL : jeux-de-mots.org
Techno : Statique / Bootstrap / JQuery
Hébergement : OVH Start100M (gratuit)
Taille core + plugins : 0
Blog rural
Toujours dans le prolongement de mon site de rando, je voulais apporter des réflexions plus personnelles et plus engagées concernant ma démarche. Défendant une approche radicalement minimaliste du voyage, je trouvais plus cohérent de construire ce blog avec une solution low-tech. J'ai choisi le CMS flat-file Grav.
CMS & CO2
D'une part, l'utilisation de Grav m'a donné envie de tester d'autres alternatives à WordPress. D'autre part, j'ai pris conscience du grand flou qui entoure la notion d'écoconception web. Compresser les images et bannir les animations CSS n'offre à mes yeux qu'une vision très restreinte du sujet. J'ai donc entrepris de sonder le problème, et comme à mon habitude, de partager publiquement mes réflexions...
URL : cms-et-co2.fr
Techno : Kirby
Hébergement : OVH Start100M (gratuit)
Taille core + plugins : 6 Mo
Le test
Scoring écoconception et performance
Pour ce test, il m'a semblé suffisant de prendre pour échantillon les pages d'accueil de chaque site. Et pour commencer, voici les résultats obtenus par ces pages auprès des services de scoring les plus courants :
Écoindex
🏆CMS & CO2 (A 86%)
🥈Blog rural (A 82%)
🥉Jeux de mots (C 67%)
😞Aux vallées (D 51%)
Website Carbon
🏆CMS & CO2 (A+ 95%)
🥈Jeux de mots (B 81%)
🥉Blog rural (B 79%)
😞Aux vallées (C 62%)
Pingdom Tools
🏆Blog rural (A 92%)
🥈CMS & CO2 (B 84%)
🥉Jeux de mots (B 83%)
😞Aux vallées (C 75%)
PageSpeed
🏆CMS & CO2 (100%)
🥈Blog rural (91%)
🥉Jeux de mots (87 %)
😞Aux vallées (76%)
Effort de chargement et d'affichage
Ces scores, finalement, dépendent assez peu de la plateforme utilisée. Or je suis très curieux de mesurer les efforts exigés par chaque technologie, y compris côté serveur. J'ai donc poussé l'analyse un peu plus loin à l'aide de l'outil GTMetrix 👀
Ce qui m'intéresse, c'est ce qu'il se passe au tout départ de la requête http. Je cherche à surveiller, en particulier, le temps que met le serveur à préparer la page. Car je postule que l'effort demandé au serveur est proportionnel à ce délai 🤔 C'est pourquoi je me suis concentré sur le service du tout premier fichier, c'est-à-dire le fichier HTML.
(d'après Velvet CC-BY-SA 4.0 Wikimedia Commons)
Pour mieux comprendre les statistiques qui suivent, voici la signification des acronymes utilisés :
- TTFB (Time To First Byte) = Temps écoulé entre l'envoi de la requête et la réception du premier octet.
- TTFF (Time To First File) = Temps écoulé entre l'envoi de la requête et le téléchargement complet du premier fichier.
- FCP (First Content Paint) = Temps écoulé entre l'envoi de la requête et l'affichage du premier élément.
- RAM = Pic d'utilisation de la RAM pour effectuer le rendering de la page (d'après GTMetrix).
La colonne FCP-TTFF mesure donc le temps écoulé entre la réception complète du fichier HTML et l'affichage du premier élément. Cela donne une idée de l'effort fourni par le navigateur pour "construire" la page 🛠
Quant au site WordPress Aux vallées du puy Mary, il a été testé dans deux configurations distinctes :
- Aux vallées+cache = Extension WP Fastest Cache activée.
- Aux vallées = Extension WP Fastest Cache désactivée .
TTFB
🏆Aux vallées+cache (60 ms)
🥈Jeux de mots (61 ms)
🥉CMS & CO2 (145 ms)
😞Blog rural (195 ms)
😭Aux vallées (991 ms)
FCP
🏆Jeux de mots (301 ms)
🥈CMS & CO2 (343 ms)
🥉Aux vallées+cache (356 ms)
😞Blog rural (442 ms)
😭Aux vallées (1344 ms)
FCP-TTFF
🏆CMS & CO2 (196 ms)
🥈Jeux de mots (236 ms)
🥉Blog rural (246 ms)
😞Aux vallées+cache (279 ms)
😞Aux vallées (321 ms)
RAM
🏆CMS & CO2 (230 Mo)
🥈Blog rural (250 Mo)
🥉Jeux de mots (290 Mo)
😞Aux vallées (300 Mo)
😞Aux vallées+cache (320 Mo)
Enfin, j'ai codé un script PHP qui effectue ses propres mesures de temps de chargement et de volumes transférés. Cela rend possible le test des sites hébergés localement, en s'affranchissant des délais du réseau. Mais dans la pratique, les disparités entre XAMPP et les serveurs OVH brouillent un peu les pistes 😒
Voici tout de même, en complément d'information, le volume des fichiers HTML impliqués, et les TTFF moyens mesurés sur localhost par mon petit script maison :
Taille HTML
🏆CMS & CO2 (17 ko)
🥈Blog rural (22 ko)
🥉Jeux de mots (38 ko)
😞Aux vallées+cache (212 ko)
😞Aux vallées (212 ko)
TTFF
🏆Jeux de mots (359 ms)
🥈Aux vallées+cache (417 ms)
🥉CMS & CO2 (518 ms)
😞Blog rural (732 ms)
😭Aux vallées (1920 ms)
Et ça dit quoi ?
Sur la méthode
La méthode reste très artisanale, et j'ai conscience que les biais sont nombreux. D'ailleurs, je suis preneur de tout conseil pour effectuer des mesures plus rigoureuses. Le trafic sur ces quatre sites n'est pas suffisant pour faire parler des solutions comme Scaphandre par exemple.
Parmi les biais auxquels je pense :
- Il y a un temps incompressible pour établir la connexion http (DNS lookup, handshake SSL...) non pris en compte.
- Le serveur web étant mutualisé, on ignore sa charge au moment des tests.
- Les ressources CPU/RAM allouées aux hébergements OVH dépendent-elles de l'offre souscrite ? Le comparatif affiché sur le site d'OVH n'en fait aucune mention.
- L'état du réseau demeure également une inconnue.
De par leurs conceptions très différentes, les fichiers HTML des quatre pages d'accueil ont des tailles qui varient d'un facteur 1 à 10, mais l'impact s'avère négligeable. Avec GTMetrix comme avec mon script personnel, le calcul TTFF-TTFB oscille entre 1 et 2 ms quelles que soient les pages. Par exemple, au débit descendant de ma box (900 Mbps), il faut 1,8 ms pour télécharger les 212 ko mesurés pour le site Aux vallées.
Enfin, c'est la version 8.2 de PHP qui "tourne" sur les quatre sites, donc pas de biais de ce côté-là 👌
Sur les résultats
Outils de caching
Le plus remarquable, à mes yeux, c'est l'efficacité impressionnante du plugin de cache WordPress. Grâce à la mise en cache, la page d'accueil du site Aux vallées est servie à peu près à l'identique d'une page statique. J'ai fait le test avec d'autres pages plus volumineuses, et c'est la même chose, à la milliseconde près.
Si Grav est mal placé dans le classement, cela vient probablement du système de cache. À vrai dire, il est tout à fait possible que je sois passé à côté d'un réglage concernant ce cache, car je n'en ai lu que des compliments par ailleurs. Peut-être cette mauvaise place est-elle injuste pour Grav, à cause d'un oubli de ma part 😕
La prégnance du cache dans l'efficacité du service invite à y prêter la plus grande attention. Kirby possède un système de caching natif, avec des extensions complémentaires au catalogue. Il existe même des possibilités de génération de site statique : Staticache et Static Site Generator, très populaires dans la communauté Kirby.
On en revient sempiternellement (et logiquement) à la même conclusion : mieux vaut tendre au maximum vers des solutions statiques.
Outils de scoring
Chaque score s'appuie sur des critères très différents, ce qui explique des classements assez variables. Il y a toujours des informations utiles à retenir de chaque évaluation, mais il convient tout de même de lire ces résultats avec beaucoup de recul.
Les trois critères de l'Écoindex ont l'avantage de la limpidité : poids de la page, nombre d'éléments dans le DOM, nombre de requêtes http. Il est clair que dans une démarche d'écoconception web, il y a tout intérêt à minimiser ces chiffres. Néanmoins, le score ne tient pas compte de la complexité du CSS et du JS, bien que cette complexité soit décisive dans l'énergie dépensée par le navigateur 🔌
Concernant le nombre de requêtes, les choses ne sont pas non plus si tranchées. Ainsi, le CMS Grav ou les plugins de cache de WordPress proposent de combiner tous les fichiers CSS ou JS dans un seul fichier. Certes, cela diminue le nombre de requêtes, mais cette pratique n'est pourtant pas toujours la meilleure.
En effet, est-il préférable de charger un seul fichier CSS de 100 ko, plutôt que 5 fichiers CSS de 20 ko ? Cet article de GTMetrix, parmi d'autres, signale qu'avec le protocole HTTP/2, cela n'a rien d'évident. Dans les captures d'écran ci-dessous, on voit que les ressources CSS et JS du site Aux vallées sont chargées en parallèle avec HTTP/2.
(Cliquer sur l'image pour l'agrandir)
(Cliquer sur l'image pour l'agrandir)
Quelle sera la méthode de chargement la plus efficiente pour le nagivateur ? La seule façon de le savoir, c'est de tester. C'est l'autre enseignement que je tire de ces expérimentations : au-delà des recommandations générales, il est toujours préférable de mesurer et comparer.
En ce sens, seuls des outils comme GTMetrix ou PageSpeed/Lightouse me semblent offrir les métriques nécessaires pour faire le job 👍
Des questions en suspens
Comme mentionné plus haut, je trouve que la complexité du CSS et du JS ne sont pas suffisamment mesurées dans l'écoconception web. Intuitivement, on comprend bien que moins il y en a, mieux c'est ! Mais il suffit de peu de lignes en JS pour faire mouliner sérieusement le navigateur. Sur beaucoup de sites vitrines, il n'y a pas de raison de recourir massivement à Javascript.
Pour CSS, j'avoue que dans mes pratiques, je déroge honteusement au principe de sobriété 😬 J'ai tendance à surcharger beaucoup de règles fournies par les thèmes et les extensions. Déjà, en soi, le principe de la surcharge est un gâchis. Ensuite, cela me pousse à écrire des sélecteurs "à rallonge", voire même parfois, de coupables "!important" 😱
À titre personnel, c'est donc un axe de progression que j'ai clairement identifié, bien qu'il ait tendance à passer sous les radars des outils de scoring. L'effort me paraît faire sens, bien plus que les quelques ko gagnés par la minification.
Conclusion
Finalement, cette plongée dans les tréfonds des millisecondes aboutit à une recommandation qu'il est bon d'appliquer dans tous les domaines : toujours se méfier des idées reçues !
Et j'ai la réponse à ma question de départ. Oui, avec un bon plugin de cache, mes étudiants font des sites WordPress rapides, et même plus rapides qu'avec Grav ou Kirby 🤯
Pourtant, en ce qui me concerne, je décide de poursuivre avec Kirby. Même si les poids lourds du caching WordPress font mieux que Kirby, cette plateforme reste infiniment plus légère et agile.
