PageSpeed Insights : quel score viser et lesquels ignorer

Un score de 47 sur mobile, 89 sur desktop. Deux chiffres, deux couleurs, et une question immédiate : faut-il tout revoir ou peut-on dormir tranquille ? PageSpeed Insights affiche tellement de métriques, de diagnostics et de suggestions que la plupart des propriétaires de sites finissent soit par tout ignorer, soit par perdre des heures sur des optimisations sans impact réel. La clé, c’est de savoir lire ce rapport correctement : identifier les indicateurs qui pèsent sur le référencement, ceux qui influencent l’expérience utilisateur, et ceux qui ne sont que du bruit. C’est exactement ce que je détaille dans ce guide.

Ce que PageSpeed Insights mesure réellement

PageSpeed Insights n’est pas un simple compteur de vitesse. L’outil combine deux types de données complètement différents pour évaluer la performance d’une page web. Le premier type, ce sont les données de terrain (aussi appelées données réelles ou Field Data). Elles proviennent du Chrome User Experience Report (CrUX), une base de données alimentée par les navigateurs Chrome des utilisateurs réels qui visitent votre site. Le second type, ce sont les données de laboratoire, générées par Lighthouse, un outil d’audit automatisé qui simule un chargement dans des conditions contrôlées.

La confusion la plus fréquente consiste à traiter le score Lighthouse (le gros chiffre coloré) comme un verdict définitif. Ce score n’est qu’une simulation. Il reflète un chargement effectué sur un serveur Google, avec un bridage CPU et réseau artificiel, sur une configuration matérielle précise. Votre site peut afficher un score de 55 dans Lighthouse et se charger en moins de deux secondes pour 90 % de vos visiteurs réels. C’est la section « Évaluation des Core Web Vitals » tout en haut du rapport qui donne le verdict réel, celui que Google utilise pour le classement.

Données terrain vs données de laboratoire

Quand vous entrez une URL dans PageSpeed Insights, le rapport affiche d’abord un bandeau vert « Réussite », orange « À améliorer » ou rouge « Échec » basé sur les données terrain des 28 derniers jours. Cette évaluation agrège les expériences de vos vrais visiteurs. Si ce bandeau est vert, votre site passe les critères de performance de Google, quel que soit le score Lighthouse affiché plus bas.

Les données de laboratoire, elles, servent à diagnostiquer les problèmes. Elles décomposent le chargement en étapes mesurables : premier affichage, temps de blocage, décalage visuel. C’est un outil de travail pour les développeurs, pas un indicateur de ranking. Pour bien comprendre comment votre hébergement influence ces résultats, je recommande de lire mon article sur le diagnostic d’un site lent avant d’installer un plugin de cache.

Certains sites récents ou à faible trafic n’ont aucune donnée terrain disponible. PageSpeed Insights affiche alors « Les données du rapport sur l’expérience utilisateur de Chrome ne sont pas disponibles ». Dans ce cas, il faut se fier uniquement aux données de laboratoire, tout en gardant en tête qu’elles représentent un scénario pessimiste. Selon la documentation officielle de Google sur PageSpeed Insights, les données terrain nécessitent un volume de trafic suffisant pour être statistiquement fiables.

Core Web Vitals : les trois métriques qui comptent pour Google

Depuis 2021, Google utilise les Core Web Vitals comme signal de classement. En 2024, la métrique FID (First Input Delay) a été remplacée par INP (Interaction to Next Paint). Voici les trois métriques à surveiller, avec leurs seuils officiels :

Le LCP est souvent le plus impactant. Il dépend de la vitesse du serveur (TTFB), du poids de l’image ou du bloc de texte principal, et de la chaîne de chargement CSS/JS. Si votre LCP dépasse 2,5 secondes dans les données terrain, c’est la première métrique à corriger. L’optimisation des images joue un rôle majeur : je détaille les formats et poids cibles dans mon guide sur la compression d’images en WebP et AVIF.

L’INP mesure la latence entre une action utilisateur (clic, toucher, appui clavier) et la mise à jour visuelle qui en résulte. Un INP élevé trahit un JavaScript lourd qui bloque le thread principal. Les sites WordPress avec beaucoup de plugins sont particulièrement concernés.

