Google PageSpeed Insights : comment lire et utiliser les résultats en 2026

Le gros chiffre vert en haut de PageSpeed Insights n’est pas ce que Google utilise pour juger votre site. Lisez d’abord le bloc « données terrain », qui décrit de vrais visiteurs, et traitez le score comme un outil de vérification de correctif, rien de plus. Presque toutes les mauvaises décisions que je vois autour de cet outil viennent d’une lecture à l’envers.

Voici comment je lis un rapport, dans l’ordre, avec ce que chaque bloc dit vraiment, deux mesures réelles que j’ai prises sur des sites de ma flotte, et la façon dont je transforme un rapport en liste de travail chiffrée.

Ce qu’est vraiment PageSpeed Insights

L’outil combine deux sources très différentes. D’après la documentation officielle, les données de laboratoire viennent de Lighthouse, qui simule un chargement de page, et les données terrain viennent du Chrome UX Report (CrUX), sur une fenêtre glissante de 28 jours.

La différence change tout :

• Terrain : des visiteurs réels, sur leurs appareils réels, avec leur réseau réel. C’est la mesure qui compte pour les Core Web Vitals.
• Laboratoire : un seul chargement simulé, sans cache, dans un datacenter. C’est reproductible, donc utile pour tester, mais ce n’est pas un visiteur.

Un détail que beaucoup ignorent : la documentation précise que le test tourne depuis un datacenter Google, dont l’emplacement est indiqué dans le rapport (Amérique du Nord, Europe ou Asie). Si votre clientèle est à Marseille et que votre hébergement est mal configuré, un test lancé depuis loin vous montrera un premier octet plus lent que ce que vit un visiteur de PACA. Je garde cette nuance en tête avant d’accuser le serveur.

Le bloc « données terrain » : comment le lire

C’est la première section du rapport, et c’est la seule qui reflète l’expérience réelle. Trois métriques y sont jugées au 75e centile. D’après web.dev, les seuils « bon » sont de 2 500 ms pour le LCP, 200 ms pour l’INP et 0,1 pour le CLS. Concrètement, 75 % des visites doivent passer sous le seuil pour que la métrique soit verte.

Quatre cas de figure, que je rencontre régulièrement :

1. L’URL a ses propres données. Parfait, c’est la lecture la plus fiable.
2. L’URL n’a pas assez de visites, mais le domaine oui. L’outil bascule sur les données du domaine entier. Attention : vous lisez alors une moyenne qui mélange votre page d’accueil, vos articles et votre formulaire. Une page lente peut y être noyée.
3. Ni l’URL ni le domaine. Le rapport affiche qu’il n’y a pas assez de données. Un artisan local avec quelques centaines de visites mensuelles se retrouve souvent là. Ce n’est pas une panne, c’est un seuil de volume.
4. Les données existent mais sont anciennes. Comme la fenêtre est de 28 jours, un correctif déployé hier n’apparaîtra pleinement que dans un mois.

Ce dernier point m’a valu des appels de clients qui trouvaient que « rien n’avait bougé » trois jours après une livraison. Je préviens désormais dès la remise du devis : la date de remesure est fixée à J+28, écrite noir sur blanc.

Le score : ce qu’il pèse et pourquoi il est trompeur

Le cercle de 0 à 100 est un résultat de laboratoire. La documentation Lighthouse pondère cinq métriques pour les versions récentes : Total Blocking Time 30 %, LCP 25 %, CLS 25 %, First Contentful Paint 10 % et Speed Index 10 %.

Deux lectures que je fais systématiquement.

D’abord, 80 % du score tient à trois métriques. TBT, LCP et CLS. Le TBT mesure le temps où le fil principal est bloqué par du JavaScript, et c’est la plus lourde. Sur un site vitrine, le premier réflexe n’est donc pas d’optimiser les images, c’est de regarder quels scripts tiers bloquent le chargement. Un widget de chat, une balise publicitaire ou un outil de cartographie coûtent plus de points que n’importe quelle image.

Ensuite, le TBT n’est pas une métrique terrain. Les Core Web Vitals utilisent l’INP, qui mesure les vraies interactions. Le TBT sert de remplaçant en laboratoire, puisqu’un test sans clic ne peut pas mesurer l’INP. Un site peut donc avoir un bon score labo et un INP médiocre, ou l’inverse. C’est la raison numéro un pour laquelle les deux blocs d’un même rapport se contredisent.

Comme le score vient d’une simulation, il varie. Mes règles : trois passages, médiane retenue, même gabarit avant et après, jamais des pages différentes.

