PageSpeed Insights est l’outil gratuit de Google qui analyse la vitesse d’une page web et lui attribue des scores sur 100, sur mobile et sur ordinateur. Son rapport réunit deux choses très différentes : ce que vivent réellement vos visiteurs (les données de terrain) et un test simulé en laboratoire, qui sert à trouver les causes. C’est la confusion entre les deux qui pousse à courir après un chiffre sans améliorer le site. Ce guide explique comment lire le rapport, quels seuils retenir, pourquoi la note change d’un test à l’autre, puis quelles sont les causes les plus fréquentes d’un mauvais score et comment les corriger. Pour les autres outils de test, voyez notre guide sur les outils gratuits pour tester la performance de son site.
En bref
- Le rapport mélange des données réelles (28 derniers jours) et un test simulé : lisez d’abord les données réelles.
- Les seuils à retenir : chargement sous 2,5 s, réactivité sous 200 ms, stabilité sous 0,1, au 75e centile des visites.
- Le score de performance varie d’un test à l’autre, même sans toucher au site : testez plusieurs fois.
- Les causes d’un score bas sont connues : images, scripts, polices, serveur, cache. Corrigez-les dans cet ordre.
Que mesure PageSpeed Insights ?
PageSpeed Insights produit, pour une page à la fois, un rapport sur l’expérience des utilisateurs sur mobile et sur ordinateur. Il combine deux sources de données : celles du terrain, issues de vrais visiteurs, et celles du laboratoire, issues d’un chargement simulé (Google, À propos de PageSpeed Insights).
| Critère | Données de terrain | Données de laboratoire |
|---|---|---|
| Origine | Utilisateurs réels de Chrome (rapport CrUX) | Un test simulé avec Lighthouse |
| Période | 28 derniers jours | Un seul chargement, à l’instant du test |
| Usage | Savoir ce que vivent vos visiteurs | Chercher l’origine d’un problème |
| Limite | Absentes si la page a trop peu de visites | Ne reflète pas toujours les vrais goulots d’étranglement |
Si une page n’a pas assez de données, Google affiche celles de l’ensemble du site, voire aucune. C’est fréquent sur un site récent ou peu visité : il ne faut pas y voir une erreur.
Comment lire un rapport PageSpeed Insights ?
Lisez le rapport de haut en bas, dans cet ordre : le terrain d’abord, le laboratoire ensuite. Le terrain dit si vos visiteurs sont bien servis ; le laboratoire dit pourquoi, et quoi corriger.
- Choisissez l’onglet. Commencez par « Mobile », puis regardez « Ordinateur » : les deux rapports sont indépendants.
- Lisez l’évaluation Core Web Vitals. Elle est réussie si les trois mesures (LCP, INP, CLS) sont bonnes au 75e centile des visites.
- Regardez les barres. Vert, orange, rouge : elles montrent la part des visites bonnes, moyennes et mauvaises pour chaque mesure.
- Passez aux scores de laboratoire. Quatre cercles, de la performance au SEO, avec les mêmes couleurs.
- Parcourez les diagnostics. Chaque piste d’amélioration est classée et expliquée ; commencez par celles qui concernent le LCP et le blocage du rendu.
Les trois Core Web Vitals ont chacun un seuil de « bon résultat » fixé par Google. Une valeur est jugée au 75e centile : trois visites sur quatre doivent faire mieux.
2,5 s
Chargement du plus grand élément visible (LCP) : à moins de 2,5 secondes du début du chargement. Au-delà de 4 s, c’est « médiocre ».
Source : web.dev, Google
200 ms
Réactivité (INP) : le temps entre un clic ou un toucher et la réponse de la page. Au-delà de 500 ms, c’est « médiocre ».
Source : web.dev, Google
0,1
Stabilité visuelle (CLS) : la page ne doit pas se décaler pendant le chargement. Au-delà de 0,25, c’est « médiocre ».
Source : web.dev, Google
Google précise que le 75e centile est retenu pour garantir une bonne expérience « dans les conditions d’appareil et de réseau les plus difficiles » : le chiffre ne décrit donc pas la visite moyenne, mais une visite plutôt défavorable (Google, À propos de PageSpeed Insights).
Que signifient les quatre scores sur 100 ?
Le rapport affiche quatre scores de laboratoire : performances, accessibilité, bonnes pratiques et SEO. Pour chacun, Google considère 90 et plus comme bon, de 50 à 89 comme à améliorer et moins de 50 comme médiocre. Seul le premier concerne la vitesse.
| Score | Ce qu’il évalue | Lien avec la vitesse |
|---|---|---|
| Performances | Le chargement et la réactivité de la page | Direct |
| Accessibilité | La lisibilité et l’utilisation par tous les visiteurs | Aucun |
| Bonnes pratiques | La qualité technique générale de la page | Faible |
| SEO | Les bases techniques pour être compris des moteurs | Aucun |
Le score de performances est une moyenne pondérée de cinq métriques. D’après la documentation de Lighthouse (pondérations de Lighthouse 10), le temps de blocage total pèse 30 %, le LCP et le CLS 25 % chacun, le premier affichage (FCP) et l’indice de vitesse 10 % chacun (Chrome for Developers). Les diagnostics, eux, ne comptent pas directement dans le score : les corriger l’améliore seulement de façon indirecte.
À retenir
Un score de laboratoire vert ne garantit pas que vos visiteurs vivent une bonne expérience. Google le dit lui-même : de bonnes données de laboratoire ne signifient pas nécessairement de bonnes expériences réelles.
D’où viennent les écarts de score d’un test à l’autre ?
Parce que la mesure dépend de conditions qui varient. Google indique que le score peut changer d’une exécution à l’autre sans aucune modification de la page, à cause de la disponibilité du réseau, du matériel et de la concurrence entre les processus de la machine (Google, À propos de PageSpeed Insights).
- Les conditions réseau et le chemin du trafic Internet au moment du test.
- Les publicités ou les tests A/B qui changent d’un chargement à l’autre.
- L’appareil utilisé, s’il s’agit d’un test local : ordinateur puissant ou portable modeste.
- Les extensions de navigateur et l’antivirus, qui ajoutent du code et des requêtes (Chrome for Developers).
Relancez donc le test trois ou quatre fois et regardez la tendance. Google suggère d’ailleurs de voir la performance comme une distribution de scores plutôt qu’un chiffre unique. Une variation de quelques points n’est pas un signal.
Faut-il regarder le score mobile ou le score ordinateur ?
Regardez le mobile en priorité. Pour le mobile, Lighthouse simule un appareil de milieu de gamme (Moto G4) sur un réseau mobile limité ; pour l’ordinateur, il simule un poste de bureau avec une connexion filaire (Google, À propos de PageSpeed Insights). Le test mobile est donc plus sévère, et c’est lui qui révèle le plus de défauts.
Les deux scores se calculent avec des courbes de notation distinctes : un 90 sur ordinateur et un 90 sur mobile ne représentent pas la même vitesse. Comparez toujours mobile avec mobile, et ordinateur avec ordinateur, avant et après une correction.
Pourquoi mon score PageSpeed est-il bas ?
Un score bas vient presque toujours d’un petit nombre de causes connues : des images trop lourdes, du code qui bloque l’affichage, des scripts tiers, des polices mal chargées, un serveur lent ou l’absence de cache. Le tableau les passe en revue, avec le diagnostic à repérer dans le rapport.
| Cause fréquente | Ce qu’on observe | Piste de correction |
|---|---|---|
| Images trop lourdes ou trop grandes | LCP lent, diagnostic sur la diffusion des images | Compresser, passer à WebP ou AVIF, servir la taille affichée |
| Images sans dimensions | CLS élevé : le texte « saute » | Indiquer largeur et hauteur de chaque image |
| Image principale chargée trop tard | LCP lent malgré une page légère | Pas de chargement différé sur l’image principale, priorité haute |
| CSS et JavaScript bloquants | Diagnostic « requêtes de blocage du rendu » | Différer, réduire, intégrer le strict nécessaire |
| Scripts tiers | Temps de blocage et INP dégradés | Réduire, différer ou supprimer les scripts externes |
| Polices web | Texte invisible ou décalage à l’affichage | font-display, polices allégées, préchargées |
| Serveur lent | Premier octet tardif (TTFB) | Cache de page, thème et extensions légers, hébergement adapté |
| Pas de cache navigateur | Fichiers re-téléchargés à chaque visite | Durée de cache longue pour les fichiers statiques |
Les images. Google recommande de ne jamais servir d’images plus grandes que leur affichage à l’écran, d’augmenter la compression et d’utiliser des formats modernes comme WebP ou AVIF (Chrome for Developers). Côté stabilité, il faut toujours indiquer largeur et hauteur : sans elles, le navigateur ne réserve pas l’espace et le contenu se décale quand l’image arrive (web.dev). L’image principale ne doit surtout pas être en chargement différé : Google conseille même de lui donner une priorité élevée (web.dev).
Le code qui bloque l’affichage et les scripts tiers. Les feuilles de style et scripts chargés dans l’en-tête retardent le premier affichage ; Google recommande de différer ce qui n’est pas nécessaire et de réduire le reste (Chrome for Developers). Il en va de même pour le code externe (statistiques, chat, widgets) : Google conseille de le réduire et de le différer pour donner la priorité au contenu de la page (Chrome for Developers). Un script volumineux crée aussi des tâches longues, qui dégradent la réactivité (web.dev).
Les polices. Une police web qui tarde peut laisser le texte invisible, ou le faire changer d’aspect en cours de chargement. Google recommande la propriété font-display réglée sur swap ou optional pour que le texte reste toujours visible (Chrome for Developers).
Le serveur, le thème et les extensions. Google signale qu’un serveur qui met plus de 600 ms à répondre, une redirection de trop ou une réponse non compressée ralentissent la page. Pour WordPress, sa documentation conseille un thème léger, une mise en cache de la page entière, la désactivation des extensions inutiles et, au besoin, un hébergement géré ou dédié (Chrome for Developers). Un thème chargé de fonctions inutiles ou une extension superflue pèse sur chaque page.
À retenir
Notre constat sur le terrain : les deux causes que nous rencontrons le plus souvent sont les images non optimisées et les constructeurs de pages par glisser-déposer (Elementor et ses équivalents). Ces derniers alourdissent les pages au point de donner un score catastrophique, même quand le reste du site est bien optimisé.
Le cache. Les fichiers statiques (images, polices, scripts, styles) devraient avoir une durée de cache d’au moins 30 jours, selon Google (Chrome for Developers). Sans cela, ils sont re-téléchargés à chaque visite.
Un score rouge et pas de plan d’action ?
Nous analysons votre rapport, repérons les causes réelles et vous disons ce qui rapportera le plus.
Par où commencer pour améliorer son score ?
Commencez par ce qui pèse le plus sur l’expérience des visiteurs, pas par ce qui fait gagner un point : l’image principale, puis le code qui bloque l’affichage, puis les scripts externes. Corrigez une chose à la fois et refaites le test.
- Repérez la page à tester. Prenez les pages qui comptent : accueil, une page de service, un article.
- Notez l’état de départ. Mobile et ordinateur, terrain et laboratoire, à trois ou quatre reprises.
- Traitez le LCP. Allégez et dimensionnez l’image principale, et vérifiez qu’elle n’est pas chargée en différé.
- Supprimez ce qui bloque. Différez ou retirez le code et les scripts tiers qui ne servent pas au premier affichage.
- Fixez les dimensions. Images, vidéos et encarts doivent avoir une place réservée pour éviter les décalages.
- Refaites le test. Comparez avec l’état de départ et laissez 28 jours aux données de terrain pour se mettre à jour.
À retenir
Les données de terrain portent sur les 28 derniers jours : une correction ne change pas ces chiffres du jour au lendemain. Le laboratoire réagit tout de suite ; le terrain suit.
Faut-il viser 100 sur PageSpeed Insights ?
Non, pas à tout prix. Google considère 90 à 100 comme la zone à viser et note qu’obtenir un score parfait de 100 est extrêmement difficile et n’est pas attendu (Chrome for Developers). Selon la documentation de Lighthouse, passer de 99 à 100 demande d’améliorer la métrique autant que pour passer de 90 à 94. Ce qui compte, ce sont des Core Web Vitals bons pour vos visiteurs.
À titre d’exemple, weblounes.com obtient 100 en performances sur mobile pour l’accueil sur PageSpeed Insights. Les articles de notre blog sont mesurés entre 99 et 100 sur mobile et à 100 sur ordinateur (mesures d’octobre 2026). Ces résultats se vérifient par n’importe qui sur l’outil, gratuitement, en quelques secondes.
Si votre site est loin de ces valeurs, voyez aussi que faire quand un site est lent et notre page audit SEO, qui inclut les aspects techniques. Pour un diagnostic complet, voir comment faire un audit SEO.
Questions fréquentes
Quel est un bon score sur PageSpeed Insights ?
Google classe 90 et plus comme bon, de 50 à 89 comme à améliorer et moins de 50 comme médiocre. Regardez surtout si l’évaluation des Core Web Vitals est réussie pour vos visiteurs réels.
PageSpeed Insights est-il gratuit ?
Oui, il suffit de saisir l’adresse d’une page pour obtenir un rapport pour le mobile et un autre pour l’ordinateur.
Pourquoi n’y a-t-il pas de données de terrain pour mon site ?
Google exige assez de visites réelles sur une période de 28 jours. Une page récente ou peu visitée n’en a pas toujours : seul le test de laboratoire est alors affiché.
Le score PageSpeed influence-t-il le référencement ?
Google recommande vivement d’atteindre de bons Core Web Vitals pour réussir dans la recherche. Le score de laboratoire n’est cependant qu’un outil de diagnostic : ce sont les Core Web Vitals qui comptent.
Ce qu’il faut retenir
Lisez d’abord les données de terrain, utilisez le laboratoire pour chercher les causes, testez plusieurs fois et comparez toujours mobile avec mobile. Les causes d’un score bas sont connues : images, code bloquant, scripts tiers, polices, serveur, cache. Si le rapport vous dépasse, parlons-en : nous vous aidons à le lire et à décider quoi corriger en premier.