Le CLS quantifie les sauts visuels. Une publicité qui pousse le contenu vers le bas, une image sans dimensions explicites, une police web qui provoque un flash : autant de causes de CLS élevé. L’implémentation du lazy loading peut d’ailleurs aggraver le CLS si elle est mal configurée.

Comprendre le score de performance Lighthouse

Le score de 0 à 100 affiché par PageSpeed Insights est calculé par Lighthouse à partir de cinq métriques pondérées. Chaque métrique contribue un pourcentage au score final :

• Total Blocking Time (TBT) : 30 % du score. Mesure le temps pendant lequel le thread principal est bloqué par du JavaScript.
• Largest Contentful Paint (LCP) : 25 %. Le temps d’affichage du contenu principal.
• Cumulative Layout Shift (CLS) : 25 %. La stabilité visuelle.
• First Contentful Paint (FCP) : 10 %. Le moment où le premier élément apparaît à l’écran.
• Speed Index (SI) : 10 %. La vitesse à laquelle le contenu visible se remplit progressivement.

Le TBT pèse à lui seul presque un tiers du score. C’est pour cette raison qu’un site avec beaucoup de JavaScript (outils de tracking, chat en direct, carrousels animés) affiche souvent un score faible même si le site semble rapide à l’œil. La minification des fichiers CSS et JS peut améliorer ce score, mais le gain réel dépend du volume de code exécuté, pas seulement de sa taille.

Les seuils de couleur sont simples : 0 à 49 en rouge (mauvais), 50 à 89 en orange (à améliorer), 90 à 100 en vert (bon). Mais un score orange ne signifie pas que votre site est pénalisé par Google. Le score Lighthouse n’est pas un facteur de classement direct. Ce sont les Core Web Vitals terrain qui comptent.

Score mobile vs desktop : pourquoi l’écart est normal

L’une des situations les plus fréquentes : un score desktop de 92 et un score mobile de 54. Cet écart provoque souvent de la panique, mais il est parfaitement normal. Lighthouse mobile simule un appareil Moto G Power avec un CPU bridé à environ 4x plus lent qu’un ordinateur de bureau, sur une connexion 4G simulée (débit limité, latence ajoutée). Ces conditions sont volontairement pessimistes.

En réalité, la plupart des smartphones modernes sont nettement plus puissants que le Moto G Power utilisé comme référence. Un iPhone 14 ou un Samsung Galaxy S23 exécute le JavaScript trois à cinq fois plus vite que la simulation Lighthouse. L’écart de score ne reflète donc pas l’expérience réelle de la majorité de vos visiteurs mobiles.

Cela dit, Google utilise l’indexation mobile-first. Les Core Web Vitals pris en compte pour le classement sont ceux mesurés sur mobile. Il faut donc s’assurer que les données terrain mobiles (section CrUX du rapport) restent dans le vert, même si le score Lighthouse mobile est orange. La qualité de l’hébergement joue un rôle essentiel ici : un serveur lent à répondre pénalise le TTFB sur toutes les connexions. Mon comparatif sur les différences entre mutualisé, VPS et dédié peut vous aider à évaluer si votre infrastructure est adaptée.

Les recommandations à traiter en priorité

PageSpeed Insights liste des « opportunités » et des « diagnostics » sous le score. La tentation est de tout traiter dans l’ordre affiché, mais certaines recommandations ont un impact dix fois supérieur aux autres. Avec plus de dix ans d’expérience en optimisation de sites, voici la hiérarchie que j’applique systématiquement :

Priorité haute (impact direct sur les Core Web Vitals) :

• Réduire le temps de réponse initial du serveur : si le TTFB dépasse 600 ms, aucune optimisation front-end ne compensera. Il faut revoir le système de cache serveur ou changer d’hébergeur.
• Dimensionner correctement les images : servir une image de 2 400 px de large pour un conteneur de 800 px gaspille de la bande passante et ralentit le LCP.
• Supprimer le JavaScript inutilisé : chaque kilooctet de JS doit être parsé et exécuté. Désactivez les plugins WordPress que vous n’utilisez plus.
• Définir des dimensions explicites sur les images et les iframes : sans attributs width et height, le navigateur ne peut pas réserver l’espace, ce qui provoque du CLS.