Deux mesures réelles : ce qu’un rapport ne vous dit pas

Pour ne pas rester théorique, j’ai fait une mesure simple le 19 octobre 2026. Le cadre est limité et je le dis : une requête HTTP en ligne de commande, depuis un serveur d’intégration continue, avec compression activée. Ce n’est ni un test Lighthouse ni une donnée terrain.

Site	Code HTTP	Premier octet	HTML compressé
eotra.fr	200	0,33 s	20,6 Ko
urgenceserrures.fr	200	0,90 s	11,2 Ko

Le résultat est contre-intuitif. Le site le plus léger, urgenceserrures.fr, répond le plus lentement : 0,90 s contre 0,33 s pour eotra.fr, alors que sa page pèse presque moitié moins. Le poids de la page n’explique donc pas le délai du premier octet.

Ce que j’en tire, et ce que je n’en tire pas :

• Je ne conclus pas que urgenceserrures.fr est lent pour ses visiteurs. Une seule requête, depuis un serveur éloigné de la zone visée, avec une connexion à froid, ne prouve rien.
• Je conclus que l’écart mérite d’être retesté plusieurs fois, depuis la France, avant de toucher au code. Si l’écart persiste, la piste est côté serveur, cache ou réseau, pas côté volume de page.
• Je retiens la leçon générale : un petit HTML n’est pas un site rapide. Ce piège est classique dans les rapports PageSpeed, où le détail « taille de la page » rassure alors que le blocage est ailleurs.

C’est pour cela que le premier octet figure dans mes vérifications avant tout travail sur le front.

Les diagnostics : trier au lieu de tout corriger

Sous le score, PageSpeed liste des « opportunités » et des « diagnostics » avec des gains estimés en secondes. Deux pièges.

Les gains estimés ne s’additionnent pas. Chaque ligne est calculée isolément ; corriger trois lignes à 0,5 s ne fait pas gagner 1,5 s. Je traite la ligne la plus grosse, je reteste, puis je recommence.

Un audit validé n’est pas un problème résolu. Un test réussi sur « compresser les images » ne dit rien sur l’image qui est le LCP si elle est découverte trop tard. Je cherche d’abord quel élément est le LCP, puis je décompose son délai.

Mon ordre de tri :

1. Les scripts tiers qui bloquent (TBT, donc 30 % du score et souvent l’INP terrain).
2. L’élément LCP et la manière dont il est chargé.
3. Les décalages de mise en page (CLS), souvent corrigés en une heure avec des dimensions réservées.
4. Le reste, seulement s’il reste du budget.

Quand arrêter d’optimiser

Un score élevé n’est pas un objectif commercial. Ma règle : je m’arrête quand les trois métriques terrain sont vertes, ou, faute de données, quand le test labo est stable au-dessus de 90 sur trois passages. L’heure suivante vaut mieux investie dans le contenu et la fiche d’établissement Google que dans un point de score.

Il y a aussi un angle réglementaire à ne pas négliger. Pour mesurer la performance en production, j’utilise Plausible, qui fonctionne sans cookie. Ajouter un outil de suivi qui exige un consentement au titre du RGPD, selon les règles de la CNIL, dégrade précisément l’expérience que vous cherchez à améliorer : un bandeau de plus, un script de plus.

Côté facturation, je chiffre un correctif PageSpeed en heures, sur la base de mon TJM, avec la date de remesure à 28 jours. Un client qui voit « 3 h pour retirer un script bloquant » comprend ce qu’il paie, ce qui n’est pas le cas d’un « rapport d’optimisation » de dix pages.

Résumé

PageSpeed Insights se lit de haut en bas : données terrain d’abord, score ensuite, diagnostics en dernier. Le score est une simulation unique dont 80 % dépend de TBT, LCP et CLS. Il sert à vérifier un correctif, pas à juger un site.

Points à retenir

• Les données terrain (CrUX, 28 jours, 75e centile) priment sur le score de laboratoire.
• Seuils verts : LCP 2 500 ms, INP 200 ms, CLS 0,1.
• Sans données sur l’URL, l’outil bascule sur le domaine, puis n’affiche rien si le volume est trop faible.
• TBT, LCP et CLS pèsent 80 % du score Lighthouse ; le TBT remplace l’INP en laboratoire.
• Les gains estimés des opportunités ne s’additionnent pas : corrigez, retestez, recommencez.
• Un HTML léger ne garantit pas un premier octet rapide, comme le montrent mes mesures sur eotra.fr et urgenceserrures.fr.