Rendre un site rapide une fois, c’est facile. Le garder rapide tout en continuant d’ajouter des fonctionnalités, c’est là que tout se complique : chaque nouveau composant, chaque police, chaque bibliothèque alourdit un peu la page, et personne ne s’en aperçoit jusqu’à ce que le site paraisse lent. Nous avons donc cessé de traiter la vitesse comme un audit ponctuel pour en faire un test que chaque modification doit réussir.
Le point de départ
Lorsque nous avons mesuré ce site sérieusement pour la première fois, la mise en page sautait au chargement (un Cumulative Layout Shift d’environ 0,2) et le contenu principal mettait 4 à 6 secondes à apparaître sur une connexion mobile bridée. La feuille de style principale pesait 41 Ko compressée, surtout parce que des composants et du code de validation destinés à l’espace d’administration étaient aussi envoyés aux visiteurs.
Ce que nous avons changé
- Les visiteurs ne reçoivent que le code des visiteurs. La bibliothèque d’interface de l’administration et la bibliothèque de validation des formulaires n’atteignent plus le site public. Un test parcourt les imports du site et échoue si l’une d’elles revient en douce.
- Du CSS uniquement pour ce qui est sur la page. La feuille de style principale est passée de 296 Ko à 98 Ko, et à 16 Ko compressée.
- Des polices qui ne décalent pas la mise en page. Les polices clés sont préchargées et la page ne précharge plus du code dont elle n’aura peut-être jamais besoin.
Le test qui maintient le cap
Sur chaque pull request, la CI compile le site, le sert comme le fait la production — HTTP/2, TLS, compression — et lance Lighthouse trois fois sur quatre pages clés, en retenant la médiane. Le budget : chaque score à 95 au moins, le plus grand élément de contenu visible en moins de 2 secondes, un décalage de mise en page inférieur à 0,1, un blocage du thread principal inférieur à 200 ms. Si une modification dépasse le budget, la CI passe au rouge et la modification n’est pas fusionnée. Un contrôle d’accessibilité tourne en parallèle et ne trouve actuellement aucune violation WCAG AA sur les pages qu’il couvre.
Le résultat
En CI, les pages obtiennent 100 dans les quatre catégories de Lighthouse, avec le contenu principal visible en moins d’une seconde. Sur le site en ligne, la page d’accueil obtient 100 avec le contenu principal en 1,2 seconde environ, et une page produit obtient 98.
Nous sommes aussi honnêtes sur ce qui n’est pas encore parfait : les pages en japonais et dans les autres langues CJK sont plus lentes, car leurs polices sont beaucoup plus lourdes. Cela fait l’objet d’une tâche à part.
Pourquoi c’est important pour vous
Une page lente perd ses visiteurs avant qu’ils aient lu un mot, et les moteurs de recherche le remarquent aussi. Si vous créez une landing page ou une boutique avec nous, ce budget est inclus — il fait partie de notre façon de travailler, ce n’est pas une option.