PageSpeed Insights

PageSpeed Insights (PSI) est l'outil gratuit de Google qui évalue l'expérience de chargement d'une URL sur mobile et sur ordinateur. Il juxtapose deux sources : les données de terrain du Chrome User Experience Report, qui reflètent ce que vivent les vrais visiteurs sur 28 jours, et un audit de laboratoire réalisé par Lighthouse. Les premières comptent pour le classement Google, le second sert à trouver quoi corriger.

Définition détaillée de PageSpeed Insights

PageSpeed Insights est une interface web de Google, accessible sans compte à l'adresse pagespeed.web.dev, qui analyse une URL et rend compte de l'expérience de ses utilisateurs sur mobile et sur ordinateur, accompagnée de suggestions d'amélioration. Sa documentation résume la logique de l'outil en une phrase : il fournit à la fois des données de laboratoire et des données de terrain. Les données de laboratoire, collectées dans un environnement contrôlé, servent à déboguer ; elles peuvent rater des goulets d'étranglement réels. Les données de terrain, collectées auprès des vrais visiteurs, reflètent l'expérience réelle ; elles couvrent un jeu de métriques plus restreint.

L'outil a changé plusieurs fois de moteur au fil des versions de son API. Depuis la version 5 de son API, les versions antérieures ayant été dépréciées en novembre 2018 puis retirées en mai 2020, l'analyse de laboratoire est confiée à Lighthouse, dont PSI suit les versions à quelques jours d'écart : Lighthouse 12 y a été déployé le 10 mai 2024, Lighthouse 13 le 20 octobre 2025. L'interface a été refondue en novembre 2021, et un lien partageable du rapport, valable 30 jours, existe depuis mars 2023.

Pour le référenceur, PSI est le point d'entrée le plus simple vers les Core Web Vitals d'une page, les trois métriques de terrain que Google intègre à l'évaluation de l'expérience de page. C'est aussi l'outil le plus mal lu : le score de performance affiché en gros n'est pas celui que Google regarde.

Les données de terrain : ce que Google regarde

La partie haute du rapport, consacrée à ce que vivent les utilisateurs réels, vient du Chrome User Experience Report (CrUX), le jeu de données que Chrome collecte auprès des utilisateurs qui ont accepté de partager leurs statistiques. PSI y affiche, pour les 28 derniers jours, quatre métriques : le Largest Contentful Paint (LCP), l'Interaction to Next Paint (INP), le Cumulative Layout Shift (CLS) et le First Contentful Paint (FCP), plus le Time to First Byte (TTFB), présenté comme expérimental.

Les seuils et le 75e percentile

Chaque métrique est classée en trois catégories, alignées sur le programme Web Vitals : bonne, à améliorer, mauvaise. Les seuils documentés sont 2,5 s et 4 s pour le LCP, 200 ms et 500 ms pour l'INP, 0,1 et 0,25 pour le CLS, 1,8 s et 3 s pour le FCP, 0,8 s et 1,8 s pour le TTFB. PSI présente la distribution des expériences sous forme de trois barres, verte, orange et rouge, et affiche au-dessus la valeur du 75e percentile. Ce choix est expliqué dans la FAQ officielle : viser le 75e percentile garantit que la page fonctionne bien y compris dans les conditions d'appareil et de réseau les plus difficiles, et non seulement pour l'utilisateur médian.

L'évaluation Core Web Vitals

Le verdict « Core Web Vitals : réussite » ou « échec » repose sur ce 75e percentile. La page réussit si le LCP, l'INP et le CLS sont tous les trois dans la zone « bonne ». Si l'INP manque de données, le LCP et le CLS suffisent ; si le LCP ou le CLS manquent, la page ne peut pas être évaluée. Cette règle vaut à deux niveaux d'agrégation : l'URL analysée, et l'origine entière (tout le site). Quand une page n'a pas assez de visites pour figurer dans CrUX, PSI se rabat sur les données de l'origine, et l'indique ; quand l'origine elle-même manque de données, aucune donnée de terrain n'est affichée. La documentation précise les conditions d'inclusion : l'URL doit être publique, explorable et indexable, et disposer d'un nombre suffisant d'échantillons distincts. Une page en noindex ou un site confidentiel n'auront donc jamais de données de terrain.

