Tester la vitesse d’une page avec PageSpeed Insights

Comment utiliser l’outil

Saisissez l’adresse d’une page, avec ou sans « https:// », choisissez l’appareil simulé et lancez le test. L’outil demande l’analyse à l’API PageSpeed Insights, la même que celle du site pagespeed.web.dev. Google charge la page depuis ses propres serveurs et renvoie ses mesures.²

Le résultat s’ouvre sur un résumé : la page analysée, l’appareil, la date et le score de performance. Viennent ensuite deux blocs bien séparés, les données de terrain puis les données de laboratoire, et enfin les principales pistes d’amélioration avec le gain annoncé. Un lien mène au rapport complet sur pagespeed.web.dev, qui détaille chaque audit.

Données de terrain et données de laboratoire

Les deux blocs ne mesurent pas la même chose et il ne faut pas les additionner. Les données de terrain viennent de vrais visiteurs qui utilisent Chrome : l’API les tire du Chrome User Experience Report, le CrUX.² Elles décrivent l’expérience vécue sur la page, avec la diversité des appareils, des réseaux et des comportements. Les données de laboratoire sont produites par Lighthouse, qui charge la page une fois dans des conditions contrôlées et simulées.²

Les deux sources divergent pour des raisons connues. Le laboratoire utilise un seul appareil, un seul réseau et souvent un cache vide, alors que les visiteurs de retour profitent du cache ou de la restauration instantanée des pages. Sur le terrain, l’élément le plus grand de la page peut varier d’un écran à l’autre, et le décalage de mise en page tient compte de ce qui se passe pendant le défilement ou après un clic.⁵

La conduite que recommande web.dev tient en deux temps : se fier aux données de terrain pour décider des priorités, car elles reflètent ce que vivent les visiteurs, et se servir du laboratoire pour diagnostiquer un problème et vérifier qu’une correction fonctionne.⁵ Une page peu visitée n’a pas de données de terrain, et l’outil l’écrit dans ce cas.

Les trois mesures de terrain et leurs seuils

Les Core Web Vitals sont au nombre de trois. Le Largest Contentful Paint (LCP) mesure le moment où le plus grand élément visible s’affiche : le seuil « bon » est de 2,5 secondes. L’Interaction to Next Paint (INP) mesure la réactivité aux clics, touches et appuis : le seuil « bon » est de 200 millisecondes. Le Cumulative Layout Shift (CLS) mesure les déplacements inattendus du contenu pendant le chargement : le seuil « bon » est de 0,1.¹

Google demande que ces seuils soient atteints au 75e centile des chargements de page, séparément sur mobile et sur ordinateur. Concrètement, 75 % des visites doivent faire au moins aussi bien que le seuil. Une page est considérée comme conforme quand les trois mesures le sont.¹ L’outil affiche la valeur au 75e centile renvoyée par l’API et reprend la catégorie que Google lui attribue, avec le seuil « bon » rappelé sous chaque ligne.

Le score de performance Lighthouse

Le score affiché en tête, de 0 à 100, vient du laboratoire. Lighthouse le répartit en trois bandes de couleur : de 90 à 100 pour le vert, de 50 à 89 pour l’orange, de 0 à 49 pour le rouge. Il est calculé à partir de cinq mesures de laboratoire : First Contentful Paint, Speed Index, Largest Contentful Paint, Total Blocking Time et Cumulative Layout Shift. Les pistes d’amélioration n’entrent pas dans le calcul, même si les appliquer fait souvent monter ces mesures.⁴

Ce score bouge d’une analyse à l’autre. La documentation de Lighthouse cite parmi les causes les tests A/B, les publicités, les changements de routage réseau, les différences d’appareils et les extensions de navigateur, et conseille de voir la performance comme une distribution de scores plutôt que comme une valeur unique.⁴ Relancez le test après avoir attendu les 10 minutes de cache si vous voulez une seconde mesure.

Les pistes d’amélioration

Sous les mesures, l’outil liste les audits de Lighthouse qui annoncent un gain, classés du plus important au plus faible : gain de temps estimé, en secondes, et gain de poids, en kilo-octets ou mégaoctets quand l’audit en donne un. Le texte de chaque piste est celui de Lighthouse, dans votre langue. Ces gains sont des estimations faites en laboratoire : ils indiquent où chercher, et le résultat réel sur le terrain peut différer.

Pour une page qui échoue sur le LCP, les pistes d’images et de chargement des ressources bloquantes sont le premier endroit à regarder. Pour une page qui échoue sur l’INP, le laboratoire n’est pas fiable : il ne peut pas prédire cette mesure, qui dépend des interactions réelles.⁵ Il faut alors passer par le terrain et par les outils de développement du navigateur.

La vitesse compte-t-elle pour le classement ?

Google répond sur sa page consacrée à l’expérience sur la page. Il n’existe pas de signal unique : ses systèmes de classement regardent plusieurs signaux, dont les Core Web Vitals. Un bon résultat ne garantit pas une place en tête, et Google précise que la pertinence du contenu reste prioritaire, une bonne expérience de page aidant surtout quand beaucoup de contenus utiles répondent à une même requête.⁶

Pour un site vitrine, la vitesse sert donc d’abord les visiteurs. Un site lent perd des gens avant qu’ils aient lu la première ligne, quel que soit son effet sur le classement. Corriger ce qui fait échouer l’une des trois mesures de terrain rapporte plus qu’un score de 100 visé pour le seul SEO.⁶

Ce que l’outil fait, et ses limites

L’outil interroge l’API gratuite de Google avec le paramètre category sur « performance » : il ne rend donc ni l’accessibilité, ni les bonnes pratiques, ni le SEO de Lighthouse. Le choix mobile ou ordinateur est envoyé explicitement, car sans lui l’API analyse l’ordinateur.³

L’API a un quota. Elle fonctionne sans clé, mais la documentation recommande d’en utiliser une pour les requêtes fréquentes ou automatisées.² Quand le quota est atteint, l’outil le dit et propose le lien vers le rapport sur pagespeed.web.dev. La documentation signale aussi que Google prévoit de retirer les données de terrain de cette API et renvoie vers l’API CrUX : si cela arrive, le bloc terrain de l’outil restera vide et l’outil le dira.²

Les adresses locales, privées ou à identifiants sont refusées. Aucune adresse testée n’est conservée au-delà des 10 minutes de cache, qui ne contient que les mesures publiques renvoyées par Google.

Après le test

Un test de vitesse ne couvre qu’un aspect d’une page. Pour contrôler le reste de ses balises, de ses titres et de ses liens, l’audit SEO on-page en fait la synthèse en une analyse. La vitesse est aussi un des points de la checklist pour auditer son site. Quand les mesures de terrain échouent et que les corrections demandent un travail technique, c’est le cadre de l’accompagnement SEO que je mène pour mes clients.

Questions fréquentes