De 6,3 Mo à 0,37 Mo : anatomie d'un site 10 fois plus rapide

Voici une étude de cas que nous pouvons publier avec une confiance inhabituelle, car le patient était ce site même. En une session de travail, nous avons fait passer notre page d'accueil d'un payload de 6,3 Mo et d'un Largest Contentful Paint mobile de 34,6 secondes à 0,37 Mo et 3,6 secondes — et l'accessibilité de 76 à 100. Voici exactement ce qui n'allait pas, ce que nous avons changé et ce que nous avons mesuré. Pas de captures de sites d'autrui ; nos propres chiffres.

La ligne de base (elle était mauvaise)

Les chiffres après correction sont des mesures de laboratoire (Lighthouse, 4G simulée) contre le build de production servi en local ; les chiffres de terrain en production varieront.

Constat n°1 : une image représentait 82 % de la page

Le fond du hero était un PNG de 5,14 Mo et 2816 pixels. Deux pages sœurs portaient leurs propres PNG de 9,4 Mo et 6,8 Mo — 21,5 Mo d'images de hero sur trois pages. Le correctif est banal et vaut plus que toutes les autres optimisations réunies : redimensionner à la plus grande largeur affichée (1920px) et convertir en WebP. Résultat : 5,14 Mo → 191 Ko, visuellement identique sous l'overlay sombre du hero. Comme l'image était un background CSS — invisible pour le preload scanner du navigateur avant l'analyse du CSS — nous avons ajouté <link rel="preload" as="image" fetchpriority="high">.

Constat n°2 : le serveur envoyait tout en clair, à chaque fois

Le serveur web n'avait ni compression ni en-têtes de cache : 550 Ko de CSS/JS voyageaient non compressés à chaque visite. Activer gzip a réduit le texte d'environ 75 % (notre plus grosse feuille de style est passée de 89 Ko à 14,5 Ko sur le fil), et les en-têtes de cache ont rendu les visites récurrentes quasi gratuites. Un avertissement à retenir : nos règles de cache par regex auraient silencieusement capturé des chemins devant être proxés vers un autre service — préfixer ces location avec ^~ les protège. Nous l'avons découvert en test, pas en production, seul endroit acceptable pour cette découverte.

Constat n°3 : mort par mille blocages de rendu

Une police d'icônes entière chargée pour exactement un glyphe (remplacée par un SVG inline). Vingt variantes de webfonts déclarées, six utilisées. Trois scripts analysés de façon synchrone avant le premier rendu (désormais defer). Un loader décoratif plein écran qui retenait la page 900 ms après que tout avait déjà chargé. Et un widget résiduel du template qui réclamait un fichier supprimé du build — un 404 garanti et une erreur console à chaque chargement de chaque page, qui coûtait à lui seul quatre points de Best Practices.

Constat n°4 : le layout shift se cache dans les bonnes intentions

Notre plus grande leçon de CLS : ajouter des attributs width/height à une image avec ses dimensions intrinsèques a empiré les choses, car le CSS contraignait la hauteur affichée — l'en-tête réservait 165px, s'effondrait à 40px et décalait tout le reste. Les attributs doivent décrire la géométrie affichée. Le CLS est passé de 0,259 à zéro.

Ce que nous n'avons délibérément pas fait

Aucune migration de framework, aucun pipeline de build, aucun tree-shaking du bundle hérité. La discipline compte : 90 % du gain est venu des images, de la compression et des en-têtes — des changements au risque de régression quasi nul. Les points mobiles restants relèvent d'un travail de critical-CSS dont le rapport risque/bénéfice est une décision séparée et assumée.