PageSpeed Insights
PageSpeed Insights est l'outil de Google qui affiche côte à côte les mesures relevées sur les visites réelles d'une page et celles d'un test simulé.
Définition
PageSpeed Insights est l’outil de Google qui affiche côte à côte les mesures relevées sur les visites réelles d’une page et celles d’un test simulé. Les deux moitiés du rapport ne disent pas la même chose, et l’essentiel des malentendus vient de ce qu’on les lit comme une seule note.
Pourquoi un seul écran contient deux rapports
Parce qu’ils répondent à deux questions différentes : où en est-on, et pourquoi.
La partie haute s’appuie sur le rapport d’expérience utilisateur de Chrome. Ce sont des données de champ : ce que des visiteurs réels ont vécu, sur leurs appareils et leurs connexions. Google y publie les valeurs de FCP, LCP, CLS et INP, ainsi que le TTFB à titre expérimental, sur une fenêtre glissante de 28 jours, actualisée chaque jour.
La partie basse est produite par Lighthouse, qui charge la page à la demande dans un environnement simulé. Ce sont des données de laboratoire : reproductibles, détaillées, et sans rapport direct avec ce que vivent vos visiteurs. C’est de là que vient le score sur 100. Traduire ce score en actions utiles suppose de trier ce qui pèse vraiment, un travail de diagnostic de performance.
Google documente d’ailleurs le fait que les deux peuvent se contredire, et l’explique par leur nature : l’un est un historique de conditions variées, l’autre un chargement unique dans des conditions fixes.
Comment se lit la partie mesurée
Par le 75e centile, et par un jeu de seuils publiés.
Au-dessus des barres de répartition, PageSpeed Insights affiche pour chaque indicateur la valeur du 75e centile. Ce choix est expliqué : il s’agit de représenter les expériences les plus frustrantes plutôt que la moyenne. Les seuils appliqués sont ceux de l’initiative Web Vitals.
| Indicateur | Bon | À améliorer | Mauvais |
|---|---|---|---|
| LCP | jusqu’à 2 500 ms | 2 500 à 4 000 ms | au-delà de 4 000 ms |
| INP | jusqu’à 200 ms | 200 à 500 ms | au-delà de 500 ms |
| CLS | jusqu’à 0,1 | 0,1 à 0,25 | au-delà de 0,25 |
| FCP | jusqu’à 1 800 ms | 1 800 à 3 000 ms | au-delà de 3 000 ms |
| TTFB, expérimental | jusqu’à 800 ms | 800 à 1 800 ms | au-delà de 1 800 ms |
Les trois indicateurs qui composent les Core Web Vitals sont l’INP, le LCP et le CLS. L’évaluation est réussie quand les trois 75e centiles sont dans le vert. Si les données d’INP sont insuffisantes, l’évaluation se joue sur le LCP et le CLS seuls. Si le LCP ou le CLS manquent, la page ne peut pas être évaluée du tout.
Le raccourci à éviter. Corriger une page, relancer le test, et conclure que rien n’a bougé. Le score de la partie basse change immédiatement, mais la partie haute agrège 28 jours de visites : une correction déployée hier n’y pèse presque rien. Les deux moitiés n’ont pas la même horloge, et les confondre fait annuler des corrections qui fonctionnaient.
Ce que vaut le score sur 100
Un indicateur de diagnostic, pas un objectif à atteindre.
Google situe le score : au-delà de 90 il est considéré comme bon, entre 50 et 89 il demande à être amélioré, en dessous de 50 il est mauvais. La documentation ajoute une réserve rarement citée : un bon score de laboratoire ne signifie pas que l’expérience réelle des visiteurs sera bonne.
La variabilité du score est également documentée et attendue. Lighthouse simule pour le mobile un appareil de milieu de gamme sur un réseau mobile, et pour l’ordinateur un poste émulé avec une connexion filaire. Le test s’exécute par ailleurs dans un centre de données de Google, situé en Amérique du Nord, en Europe ou en Asie selon les cas, ce que le rapport indique. Deux exécutions successives ne donnent donc pas exactement le même chiffre, sans que la page ait changé.
La conséquence pratique est simple : le score sert à comparer un avant et un après sur la même page, pas à se comparer à un concurrent, et encore moins à se fixer une note comme objectif contractuel.
Ce que l’outil désigne le plus souvent sur un site WordPress
Trois familles de causes, dans un ordre de traitement à peu près constant.
Le temps de réponse du serveur
Quand le TTFB est élevé, rien de ce qui suit ne peut compenser : le navigateur attend. Le cache de page est le levier le plus direct, avant toute optimisation de la page elle-même.
Ce qui bloque l’affichage
Feuilles de style et scripts chargés avant le rendu retardent l’apparition du contenu principal. Sur WordPress, ils viennent le plus souvent du thème et des extensions, chacune ajoutant ses propres fichiers sur toutes les pages, y compris celles où elle ne sert à rien.
Les images et les polices
Une image trop lourde retarde le LCP, une police chargée sans réservation d’espace décale la mise en page et alimente le CLS. Ces deux points sont les plus faciles à corriger et les plus souvent laissés de côté.
L’erreur de mesure la plus fréquente : regarder la page en étant connecté
Un rapport ne vaut que si la page mesurée est celle que reçoit un visiteur.
PageSpeed Insights n’est pas exposé à ce biais : il charge la page depuis un centre de données de Google, sans session ouverte. Le piège est dans les mesures que l’on fait soi-même, dans l’onglet réseau du navigateur, et qui servent ensuite à décider quoi corriger. WordPress ajoute pour toute personne connectée sa barre d’outils, avec la feuille de style et le script qui la font fonctionner, et plusieurs extensions se comportent de la même façon.
La cascade de chargement observée dans cet état contient donc des fichiers qu’aucun visiteur ne télécharge. On y voit du travail à faire là où il n’y en a pas, et l’on ne voit pas celui qui existe vraiment.
Constat de terrain. Vérifié le 29 août 2026 sur ce site : la page du lexique, téléchargée sans session ouverte, ne contient aucune balise de script pointant vers un fichier externe et aucune feuille de style liée, pour environ 108 Ko de page. Tout est écrit dans la page elle-même. Le même contrôle mené depuis une session d’administration n’aurait pas donné ce résultat, puisque la barre d’outils et ses fichiers s’ajoutent pour les personnes connectées.
La règle qui en découle tient en une phrase : toute mesure de performance se fait en navigation privée, ou avec un outil qui n’ouvre pas de session. C’est vrai de la mesure faite au navigateur, et c’est aussi ce qui explique certains écarts entre ce que l’on croit servir et ce que la partie mesurée du rapport constate.
Questions fréquentes
Pourquoi la partie haute affiche-t-elle des données du site entier et non de ma page ?
Parce que la page n’a pas assez de visites pour être mesurée seule. Dans ce cas, PageSpeed Insights bascule sur une agrégation au niveau du domaine, qui regroupe toutes les expériences de toutes les pages. Cela arrive systématiquement sur une page récente, et cela signifie que le chiffre affiché ne parle pas de la page consultée.
Pourquoi mon site est-il rapide chez moi et lent dans l’outil ?
Parce que votre navigateur conserve en cache une partie des fichiers et que votre connexion n’est pas celle du test. C’est précisément la raison d’être de la partie mesurée : elle agrège des visiteurs qui, eux, arrivent souvent sans rien en cache.
Faut-il viser 100 sur 100 ?
Non, et l’objectif est même contre-productif. Les derniers points se paient en contorsions techniques dont l’effet sur l’expérience réelle est nul ou négatif. Ce qui compte se lit dans la partie haute, sur les seuils publiés, et une page peut très bien passer les Core Web Vitals avec un score de laboratoire imparfait.
À quelle fréquence relancer le test ?
Le test de laboratoire se relance à chaque correction, puisqu’il répond dans la seconde. La partie mesurée se regarde à intervalle plus long, quelques semaines après un déploiement, le temps que la fenêtre de 28 jours se renouvelle. Relancer la seconde tous les jours ne produit que du bruit.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.