Score PageSpeed à 42 en orange sur mobile, avec une longue liste de recommandations techniques : plutôt que de se demander par où commencer, la vraie question est de distinguer les "lab data" (score Lighthouse, environnement contrôlé) des "field data" (données CrUX, expérience réelle des utilisateurs), une nuance rarement expliquée en France, alors qu'elle est déterminante pour le SEO : un score vert peut cacher une mauvaise expérience réelle, et un score orange peut coexister avec des Core Web Vitals parfaitement valides.
Qu'est-ce que PageSpeed Insights ?
PageSpeed Insights (PSI) est un outil gratuit développé et maintenu par Google. Il analyse la performance d'une URL et produit deux types de données distincts : des données de laboratoire générées par Google Lighthouse, et des données de terrain issues de l'expérience réelle des utilisateurs Chrome (CrUX).
L'outil est accessible directement via pagespeed.web.dev. Il ne nécessite aucune installation, aucun compte Google. Vous collez une URL, vous attendez quelques secondes, vous obtenez l'analyse. PageSpeed Insights est gratuit et sans limite d'appels via l'interface web. Une API existe pour automatiser les analyses ou les intégrer dans des outils de CI/CD (clé API Google Cloud requise pour les appels en volume). Pour la grande majorité des usages éditoriaux et SEO, l'interface web suffit.
PSI analyse chaque URL individuellement. Ce n'est pas un outil d'audit de site complet. Si votre page d'accueil a un score de 95 mais que vos fiches produit chargent lentement, PSI ne vous le dira que si vous testez chaque fiche.
Lab data vs Field data (CrUX) : la différence cruciale
C'est le point que les guides francophones ignorent, et c'est celui qui compte le plus pour votre SEO. PageSpeed Insights affiche deux blocs de données. En haut : les "données de terrain" (field data), issues de l'expérience réelle des visiteurs Chrome sur votre page au cours des 28 derniers jours. En bas : les "données de lab" (lab data), issues d'un test Lighthouse simulé dans un environnement contrôlé.
Google les distingue ainsi :
"Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience, but has a more limited set of metrics."
Google Developers, About PageSpeed Insights, mis à jour 21 octobre 2024 (source : https://developers.google.com/speed/docs/insights/v5/about)
Le score 0-100 affiché en haut de l'interface (score Lighthouse) est une donnée de lab, calculée depuis un seul test simulé dans un datacenter Google, ce n'est pas ce sur quoi repose votre classement. Google se base sur les Core Web Vitals en field data, mesurés depuis les navigateurs réels de vos visiteurs via CrUX sur 28 jours glissants.
Résultat : un site à 42 en Lighthouse peut avoir des Core Web Vitals au vert en réel, et un site à 85 peut avoir un LCP dégradé sur le terrain. Piloter sa performance uniquement sur le score Lighthouse, c'est donc décider sur la mauvaise donnée : utile pour repérer des pistes techniques, mais pas pour savoir ce que Google mesure réellement. À noter : les données de terrain n'apparaissent que si le site a assez de trafic Chrome ; sinon, PSI l'indique et n'affiche que le lab.
Comment utiliser PageSpeed Insights
L'utilisation de base se fait en quatre étapes.
- Ouvrez pagespeed.web.dev dans votre navigateur
- Collez l'URL complète de la page à analyser (avec https://)
- Cliquez sur "Analyser" et attendez quelques secondes
- Lisez le rapport en commençant par les données de terrain, pas par le score
Un conseil pratique : testez d'abord la version mobile. PSI affiche les scores desktop et mobile séparément via deux onglets. Le score mobile est presque toujours plus bas, et c'est la version que Google utilise en priorité depuis le passage au mobile-first indexing.
Pour analyser plusieurs pages d'un même site, l'API PSI permet de lancer des tests automatisés et de stocker les résultats. Pour un audit ponctuel manuel, commencez par les pages stratégiques : page d'accueil, pages d'atterrissage principales, pages catégorie ou article à fort trafic.
Lire le score et les couleurs (vert, orange, rouge)
Le score PSI va de 0 à 100. Il est affiché en haut du rapport, avec un code couleur.
- Vert (90-100) : bonne performance. Le score Lighthouse composite est élevé, les métriques de lab sont dans les seuils recommandés.
- Orange (50-89) : performance à améliorer. Des optimisations sont possibles sur plusieurs métriques.
- Rouge (0-49) : performance faible. Des problèmes significatifs ralentissent la page.
Ces seuils s'appliquent au score global. Chaque métrique individuelle (LCP, CLS, INP, FCP, Speed Index) a ses propres seuils, affichés avec le même code couleur. Ce score composite agrège plusieurs métriques de lab pondérées. Deux d'entre elles pèsent particulièrement lourd : le Largest Contentful Paint et le Total Blocking Time. Or le Total Blocking Time, qui influence fortement le score composite, n'est pas un Core Web Vital : il n'entre pas directement dans le signal de classement de Google.
À l'inverse, le LCP est un Core Web Vital officiel. Le score Lighthouse optimise donc pour une vision de la performance qui ne recoupe pas exactement ce que Google mesure pour le classement. Lisez donc les métriques individuellement. Un score global de 70 avec un LCP terrain dans le rouge est plus problématique qu'un score de 60 avec tous les CWV terrain dans le vert.
Core Web Vitals dans PSI : LCP, CLS, INP, FCP, TTFB, seuils chiffrés
Les Core Web Vitals sont les trois métriques que Google utilise comme signaux de classement : LCP, INP et CLS. PageSpeed Insights les affiche dans les deux formats : données terrain (field data, ce qui compte pour le SEO) et données de lab (lab data, pour le diagnostic).
| Métrique | Bon | À améliorer | Mauvais |
|---|---|---|---|
| LCP (Largest Contentful Paint) | < 2,5 s | 2,5 - 4 s | > 4 s |
| INP (Interaction to Next Paint) | < 200 ms | 200 - 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | < 0,1 | 0,1 - 0,25 | > 0,25 |
| FCP (First Contentful Paint) | < 1,8 s | 1,8 - 3 s | > 3 s |
| TTFB (Time to First Byte) | < 800 ms | 800 ms - 1,8 s | > 1,8 s |
Source : web.dev, seuils officiels Core Web Vitals et métriques de chargement.
Depuis mars 2024, l'INP (Interaction to Next Paint) a remplacé le FID comme Core Web Vital officiel. Le FID a disparu de PageSpeed Insights, et les deux métriques ne sont pas comparables, l'INP mesurant toutes les interactions là où le FID ne mesurait que la première. Autre point clé : les seuils s'appliquent au 75e centile (P75) des données terrain, plus exigeant que la médiane, car la performance sur connexions lentes et appareils anciens compte pleinement.
Le Largest Contentful Paint est la métrique sur laquelle concentrer l'effort en priorité. Elle pèse lourd dans le score Lighthouse, mais surtout elle conditionne la perception de vitesse : c'est le moment où le contenu principal est visible. Un LCP élevé signifie que l'utilisateur attend.
Le Speed Index, lui, n'est pas un Core Web Vital. C'est une métrique Lighthouse qui mesure la progression visuelle du chargement. Comme le Total Blocking Time, il est utile pour le diagnostic (voir à quel rythme le contenu s'affiche) mais il n'entre pas dans le signal de classement de Google.
Interpréter les recommandations Lighthouse
Sous les métriques, PageSpeed Insights affiche trois blocs de recommandations : "Opportunités" (avec une estimation de gain en secondes), "Diagnostics" (problèmes sans estimation directe) et "Éléments réussis" (métriques déjà dans les clous).
Les opportunités sont classées par impact estimé. Commencez par les premières. L'estimation en secondes est approximative, car elle est calculée sur vos métriques de lab, pas sur votre trafic réel, mais elle donne une hiérarchie pertinente. Les recommandations les plus fréquentes et leur signification réelle :
- Éliminer les ressources bloquant le rendu : des fichiers CSS ou JavaScript sont chargés en mode bloquant dans le <head> de votre page. Pendant leur chargement, le navigateur ne peut pas afficher de contenu. Impact : FCP et LCP. Le correctif typique consiste à utiliser defer ou async sur les scripts non critiques et à charger le CSS non critique de manière asynchrone.
- Différer les images hors écran : des images situées sous la ligne de flottaison sont chargées dès le début du chargement de la page. C'est du lazy loading manquant. Impact : LCP et TBT. Le correctif : ajouter l'attribut loading="lazy" sur les images hors écran.
- Réduire le temps de réponse du serveur initial (TTFB) : le serveur met trop de temps à envoyer le premier octet. Impact direct sur le LCP. Les leviers : mise en cache serveur, CDN, optimisation des requêtes base de données.
- Encoder les images efficacement : vos images ne sont pas compressées ou utilisent des formats non optimaux. Passer à un format moderne comme le WebP ou l'AVIF réduit le poids des images à qualité visuelle équivalente.
- Les éléments d'image ont une taille incorrecte : vous servez des images en 1500 px sur un écran mobile qui les affiche en 400 px. Inutile pour l'affichage, coûteux en bande passante.
Ce que la plupart des articles ne disent pas sur ces recommandations : certaines ont un impact fort sur le score Lighthouse mais un impact limité sur les CWV terrain, et inversement. Si votre objectif est le classement SEO, les CWV terrain priment. Si votre objectif est d'améliorer le score composite (pour un dashboard ou un reporting client), les opportunités avec estimation de gain en secondes priment.
Comment améliorer son score PageSpeed Insights
Améliorer son score PSI, c'est un objectif de lab. Améliorer ses Core Web Vitals terrain, c'est un objectif SEO. Les deux se recoupent mais ne sont pas identiques. Ce guide traite les deux.
Le Largest Contentful Paint est dans le rouge sur une large part des sites que nous auditons. Les causes les plus fréquentes et leurs corrections directes :
Image LCP non préchargée : l'image la plus grande de votre page (souvent l'image hero) est découverte tard par le navigateur. Ajoutez <link rel="preload" as="image"> dans le <head> pour la découvrir dès le parsing HTML. Le gain sur le LCP peut être notable lorsque cette image est le point de blocage.
Image LCP en format JPEG ou PNG lourd : passez au format WebP ou AVIF. À qualité visuelle identique, le WebP réduit le poids des images de 25 à 34 % par rapport au JPEG selon les chiffres publiés par Google, et l'AVIF compresse encore davantage. Moins de kilo-octets à télécharger, LCP plus rapide.
CSS bloquant le rendu : si votre feuille de style principale est lourde et chargée en mode bloquant, le navigateur attend son téléchargement et son parsing avant d'afficher quoi que ce soit. Identifiez le CSS critique (le minimum nécessaire au premier affichage) et inlinez-le dans le <head>. Le CSS non critique peut être chargé en asynchrone.
TTFB élevé : si le serveur met plus de 800 ms à répondre, il ne reste pas assez de temps pour tenir le seuil LCP de 2,5 secondes. Avant de travailler sur le front, vérifiez votre TTFB.
Le CLS (Cumulative Layout Shift) mesure les décalages de mise en page inattendus. Les causes classiques : images sans dimensions définies, publicités ou embeds qui s'insèrent dynamiquement, polices web qui décalent le texte à l'affichage. Le correctif : toujours définir width et height sur vos images et iframes, et utiliser font-display: optional ou swap avec une police de repli bien calibrée.
Un TBT élevé et un INP dégradé ont souvent la même cause : du JavaScript qui monopolise le thread principal trop longtemps. Les tâches JavaScript qui durent plus de 50 ms bloquent toute interaction. Découpez les tâches longues, différez le JavaScript non critique, et évaluez si certains scripts tiers (chatbots, analytics lourds, A/B testing) peuvent être chargés de manière asynchrone ou conditionnelle.
Le chargement différé des JS et CSS non critiques avec defer et async, ainsi que la minification des fichiers CSS et JavaScript, réduisent le volume de code à charger et à exécuter au démarrage. Sur un site mal optimisé, ces deux actions combinées font souvent progresser sensiblement le score Lighthouse.
Pourquoi le score mobile est-il plus bas ?
Le score mobile PageSpeed Insights est systématiquement inférieur au score desktop, et ce n'est pas une anomalie mais une conséquence technique documentée. En mode mobile, Lighthouse simule un appareil d'entrée à milieu de gamme avec un throttling CPU 4x et une connexion à 150 ms de RTT, reflétant l'expérience d'une part significative des utilisateurs mobiles dans le monde, alors qu'en desktop les conditions sont bien moins contraintes (aucun throttling CPU, connexion rapide). Un même code JavaScript ou une même image met donc mécaniquement plus de temps à s'exécuter ou charger dans les conditions mobiles simulées, une question de ressources disponibles et non de rendu.
Concrètement, un score mobile de 45 face à un score desktop de 90 sur la même URL est parfaitement normal pour un site non optimisé mobile : l'écart n'a rien de mystérieux, c'est l'effet des conditions de test. La bonne question n'est donc pas "pourquoi mon score mobile est-il plus bas ?" mais "mes Core Web Vitals terrain, mesurés sur les vrais appareils de mes visiteurs, sont-ils dans les seuils recommandés ?" Si votre audience est majoritairement desktop, un score mobile faible a un impact limité sur votre SEO ; si elle est majoritairement mobile, c'est en revanche une priorité.
PageSpeed Insights vs Lighthouse vs GTmetrix vs WebPageTest
Ces quatre outils testent la performance web, mais ils ne sont pas interchangeables.
| Critère | PageSpeed Insights | Lighthouse | GTmetrix | WebPageTest |
|---|---|---|---|---|
| Données field (CrUX) | Oui | Non | Non | Non |
| Données lab | Oui | Oui | Oui | Oui |
| Test mobile | Oui | Oui (DevTools) | Oui | Oui |
| API disponible | Oui | Via CLI/CI | Oui | Oui |
| Gratuit | Oui | Oui | Freemium | Freemium |
| Choix de localisation | Non | Non | Partiel | Oui |
| Waterfall détaillé | Non | Non | Oui | Oui |
Quel outil pour quel usage ?
PageSpeed Insights reste l'outil de référence pour les données terrain (CrUX), le seul de cette liste à afficher le field data des utilisateurs réels, et le plus simple pour un diagnostic rapide. Lighthouse, intégré à Chrome DevTools, produit les mêmes données que la section lab de PSI mais offre plus de contrôle et peut tester des pages en authentification, en localhost ou en staging.
GTmetrix ajoute un waterfall détaillé et des métriques historiques : son score propriétaire compte moins pour le SEO que les CWV, mais le waterfall aide à identifier la ressource qui ralentit le LCP. WebPageTest, enfin, est le plus complet pour l'analyse de lab avancée : tests multi-localisations, vidéo frame par frame, comparaison de deux URLs, et analyse détaillée des phases DNS, TCP et TLS.
En pratique : PSI pour la donnée terrain et le diagnostic rapide, Lighthouse pour les environnements contrôlés (staging, authentification), WebPageTest pour les analyses poussées et les comparaisons géographiques. Voir aussi notre comparatif des outils de monitoring web pour le suivi en continu.
Questions fréquentes
Commencez par identifier la métrique la plus dégradée dans les données terrain (LCP, INP ou CLS). Chaque métrique a des leviers spécifiques : pour le LCP, préchargez l'image principale, réduisez le TTFB et passez au format WebP ; pour le CLS, définissez des dimensions sur vos images et iframes ; pour l'INP, découpez les tâches JavaScript longues et différez les scripts non critiques. Le score global suit quand les métriques individuelles s'améliorent.
Ouvrez pagespeed.web.dev, collez l'URL de la page à analyser et cliquez sur Analyser. Lisez d'abord le bloc "données de terrain" (Core Web Vitals réels), puis les opportunités et diagnostics dans la section lab. Testez toujours la version mobile en priorité : c'est celle que Google indexe en premier.
Le test mobile de Lighthouse applique un throttling CPU 4x et une connexion réseau simulée à 150 ms de RTT, reflétant les conditions d'un appareil mobile d'entrée de gamme. Sur desktop, ces contraintes n'existent pas. L'écart de score est mécanique, ce n'est pas une erreur.
PSI est fiable pour les données terrain (CrUX) : elles reflètent les vraies expériences des utilisateurs Chrome. Les données de lab (score Lighthouse) sont reproductibles mais sensibles aux conditions du moment. Pour un diagnostic robuste, comparez plusieurs analyses successives, car un seul test peut varier d'une exécution à l'autre.
Oui. L'interface web de PageSpeed Insights est gratuite et sans limite d'appels. L'API PSI est également gratuite mais nécessite une clé API Google Cloud, et des quotas s'appliquent au-delà d'un certain volume d'appels.
Le score Lighthouse composite (le chiffre 0-100) n'est pas un signal de classement direct. Ce que Google utilise pour le classement, ce sont les Core Web Vitals mesurés en données terrain (CrUX) :
"We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally."
Google Search Central, Core Web Vitals, mis à jour 10 décembre 2025 (source : https://developers.google.com/search/docs/appearance/core-web-vitals)
Autrement dit : optimiser votre score Lighthouse n'est pas directement un levier SEO. Obtenir un LCP, un CLS et un INP "bons" en données terrain l'est.
Le Speed Index mesure la vitesse à laquelle le contenu visuel de la page s'affiche progressivement. Il est calculé à partir de l'analyse des frames du chargement de la page dans Lighthouse. Un Speed Index bas indique que le contenu s'affiche rapidement, sans longue période d'écran blanc. Ce n'est pas un Core Web Vital et il n'impacte pas directement le classement Google, mais il contribue au score Lighthouse.
Les données de terrain (CrUX) dans PSI ne sont disponibles que si votre page ou votre domaine a suffisamment de trafic depuis des navigateurs Chrome pour constituer un échantillon statistiquement significatif. Google ne publie pas le seuil exact. Si votre page est récente, peu fréquentée ou majoritairement visitée depuis des navigateurs non-Chrome, PSI affiche uniquement les données de lab. Il peut falloir plusieurs semaines après la publication d'une page pour que les premières données CrUX apparaissent.
Le mot de la fin
PageSpeed Insights est l'outil le plus accessible pour diagnostiquer la performance de votre site. Mais il est souvent mal lu. Le score orange ou rouge en haut de l'interface n'est pas ce que Google mesure pour votre classement. Ce qui compte, c'est le bloc "données de terrain" : vos LCP, CLS et INP réels, mesurés depuis les appareils de vos vrais visiteurs.