Google PageSpeed Insights délivre en moins de trente secondes un diagnostic complet de la vitesse perçue d’une URL, et c’est l’outil officiel auquel se réfère l’algorithme Page Experience. Selon HTTP Archive, le score Lighthouse moyen des sites WordPress en 2026 stagne à 47/100 sur mobile et 78/100 sur desktop, ce qui laisse une marge confortable pour quiconque comprend les métriques affichées. Cet outil gratuit reste au cœur de tout SEO technique sérieux et alimente directement les Core Web Vitals que Google utilise comme signal de classement.

Google PageSpeed Insights : ce que l’outil mesure réellement
Réponse directe : PageSpeed Insights combine deux sources de données. Les données terrain (CrUX, Chrome User Experience Report) proviennent des visites réelles enregistrées par Chrome sur les 28 derniers jours. Les données de laboratoire (Lighthouse) sont issues d’un audit simulé en conditions standardisées : connexion 4G, processeur mobile mid-tier, écran 360×640. Seules les données terrain influencent le classement.
L’outil renvoie six métriques principales : LCP (Largest Contentful Paint, temps d’affichage du plus grand élément), INP (Interaction to Next Paint, réactivité aux clics et taps), CLS (Cumulative Layout Shift, instabilité visuelle), FCP (First Contentful Paint, premier pixel utile), TTFB (Time To First Byte, réponse serveur) et TTI (Time To Interactive). Les trois premières forment les Core Web Vitals.
Les seuils que Google considère bons
Pour passer en zone verte : LCP inférieur à 2,5 secondes, INP inférieur à 200 millisecondes, CLS inférieur à 0,1. Mueller a précisé en 2024 que ces seuils sont mesurés au 75e percentile, ce qui signifie qu’au moins 75 % des visites réelles doivent rester sous le seuil. Une seule métrique en rouge fait basculer toute l’URL en « ne respecte pas les Core Web Vitals » dans la Search Console.
Interpréter le rapport sans se tromper
Le score global Lighthouse (entre 0 et 100) est une note synthétique pondérée, pas un signal Google. Une page peut afficher 65/100 et respecter les Core Web Vitals sur le terrain. Inversement, une page à 95/100 en lab peut échouer sur INP si l’audit ne déclenche pas les scripts lourds. Nous regardons toujours d’abord la section CrUX en haut de la page, puis seulement ensuite les opportunités Lighthouse.

Le bouton mobile/desktop change tout
Depuis l’index Mobile-First, la version mobile est celle que Google évalue pour le classement. Nous ignorons le score desktop sauf pour les audits B2B où le trafic mobile reste minoritaire. Search Engine Journal a documenté en 2025 que 73 % des sites français analysés affichaient un écart de plus de 25 points entre les deux versions, presque toujours au détriment du mobile.
Les sept erreurs les plus fréquentes et leurs correctifs
Premièrement, les images non optimisées. Convertir en WebP, redimensionner aux dimensions réelles d’affichage et ajouter loading= »lazy » sur les images sous la ligne de flottaison récupère typiquement 1,2 seconde de LCP. Deuxièmement, le JavaScript bloquant. L’attribut defer ou async sur les scripts non critiques libère le thread principal. Troisièmement, l’absence de cache navigateur, corrigeable en quelques lignes dans le .htaccess via les en-têtes Cache-Control et Expires.
Quatrièmement, le CSS critique non inliné, qui retarde le premier rendu. Cinquièmement, les polices web chargées sans font-display: swap, ce qui produit un flash de texte invisible. Sixièmement, l’absence de CDN sur les assets statiques, problème majeur sur les hébergements partagés français. Septièmement, les plugins WordPress mal codés (sliders, page builders) qui injectent 300 Ko de scripts par page.
Notre méthode de correction en deux semaines
Semaine 1 : audit complet via PageSpeed Insights sur 10 URL représentatives, croisé avec Screaming Frog pour identifier les ressources qui pèsent. Semaine 2 : correction d’abord du LCP (le plus visible), ensuite du CLS (le plus simple), enfin de l’INP (le plus complexe). Sur referencement-top.fr, cette routine a fait passer le score mobile moyen de 54 à 89 en treize jours.
Le suivi sur la durée : alertes et tableau de bord
PageSpeed Insights ne fournit pas d’historique. Pour suivre l’évolution, nous croisons trois sources. La Search Console affiche le rapport Core Web Vitals consolidé par URL, mis à jour quotidiennement. PageSpeed Insights API (gratuite, 25 000 requêtes par jour) permet d’automatiser des relevés via un script Python. Pour des organisations plus matures, des outils comme SpeedCurve ou Calibre fournissent un monitoring continu avec alertes.

Ce que Google ne dit pas, mais qu’Illyes a laissé entendre lors du Search Central Live de Zurich 2024 : un site qui améliore ses Core Web Vitals sur l’ensemble de ses URL gagne plus rapidement que celui qui les améliore seulement sur la home et quelques pages phares. La cohérence sitewide compte. Un audit SEO ne devrait jamais traiter PageSpeed comme une métrique vanité : c’est un signal de classement direct mesuré au quotidien.
Questions fréquentes sur Google PageSpeed Insights
Faut-il viser 100/100 sur Lighthouse ?
Non. L’objectif réel est d’avoir les trois Core Web Vitals au vert sur les données terrain. Un score Lighthouse de 85 à 95 sur mobile avec CrUX valide suffit largement pour un classement optimal.
Pourquoi mon score varie entre deux tests ?
La partie Lighthouse fonctionne en condition simulée mais soumise à des variations du serveur Google et à la charge réseau du moment. Nous effectuons toujours trois tests à dix minutes d’intervalle et retenons la médiane. Les données terrain CrUX, elles, restent stables car elles agrègent 28 jours de visites.
Existe-t-il une alternative gratuite et fiable ?
WebPageTest.org reste la référence pour des tests approfondis multi-régions avec waterfall complet. GTmetrix combine Lighthouse et son propre engine. Pour un suivi sitewide automatisé, Treo Site Speed offre 500 mesures gratuites mensuelles.
