PageSpeed Insights : pourquoi votre score bouge sans que rien ne change
Dans la nuit du 4 au 5 septembre, le score PageSpeed de notre page d’accueil a fait 53, puis 69, puis 94, puis 59, puis 99. Entre les deux dernières mesures, on n’avait touché à rien de structurel. Voici ce que ce chiffre mesure réellement, les quatre erreurs de méthode qu’on a commises cette nuit-là, et ce qu’il faut regarder à la place.
Le score est une note de laboratoire, pas une mesure de vos visiteurs
C’est le point de départ, et il est écrit noir sur blanc dans la documentation de Google. Le test simule un chargement sur un seul appareil, avec un débit réseau fixé à l’avance. Les notes officielles de Chrome sur le calcul du score Lighthouse précisent que la majeure partie des variations observées ne vient pas de l’outil mais des conditions d’exécution : la machine qui lance le test, la charge du réseau à cet instant, les extensions du navigateur.
Ce qui compte pour votre référencement, ce sont les Core Web Vitals mesurés sur vos vrais visiteurs. D’après la documentation web.dev de Google sur les Core Web Vitals, mise à jour le 31 octobre 2024, le seuil à viser est un LCP sous 2,5 secondes, un INP sous 200 millisecondes et un CLS sous 0,1, évalués au 75e percentile des chargements de page, mobile et ordinateur comptés séparément.
Autrement dit : un quart de vos visiteurs peut avoir une expérience plus lente que le seuil sans que ça vous pénalise. Et un score de laboratoire à 99 ne garantit rien si votre serveur met deux secondes à répondre depuis une connexion mobile réelle. Google consacre d’ailleurs un article entier à l’écart entre données de laboratoire et données de terrain.
La conséquence pratique est simple. Ne prenez jamais une décision sur une seule mesure. Trois relevés espacés, on garde la médiane.
Erreur n° 1 : accuser un fichier sur sa taille non compressée
Notre feuille de style pesait 341 Ko sur le disque. Chiffre impressionnant, coupable idéal. On l’a désigné deux fois en deux semaines.
Sauf que le serveur la compresse avant de l’envoyer. Sur le réseau, elle transférait 71 Ko. Le vrai poids de la page venait des images : 810 Ko sur 1 044 Ko au total. Un audit réalisé deux semaines plus tôt le disait déjà, et on l’avait contredit sur la foi d’une taille de fichier lue dans un explorateur.
La commande qui règle le débat tient en une ligne :
curl -s -o /dev/null -w "%{size_download}\n" \
-H "Accept-Encoding: br,gzip" https://votresite.fr/style.cssTant que vous n’avez pas mesuré le transfert réel, vous ne savez pas ce que vous optimisez. C’est la leçon la plus rentable de toute cette nuit.
Erreur n° 2 : optimiser une image sans regarder où elle s’affiche
On a régénéré quinze images au format WebP. Gain immédiat, page divisée par deux. Le lendemain matin, retour du client : les photos de l’équipe sont floues.
On avait mesuré la taille d’affichage sur un écran de 375 pixels de large, et généré les portraits en 160 pixels. Sur ordinateur, les mêmes portraits s’affichent à 336 pixels. Et comme ils sont recadrés en object-fit: cover, le navigateur doit remplir la plus grande des deux dimensions, pas la plus petite.
La règle qu’on aurait dû appliquer dès le départ : largeur de fichier = plus grande dimension affichée × 2, pour couvrir les écrans à haute densité. Nos portraits sont passés à 672 pixels.
Deuxième constat, plus embêtant : un seul fichier ne peut pas servir correctement un téléphone et un écran de bureau. Trop grand, il plombe le mobile. Trop petit, il floute l’ordinateur. La réponse s’appelle srcset, et elle n’est pas optionnelle dès qu’une image apparaît sur les deux formats.
Un détail qui coûte cher si on l’oublie : quand vous remplacez une image par une version plus grande en gardant le même nom de fichier, les navigateurs continuent de servir l’ancienne pendant des jours. On a dû renommer les fichiers pour voir le correctif.
Erreur n° 3 : confondre le poids du CSS et le moment où il fait mal
Notre page d’accueil embarque son CSS directement dans le <head>, ce qui est censé accélérer le premier affichage. Le résultat mesuré disait le contraire : premier affichage à 1,7 seconde, mais LCP à 9,1 secondes. Sept secondes d’écart pour une seule image.
L’explication n’a rien à voir avec le poids du CSS sur le réseau. Ce bloc de style fait 193 Ko à lui seul. L’image principale, elle, est déclarée après, dans le corps du document. Le navigateur devait donc analyser 196 Ko de document avant même de savoir qu’il y avait une image à télécharger.
Le correctif tient en une balise placée tout en haut du <head> :
<link rel="preload" as="image"
href="/hero.webp"
imagesrcset="/hero-480.webp 480w, /hero-960.webp 960w"
imagesizes="(max-width: 782px) 100vw, 960px">L’image est désormais annoncée à 9,5 Ko du début du document, soit 187 Ko d’analyse économisés avant le déclenchement du téléchargement. Sur notre page de campagne publicitaire, le score est passé de 68 à 88 avec cette seule modification.
Un avertissement, parce que celui-là fait perdre le gain : les attributs imagesrcset et imagesizes du preload doivent être strictement identiques à ceux de la balise <img>. Au moindre écart, le navigateur télécharge deux fichiers différents et vous ralentissez la page que vous vouliez accélérer.
Dans le même esprit, on a retiré le préchargement d’une police décorative qui ne sert qu’en bas de page. Elle réclamait 38 Ko en priorité haute, devant l’image que le visiteur regarde en premier.
Erreur n° 4 : mesurer le temps de réponse serveur au mauvais endroit
Le TTFB brut mélange trois choses : la résolution DNS, la négociation de la connexion chiffrée, et le temps que met votre serveur à fabriquer la page. Sur notre hébergement, la seule négociation TLS variait de 0,35 à 1,43 seconde d’une mesure à l’autre. Elle noyait complètement le signal.
Ce qu’il faut isoler, c’est l’écart entre starttransfer et pretransfer :
curl -s -o /dev/null \
-w "traitement: %{time_starttransfer}s (dont TLS %{time_appconnect}s)\n" \
https://votresite.fr/Deuxième piège, et il est méchant : ajouter ?cb=123 à la fin d’une URL pour éviter le cache navigateur contourne aussi le cache statique du serveur. Vous mesurez alors le temps de génération PHP, jamais ce que reçoivent vos visiteurs. Nos deux chiffres différaient d’un facteur six.
Une fois la mesure remise d’aplomb, le vrai correctif est apparu tout seul. En basculant le cache en mode expert, le serveur sert un fichier statique sans réveiller PHP, ce qui protège aussi la machine en cas de pic de trafic automatisé : 1,196 seconde de traitement contre 0,189, soit 84 % de moins.
Ce que le score dit, et ce qu’il faut lire à la place
| Ce que vous lisez | Ce que ça vaut | Ce qu’il faut regarder |
|---|---|---|
| Score global sur 100 | Une simulation, variable de 10 à 15 points d’un test à l’autre | La médiane de trois mesures espacées |
| « Réduire le CSS inutilisé, 341 Ko » | Une taille avant compression, souvent trompeuse | Le poids transféré, mesuré avec size_download |
| LCP élevé avec un FCP correct | Un signal de découverte tardive, pas de poids excessif | La position de l’image principale dans le document |
| TBT qui saute d’un test à l’autre | Le bruit de la machine qui exécute le test | L’INP mesuré sur le terrain, dans la Search Console |
« Le score bouge, donc on court après le score. C’est exactement le piège. Sur notre propre site, la nuit où on a arrêté de relancer le test pour aller mesurer le poids réellement transféré, on a trouvé le problème en dix minutes. Il était là depuis le début, et un audit nous l’avait déjà signalé. »
La méthode qui marche, dans l’ordre
- Mesurer le poids transféré de la page, par type de ressource. Images, styles, scripts, polices. Le plus gros poste gagne, pas le plus gros fichier sur le disque.
- Identifier l’élément LCP et vérifier à quelle distance du début du document le navigateur le découvre.
- Isoler le temps de traitement serveur, sans le TLS et sans contourner le cache.
- Refaire trois mesures espacées et comparer les médianes, jamais deux tests consécutifs.
Notre page d’accueil est passée de 1 044 Ko à 441 Ko, et le score ordinateur de 57 à 99. Mais le chiffre dont on est le plus content, c’est le temps de traitement serveur divisé par six. Celui-là, tous les visiteurs le ressentent, y compris ceux que le laboratoire ne simule jamais. Un dernier avertissement : accélérer un site avec un cache statique peut casser ses formulaires, et c’est un effet de bord qu’on a découvert le lendemain. On l’a raconté ici.
Un score qui plafonne malgré vos efforts ?
On mesure le poids réellement transféré, on identifie l’élément LCP et on isole le temps serveur. Rapport chiffré sous 48 heures ouvrées, sans engagement.
Sources et références
- Google, Web Vitals, web.dev, mis à jour le 31 octobre 2024.
- Google, Lighthouse performance scoring, Chrome for Developers.
- Google, Why lab and field data can be different (and what to do about it), web.dev.
Jean Fagnon est le fondateur de Kefa Global Network, agence web installée en France qui conçoit et maintient des sites pour des TPE, des PME et des cabinets libéraux. Toutes les mesures citées ont été relevées sur le site de l’agence entre le 2 et le 5 septembre 2026.
Publié le 5 septembre 2026.