Les données de terrain de PSI sont mises à jour quotidiennement, alors que le jeu de données CrUX sur BigQuery est publié mensuellement et se limite au niveau de l'origine. Les deux portent sur une fenêtre glissante de 28 jours : une correction mise en ligne aujourd'hui mettra jusqu'à quatre semaines à se refléter complètement dans le rapport.

Les données de laboratoire : ce que Lighthouse simule

La seconde partie du rapport, « Diagnostiquer les problèmes de performances », est un audit Lighthouse exécuté sur les serveurs de Google. Il produit un score de 0 à 100 dans quatre catégories, performance, accessibilité, bonnes pratiques et SEO ; 90 et plus est considéré comme bon, de 50 à 89 à améliorer, moins de 50 mauvais. Le score de performance est calculé à partir de métriques de laboratoire (FCP, LCP, Speed Index, CLS, Total Blocking Time), puis suivent les « insights » et diagnostics qui expliquent les pertes de temps : image LCP découverte trop tard, ressources bloquant le rendu, JavaScript inutilisé, polices, cache.

La FAQ officielle détaille les conditions de la simulation : pour le mobile, un appareil de milieu de gamme (un Moto G4) sur un réseau mobile ; pour l'ordinateur, un poste émulé sur connexion filaire. Le test tourne dans un centre de données Google situé en Amérique du Nord, en Europe ou en Asie, ce que le bloc « environnement » du rapport indique. En décembre 2024, Google a relevé le facteur de ralentissement du processeur pour tenir compte des machines peu puissantes de son infrastructure de production, ce qui a fait monter le Total Blocking Time mesuré sur mobile sans toucher aux données de terrain ni aux scores ordinateur.

Ce que le score ne dit pas

La question la plus fréquente sur PSI est celle d'une contradiction : de bonnes données de terrain avec un mauvais score de laboratoire, ou l'inverse. La réponse de Google tient en deux phrases. Les données de terrain sont un historique de l'URL, agrégé sur des visiteurs variés, avec leurs appareils et leurs réseaux ; les données de laboratoire viennent d'un chargement unique, sur un seul appareil et un jeu fixe de conditions réseau. Les valeurs peuvent donc différer, et la documentation ajoute qu'un bon score de laboratoire « ne signifie pas nécessairement que l'expérience des vrais utilisateurs sera bonne ».

Trois conséquences pratiques en découlent.

• Le score de performance n'est pas un signal de classement. Google utilise les Core Web Vitals de terrain. Un site peut afficher 40 en laboratoire et réussir l'évaluation Core Web Vitals, ou l'inverse. C'est la ligne « Core Web Vitals » de la section terrain qui compte.
• Le score varie sans que la page change. La FAQ cite la disponibilité du réseau, le matériel du client et la contention des ressources comme sources de variabilité. Deux analyses successives peuvent différer de plusieurs points.
• Le laboratoire ne mesure pas l'INP. Cette métrique de réactivité aux interactions n'existe qu'en données de terrain ; Lighthouse ne peut que l'approcher par le Total Blocking Time.

La lecture utile d'un rapport PSI se fait donc de haut en bas : d'abord le verdict Core Web Vitals sur 28 jours, en distinguant si les données affichées sont celles de l'URL ou de l'origine ; ensuite, si une métrique de terrain est dans l'orange ou le rouge, les diagnostics de laboratoire qui s'y rapportent ; enfin, une contre-vérification dans le rapport Core Web Vitals de la Search Console, qui regroupe les URL par gabarit et couvre tout le site.

L'API PageSpeed Insights

Tout ce que fait l'interface est disponible par une API REST, en version 5, sur le point d'entrée https://www.googleapis.com/pagespeedonline/v5/runPagespeed. Une requête GET prend au minimum le paramètre url ; les paramètres facultatifs sont strategy (mobile ou desktop, ce dernier étant la valeur par défaut, à l'inverse de l'interface), category (par défaut seule la performance est auditée ; on peut ajouter accessibility, best-practices et seo) et locale. La réponse est un objet JSON qui contient les données de terrain dans loadingExperience (URL) et originLoadingExperience (origine), et le rapport Lighthouse complet dans lighthouseResult. L'API fonctionne sans clé, mais Google recommande d'en créer une dans Google Cloud pour tout usage automatisé ou fréquent, et de l'ajouter en paramètre key.