Priorité moyenne (amélioration de l’expérience sans impact SEO direct) :

• Utiliser des formats d’image nouvelle génération : WebP et AVIF réduisent le poids de 25 à 50 % par rapport au JPEG. Consultez mon guide sur la compression WebP et AVIF pour les détails.
• Activer la compression de texte : Gzip ou Brotli sur le serveur. La plupart des hébergeurs modernes l’activent par défaut.
• Précharger le LCP : ajouter un lien preload pour l’image ou la police qui constitue le Largest Contentful Paint.

Les alertes que vous pouvez ignorer sans risque

Certaines recommandations de PageSpeed Insights sont techniquement correctes mais n’ont aucun impact mesurable sur les performances réelles ou le référencement. Les voici, avec l’explication de pourquoi vous pouvez les laisser de côté :

« Éliminer les ressources qui bloquent le rendu » : cette alerte concerne les fichiers CSS et JS chargés dans le head. La recommandation théorique est de tout inliner ou différer. En pratique, inliner le CSS critique est complexe à maintenir, et différer tout le JS peut casser des fonctionnalités. Si votre FCP et votre LCP sont bons, cette alerte est du bruit.

« Réduire le CSS inutilisé » : les outils de purge CSS automatique (PurgeCSS, UnCSS) suppriment parfois des styles nécessaires aux pages non testées. Le gain est souvent de quelques dizaines de kilooctets, ce qui ne change rien au LCP. À traiter uniquement si votre CSS dépasse 200 Ko non compressé.

« Éviter les redirections de page » : si vous redirigez http vers https ou www vers non-www, c’est une bonne pratique de sécurité. PageSpeed le signale quand même. Ignorez cette alerte pour les redirections canoniques.

« Diffuser des éléments statiques grâce à des règles de cache efficaces » : cette alerte apparaît souvent pour les scripts tiers (Google Analytics, Facebook Pixel, fonts Google). Vous n’avez aucun contrôle sur les en-têtes de cache de ces domaines. La seule solution serait de les héberger localement, ce qui pose d’autres problèmes (mises à jour, conformité). Passez votre chemin.

Le score d’accessibilité, de bonnes pratiques et de SEO : ces onglets sont utiles mais indépendants du score de performance. Un score SEO Lighthouse de 82 ne signifie pas que votre référencement est mauvais. Ces audits vérifient des basiques (balise title présente, meta viewport, contraste des couleurs) et ne remplacent pas un vrai audit SEO. Le guide de performance Lighthouse sur web.dev détaille la méthodologie complète.

Quel score viser selon votre type de site

Il n’existe pas de score universel à atteindre. La cible dépend de votre type de site, de votre stack technique et de votre audience. Voici les repères que j’utilise pour cadrer les attentes :

Un site WooCommerce avec un score mobile de 45 peut très bien avoir des Core Web Vitals terrain au vert. L’inverse est aussi vrai : un site statique à 95 peut avoir un LCP terrain dégradé si le serveur est lent ou si le CDN est mal configuré. Pour comprendre comment un CDN améliore le temps de réponse, consultez mon article sur ce que change réellement un CDN sur un site français.

La règle que j’applique est simple : les Core Web Vitals terrain passent avant le score Lighthouse. Si les trois métriques CrUX sont au vert, ne perdez pas de temps à gratter 10 points de score. Si elles sont au rouge, le score Lighthouse ne sert qu’à identifier les causes.

Pour les sites WordPress, la version de PHP utilisée a un impact direct sur le TTFB et donc sur le LCP. Passer de PHP 7.4 à PHP 8.2 peut réduire le temps de réponse serveur de 20 à 40 %. J’explique la procédure et les risques dans mon guide pour mettre à jour la version de PHP.

Enfin, n’oubliez pas que PageSpeed Insights ne teste qu’une seule page à la fois. Votre page d’accueil peut obtenir 90 tandis qu’une page produit avec dix images haute résolution plafonne à 40. Testez au minimum la page d’accueil, une page intérieure type et la page la plus lourde de votre site pour avoir une image complète. Si vous constatez que votre base de données ralentit le chargement, le nettoyage des révisions, transients et tables orphelines peut faire gagner plusieurs centaines de millisecondes sur le TTFB.