100 points sur PageSpeed : ce que nous avons changé

La valeur de départ était de 58 sur 100 sur mobile. Ce n'est pas un mauvais score pour un site avec un effet 3D en en-tête, mais c'est un score que Google sanctionne sensiblement dans la recherche mobile. À l'arrivée : 100 points sur ordinateur et 98 sur mobile, avec également 100 pour l'accessibilité.

Ce qui suit n'est pas une liste générale mais le déroulé réel – y compris les endroits où nous nous sommes trompés.

La situation de départ

Les cinq interventions qui ont vraiment compté

1. Remplacer la bibliothèque, pas l'optimiser

L'en-tête affiche un nuage de particules en 3D. Une bibliothèque graphique connue tournait pour cela – 458 Ko après minification. La mesure indiquait que 51 Ko n'étaient jamais exécutés.

Le regard décisif a été de nous demander ce dont nous avions réellement besoin. C'était onze briques : moteur de rendu, scène, caméra, géométrie, matériau et quelques classes utilitaires. Tout cela se programme directement contre l'interface graphique du navigateur.

Résultat : 458 Ko sont devenus 6 Ko. Le rendu est identique – nous avons repris les mêmes shaders.

2. La compression n'était qu'à moitié activée

Dans la configuration du serveur, la compression était sur « activée » – mais la ligne indiquant quels types de fichiers compresser était commentée. C'est le réglage par défaut de nombreuses distributions. Résultat : seul le HTML était compressé.

La bibliothèque graphique passait donc sur le réseau sans compression. Après activation : 1243 Ko sont devenus 251 Ko. En complément, nous déposons désormais les versions compressées précalculées à côté, pour que le serveur ne recalcule pas à chaque appel.

Effort : deux lignes de configuration. Effet : près d'un mégaoctet par première visite.

3. Supprimer entièrement la bibliothèque d'animation

Une autre bibliothèque, de 114 Ko, gérait les apparitions au défilement. La mesure la désignait en outre comme responsable de recalculs de mise en page forcés – elle interrogeait la géométrie pendant le défilement et obligeait le navigateur à recalculer la mise en page en plein mouvement.

Remplacée par un IntersectionObserver qui se contente d'ajouter une classe. Le mouvement lui-même est fait en CSS. 114 Ko de moins, plus de recalculs, une quarantaine de lignes de code maison.

4. Le favicon pesait 205 Ko

Un détail à l'effet étonnant, parce qu'il se charge très tôt. Remplacé par un fichier SVG de 6 Ko, produit à partir du logo existant.

5. Interroger la géométrie dans la trame d'animation

Un script lisait la hauteur totale du document à chaque événement de défilement. Le navigateur ne peut pas répondre de mémoire à cette propriété – il doit recalculer la mise en page de toute la page, en plein défilement.

La règle qui en découle et qui vaut partout : lire dans l'événement, écrire dans la trame suivante. Jamais l'inverse. Depuis, la hauteur de page est mesurée une fois et mémorisée, au lieu d'être redemandée soixante fois par seconde.

L'erreur qui a coûté 24 points

Ce qui a peu rapporté

Pour être complets, les mesures présentes dans tous les guides et à peine mesurables chez nous :

Les formats d'image. Notre page d'accueil comporte peu d'images – le logo est un fichier SVG. Là où il y a des images, la conversion vaut évidemment la peine ; comme levier principal, elle ne sert que sur les pages riches en images.

Réduire encore les polices. Nous hébergeons nous-mêmes deux familles et préchargeons celles nécessaires à la zone visible. Une optimisation supplémentaire serait possible, mais ne bouge pas le score.

L'emplacement du serveur. Souvent recommandé, sans objet dans notre cas : le temps jusqu'au premier octet était déjà de 20 millisecondes. Qui est déjà bon à cet endroit ne gagne rien avec un réseau de distribution.

La marche à suivre, à reproduire

1. Mesurer avant toute modification. Mobile et ordinateur séparément, et noter les valeurs.
2. Chercher le plus gros fichier transféré. C'est presque toujours du JavaScript. La question n'est pas comment le réduire, mais si on en a besoin.
3. Vérifier la compression. Non pas si elle est activée, mais pour quels types de fichiers.
4. Compter les requêtes bloquantes. Chaque feuille de style dans l'en-tête retarde le premier rendu.
5. Contrôler les décalages sans bridage. Le test qui nous a manqué.
6. Remesurer après chaque modification. Sinon on ne sait pas, à la fin, ce qui a agi.

Aide-moi à traduire le rapport PageSpeed de mon site en un ordre
de priorités. Sois strict ; ne complimente rien.

Mes mesures :
- Mobile : [score], ordinateur : [score]
- LCP, TBT, CLS par appareil : [valeurs]
- Plus gros fichiers transférés avec leur taille : [liste]
- Requêtes bloquant le rendu : [liste]
- Messages du rapport : [coller le texte]

Sur le site :
- Comment il est construit : [CMS / statique / éditeur en ligne]
- Le JavaScript est-il nécessaire au contenu visible ? [oui/non]
- Comment le CSS est-il livré ? [externe / intégré / partiellement
  intégré]

Tâches :
1. Rattache chaque message à une cause et dis quel indicateur il
   influence – LCP, TBT ou CLS.
2. Classe les mesures par effet rapporté à l'effort. Pour chacune,
   indique combien de points elle déplace réellement et pourquoi.
3. Nomme les mesures du rapport qui n'apportent pratiquement rien
   à ce type de construction – et justifie, au lieu de simplement
   les omettre.
4. Pour chaque gros fichier JavaScript, demande d'abord s'il est
   nécessaire avant de proposer de le réduire.
5. Signale si le CSS n'est que partiellement intégré et explique
   pourquoi cela peut être pire pour le CLS que pas du tout.
6. Indique ce que je devrais remesurer après chaque modification.

N'invente aucune mesure.

Conclusion

Le score en lui-même n'est pas l'objectif – c'est une mesure, pas un résultat commercial. Ce qui compte, c'est l'expérience derrière : une page lisible au bout de 1,4 seconde est lue par plus de monde qu'une page qui en demande six. Chez les visiteurs mobiles en réseau cellulaire, l'écart pèse plus lourd que n'importe quelle optimisation de texte.

Le chemin est passé chez nous par une seule question récurrente : en avons-nous besoin ? Cinq interventions sur six ont consisté à retirer quelque chose, pas à en ajouter.

Questions fréquentes