Un changement est annoncé dans la documentation de l'API : Google prévoit de cesser d'y inclure les données de terrain de CrUX et renvoie vers l'API CrUX et l'API CrUX History pour ce besoin. Un script qui suit les Core Web Vitals d'un parc d'URL par l'API PSI a donc intérêt à migrer, et à ne garder PSI que pour la partie Lighthouse. Il faut aussi tenir compte du fait que la version de Lighthouse évolue indépendamment de la version de l'API, avec des changements de structure de réponse à chaque version majeure.

Les erreurs fréquentes

• Vendre ou acheter un score. Un « 100 sur PageSpeed » est une promesse fréquente des prestataires ; c'est un score de laboratoire sur une URL, un jour donné, qui ne dit rien des Core Web Vitals réels ni du classement.
• Ne tester que la page d'accueil. C'est souvent la page la plus soignée et la moins représentative. Les gabarits qui portent le trafic (fiches produit, articles, catégories) méritent chacun leur analyse.
• Lire les données d'origine comme celles de la page. Quand PSI se rabat sur l'origine, il le signale ; une page lente peut se cacher derrière une origine globalement bonne.
• Attendre un effet immédiat. La fenêtre de 28 jours lisse toute correction ; la donnée de terrain met un mois à refléter pleinement un changement.
• Tester en ordinateur par défaut dans l'API. Contrairement à l'interface, l'API analyse en mode ordinateur si le paramètre strategy est omis.

FAQ

Quelle est la différence entre le score PageSpeed et les Core Web Vitals ?

Le score de 0 à 100 est produit par Lighthouse lors d'un chargement simulé sur les serveurs de Google : c'est une donnée de laboratoire. Les Core Web Vitals affichés en haut du rapport viennent du Chrome User Experience Report et mesurent ce que les vrais visiteurs ont vécu sur 28 jours. Google utilise les seconds pour l'expérience de page, jamais le premier.

Pourquoi PageSpeed Insights n'affiche-t-il aucune donnée de terrain pour ma page ?

Selon la documentation, l'URL doit être publique, explorable et indexable, et recevoir assez de visites d'utilisateurs Chrome ayant activé le partage de statistiques. Une page récente, peu visitée, en noindex ou réservée à des utilisateurs connectés n'a pas de données. PSI se rabat alors sur l'origine, et si l'origine elle-même manque de données, seule la partie Lighthouse s'affiche.

Un score de 90 suffit-il pour réussir les Core Web Vitals ?

Non, les deux mesures sont indépendantes. La réussite Core Web Vitals exige que le 75e percentile du LCP, de l'INP et du CLS de terrain soit dans la zone « bonne ». Un score de laboratoire de 90 peut coexister avec un INP de terrain mauvais, car Lighthouse ne mesure pas les interactions réelles.

Combien de temps une correction met-elle à apparaître dans PageSpeed Insights ?

La partie laboratoire reflète la page immédiatement, à chaque nouvelle analyse. La partie terrain est mise à jour chaque jour mais porte sur les 28 derniers jours : une correction met jusqu'à quatre semaines à se refléter pleinement dans le verdict Core Web Vitals.

L'API PageSpeed Insights est-elle gratuite ?

Oui. Elle fonctionne même sans clé, mais Google recommande une clé d'API Google Cloud pour les usages automatisés. La documentation annonce que les données de terrain CrUX seront retirées de cette API : pour suivre les Core Web Vitals en masse, il faut passer par l'API CrUX ou l'API CrUX History.

En résumé

• PageSpeed Insights : outil gratuit de Google qui analyse une URL sur mobile et ordinateur, en combinant données de terrain (CrUX) et audit de laboratoire (Lighthouse).
• Terrain : LCP, INP, CLS, FCP et TTFB des vrais visiteurs sur 28 jours, au 75e percentile, avec repli sur l'origine si la page manque de données ; c'est cette partie que Google prend en compte.
• Laboratoire : score de 0 à 100 en performance, accessibilité, bonnes pratiques et SEO, sur un appareil et un réseau simulés ; bon à partir de 90, sans effet sur le classement.
• Réussite Core Web Vitals : LCP, INP et CLS de terrain tous dans la zone « bonne » au 75e percentile.
• API v5 : point d'entrée runPagespeed, paramètres strategy et category, clé recommandée ; les données CrUX doivent y être retirées au profit de l'API CrUX.

Abondance c'est aussi des audits SEO, un service de contenus et des formations en e-learning !