Tout est parti d'une envie de me vanter
Il y a un an, j'ai refait ce site en HTML et CSS écrits à la main, sans script, sans cookie, sans rien. J'en ai fait tout un article, dans lequel je m'interrogeais sur ce que donnerait vraiment un site dépouillé jusqu'à l'os. J'y écrivais même, avec l'assurance de celui qui n'a pas encore vérifié, que j'espérais « le 100/100 pour chaque critère ».
Un an plus tard, je me suis dit qu'un petit bloc « Ce site en chiffres » sur la page d'accueil ferait son effet. Le poids de la page, le nombre de requêtes, zéro cookie, zéro script. De quoi appuyer mon propos sans avoir à le défendre.
Sauf que pour afficher des chiffres, il faut les mesurer. Et c'est là que ça a commencé à sentir le roussi.
Ce que j'ai trouvé
Mes images pesaient six fois trop lourd
Première mesure, page d'accueil : 110 Ko. Pas catastrophique. Sauf que 106 de ces 110 Ko étaient une seule image. Ma page « ultra légère » était en réalité constituée à 94 % d'une photo, avec un peu de texte autour pour faire joli.
Or cette photo, comme toutes les images du site, est tramée. Je l'ai passée dans ditherit.com pour obtenir ce rendu façon vieille impression. Le fichier de palette est resté dans mon dossier : trois couleurs. Un brun, un brun foncé, un crème.
Une image de trois couleurs. Stockée en JPEG.
Pour ceux qui ne font pas d'image au quotidien : le JPEG compresse par blocs de huit pixels sur huit, en partant du principe que les zones voisines se ressemblent. C'est redoutablement efficace sur une photo. C'est exactement l'inverse de ce qu'il faut pour du tramage, dont le principe même est d'alterner les pixels contrastés un à un. Le JPEG passe son temps à lutter contre la structure de l'image au lieu de l'exploiter.
Réencodées en PNG à palette indexée, deux bits par pixel, le tout vérifié pixel par pixel pour garantir un rendu strictement identique :
- la photo d'accueil : 106 Ko → 17 Ko
- une photo de trail : 632 Ko → 132 Ko
- le dossier d'images en entier : 2,9 Mo → 870 Ko
Aucune perte. Aucun compromis de qualité. Je n'ai rien « optimisé » au sens où on l'entend d'habitude, je n'ai pas dégradé la moindre image : j'ai juste arrêté de ranger mes affaires dans le mauvais tiroir. La page d'accueil est passée de 110 à 22 Ko.
J'ai écrit un article entier sur l'éco-conception et le poids des pages. Avec des images six fois trop lourdes pour rien.
23 Go d'archives en libre-service
En inventoriant le serveur, je m'attendais à trouver un gros gigaoctet et demi de fichiers. J'en ai trouvé vingt-cinq.
Un dossier d'archives personnelles que j'utilise comme disque dur distant, et que j'avais complètement oublié. Le listing de dossier était bien désactivé — mais les fichiers, eux, répondaient tranquillement. Y compris une sauvegarde WordPress de 15,5 Go, téléchargeable par quiconque en devinait le nom.
Je ne sais même plus ce qu'il y a dedans. C'est bien ça le problème.
Et le reste, en vrac
- Mon serveur compressait le HTML mais pas le CSS. 7,3 Ko au lieu de 2, à chaque visite, depuis toujours.
- Aucun en-tête de cache. Chaque visiteur revalidait tout, à chaque page.
- Pas de favicon : une erreur 404 à chaque visite, sur un site dont je comptais les requêtes.
- Des images appelées en
.jpgalors que les fichiers étaient en.JPG. Apache rattrapait par une redirection 301 — une requête supplémentaire par affichage, invisible dans mes comptes. - Un lien symbolique cassé pointant vers un déploiement de mars 2020.
Pourquoi je n'avais rien vu
La réponse facile serait de dire que je manque de temps. C'est vrai, mais c'est faux comme explication.
La vraie raison, c'est que ce site marchait. Il s'affichait, il était rapide à l'œil, les liens fonctionnaient, personne ne s'était jamais plaint. Et je confondais « ça marche » avec « c'est correct ».
Aucun de ces défauts ne produit de symptôme. Une image six fois trop lourde ne déclenche aucune alerte : elle rend juste la page un peu plus lente pour quelqu'un, quelque part, qui ne vous le dira jamais. Une feuille de styles non compressée ne se voit pas, elle se mesure. Un favicon manquant provoque une erreur que le navigateur encaisse sans broncher. Et des archives oubliées ne font aucun bruit — c'est précisément pour ça qu'on les oublie.
Ce sont des défauts silencieux. Pour les voir, il n'y a pas d'autre moyen que d'aller regarder exprès. Et on ne va jamais regarder exprès chez soi.
Ce que ça dit de nos audits
C'est là que ça devient intéressant pour mon métier, parce que je passe mes journées dans le RUN : la maintenance de sites en production, parfois depuis des années.
Je connais donc très bien cette situation. Un site qui tourne. Un client content. Aucun ticket ouvert. Et dessous, une couche de défauts silencieux qui s'épaissit tranquillement, année après année, parce que personne ne paie pour aller regarder quand rien ne va mal.
Mon site est le cas extrême : un seul intervenant, qui est aussi le seul utilisateur, le seul client et le seul auditeur. Autant dire que le contrôle qualité n'était pas très contradictoire.
Mais la mécanique est exactement la même chez nos clients, et je la vois avec beaucoup plus d'indulgence depuis. Quand je demande un budget d'audit sur un site qui « n'a pas de problème », je comprends mieux pourquoi c'est une vente difficile — et pourquoi c'est pourtant celle qui rapporte le plus. Ce qu'on trouve dans un audit, ce n'est presque jamais la panne que le client redoutait. Ce sont ces choses-là : des encodages absurdes, des réglages serveur jamais revus depuis l'installation, des fichiers que plus personne ne sait expliquer.
Autre leçon, plus désagréable : aucun de ces problèmes n'est un bug. Personne n'a écrit de code faux. Ce sont des choix par défaut que je n'ai jamais remis en question. JPEG parce que c'était « une photo ». La configuration serveur telle qu'elle est sortie de l'installation. Un dossier d'archives créé un jour pour dépanner et jamais rouvert. Rien de tout ça ne demandait de compétence particulière pour être évité — seulement de se poser la question une fois. C'est beaucoup plus vexant qu'une vraie erreur.
Bilan
Le site pèse désormais 22 Ko sur la page d'accueil contre 110, soit cinq fois moins, sans qu'aucune image n'ait été dégradée. Le CSS est compressé, les en-têtes de cache sont en place, les archives ne sont plus en libre-service. Et il y a un favicon.
Le bloc « Ce site en chiffres » que je voulais pour me vanter existe, il est sur la page d'accueil, et les valeurs qu'il affiche sont nettement meilleures que celles que j'aurais publiées si je ne m'étais pas posé la question.
Moralité : j'ai failli mettre en ligne un bloc célébrant la légèreté de mon site, mesuré sur une page constituée à 94 % d'une image mal encodée. Ça aurait été beaucoup plus gênant que cet article.
Quant aux deux mesures que j'annonçais depuis un an, les voici enfin. En EDGE, à 240 kbit/s, la page devient lisible en 4,4 secondes et complète en 5. Et la moitié de ce temps ne sert qu'à ouvrir la connexion : DNS, TCP, TLS. La page est devenue plus légère que le protocole qui la transporte, ce qui veut dire que continuer à l'alléger ne gagnerait presque plus rien.
Côté PageSpeed, j'écrivais il y a un an, avec l'assurance de celui qui n'a pas encore vérifié, que j'espérais « le 100/100 pour chaque critère ». C'est obtenu : 100 en performance, 100 en accessibilité, 100 en bonnes pratiques, 100 en référencement, sur le profil mobile.
Ce qui me permet de conclure sur une note désagréablement honnête : j'avais raison sur la théorie, et j'avais tort sur mon propre site. Les deux en même temps, pendant un an.