Google considère que votre site est assez rapide quand trois mesures sont bonnes chez de vrais visiteurs. Le plus grand élément s’affiche en 2,5 secondes maximum (LCP), la page réagit en 200 millisecondes maximum (INP) et la mise en page ne se décale pas de plus de 0,1 (CLS), pour trois visites sur quatre, séparément sur mobile et sur ordinateur [1].
Vous envisagez la création de site web ? Demandez une mesure plutôt qu’une promesse. Un score rouge dans PageSpeed Insights en dit moins que vous ne le pensez ; voici pourquoi, et quelles interventions rapportent le plus.
Les trois mesures en langage clair
| Mesure | Ce qu’elle mesure | Bon | Mauvais |
|---|---|---|---|
| LCP, Largest Contentful Paint | Le moment où le plus grand élément visible, en général votre image principale ou votre titre, s’affiche à l’écran | ≤ 2,5 s | > 4 s |
| INP, Interaction to Next Paint | La rapidité avec laquelle la page réagit visiblement à un clic, un tap ou une frappe au clavier | ≤ 200 ms | > 500 ms |
| CLS, Cumulative Layout Shift | À quel point la mise en page se décale de façon inattendue pendant le chargement | ≤ 0,1 | > 0,25 |
Au quotidien : le LCP, c’est le moment où votre visiteur se dit « la page est là ». L’INP, c’est la sensation qu’un bouton accroche. Le CLS, c’est le bouton qui saute au moment où vous voulez cliquer.
Une page ne réussit que si les trois mesures sont bonnes [5]. Le 12 mars 2024, l’INP a remplacé l’ancienne mesure First Input Delay (FID) [6] ; les articles qui parlent encore du FID sont dépassés.
Commencez par ces cinq interventions
On retrouve souvent ces causes sur les sites de PME, et elles se corrigent assez vite :
| Intervention | Améliore | Effort |
|---|---|---|
Réduire l’image principale, en WebP ou AVIF, sans lazy loading, avec fetchpriority="high" [7], [8] | LCP | Faible |
| Largeur et hauteur sur chaque image et vidéo [9] | CLS | Faible |
| Faire le ménage dans les scripts tiers : supprimer ce que vous n’utilisez pas, charger le reste le plus tard possible [10] | INP, LCP | Faible à moyen |
| Réserver l’espace pour la bannière cookies, les contenus intégrés et le bandeau promo [9] | CLS | Faible |
Héberger les polices vous-même, les limiter à ce que vous utilisez, régler font-display [9] | LCP, CLS | Moyen |
D’expérience, c’est là que se trouve l’essentiel du gain sur les sites de PME. Viennent ensuite les chantiers plus lourds : découper les longues tâches JavaScript, car une tâche de plus de 50 millisecondes est considérée comme longue [11], ou remplacer un page builder lourd. Pourquoi un site statique en souffre moins : lisez WordPress ou site statique.
Votre propre code est optimisé, mais votre site reste lent ? Selon web.dev, cela tient probablement aux scripts tiers [10]. Une partie de vos pixels publicitaires et analytiques peut passer par votre propre serveur. Cédric explique si cela aide, et ce que cela coûte, dans le tracking server-side expliqué.
Vrais visiteurs ou test en labo : quels chiffres comptent ?
PageSpeed Insights affiche deux blocs. En haut figurent les données de terrain du rapport sur l’expérience utilisateur de Chrome (CrUX) : l’expérience de vrais utilisateurs de Chrome sur les 28 derniers jours [5]. Le rapport Core Web Vitals de la Search Console s’appuie aussi sur ces données [12].
En bas figure le test en labo (Lighthouse) : un seul chargement simulé, sur mobile avec un appareil milieu de gamme sur un réseau mobile [5]. C’est lui qui donne le score de 0 à 100, un mélange pondéré de cinq mesures de labo [13]. Pratique pour trouver les causes, mais Google lui-même n’attend pas un 100 parfait [13].
Beaucoup de sites de PME voient « aucune donnée » en haut. Ce n’est pas une erreur : une page n’entre dans CrUX que si elle est « suffisamment populaire », Google ne publie pas le seuil et vous ne pouvez pas inscrire votre site vous-même [14]. Chrome sur iOS n’est pas non plus pris en compte [14].
Utilisez alors le test en labo comme guide, pas comme bulletin. Et testez vous-même sur un smartphone ordinaire, pas sur le wifi du bureau.
Ce que la vitesse fait pour votre position dans Google
« Core Web Vitals are used by our ranking systems », écrit Google. Mais de bons résultats ne garantissent pas la première place, et courir après un score parfait uniquement pour le SEO n’est peut-être pas, selon Google, le meilleur usage de votre temps [15]. Google affiche toujours le contenu le plus pertinent, même si l’expérience sur la page est moins bonne [15].
Notre lecture : la vitesse est une condition, pas un atout. Elle pèse davantage auprès de vos visiteurs : chez Vodafone, un LCP amélioré de 31 % a apporté 8 % de ventes en plus [16]. C’est un grand acteur et un cas de 2021, mais la tendance vaut aussi pour une PME.
Et le web dans son ensemble ? En 2025, 48 % des sites mobiles obtenaient de bons Core Web Vitals. Pour la plupart, le LCP est la pierre d’achoppement : 62 % ont un bon LCP sur mobile, contre 77 % pour l’INP et 81 % pour le CLS [17].
Rester rapide après le lancement
Un nouveau site est rapide le jour de la livraison. La question est de savoir s’il le reste, après dix nouvelles photos, un widget de chat et un pixel de plus.
- Chaque mois : testez vos cinq pages les plus importantes dans PageSpeed Insights sur mobile, et consultez le rapport Core Web Vitals dans la Search Console.
- Après une amélioration : soyez patient. Les données de terrain couvrent 28 jours [5], et si vous cliquez sur « Valider la correction » dans la Search Console, Google suit le groupe pendant 28 jours [12].
- À chaque nouveau script ou widget : testez la page avant et après.
Ce que la vitesse coûte à la construction : lisez combien coûte un site web en 2026 ? Vous voulez savoir comment votre site actuel se comporte sur mobile, et d’où viennent les problèmes ? Le scan de site gratuit mesure la vitesse de chargement, les Core Web Vitals et l’affichage mobile.
Questions fréquentes
Que sont de bons Core Web Vitals ?
Un LCP en 2,5 secondes maximum, un INP de 200 millisecondes ou moins et un CLS de 0,1 ou moins, pour 75 % des visites de pages, séparément sur mobile et sur ordinateur. Une page ne réussit que si les trois sont bons.
Quelle est la différence entre le score de PageSpeed Insights et les Core Web Vitals ?
Le score de 0 à 100 vient d’un test en labo avec un appareil et un réseau simulés. L’évaluation en haut vient de vraies visites d’utilisateurs de Chrome sur 28 jours, si votre site a assez de trafic. La Search Console s’appuie sur ces chiffres réels.
Pourquoi PageSpeed Insights n’affiche-t-il aucune donnée pour mon site ?
Parce que votre page ou votre site a trop peu de visites dans le rapport sur l’expérience utilisateur de Chrome. Google ne publie pas le seuil et vous ne pouvez pas inscrire votre site. Reste alors le test en labo, et mieux vaut tester vous-même sur un smartphone ordinaire.
Un site plus rapide est-il mieux classé ?
Tout au plus un peu. Google utilise les Core Web Vitals dans ses systèmes de classement, mais précise que de bons scores ne garantissent pas la première place et que le contenu le plus pertinent passe avant. La vitesse aide surtout vos visiteurs, et donc vos demandes.
Qu’est-ce que l’INP ?
Interaction to Next Paint : la rapidité avec laquelle votre page réagit visiblement après un clic, un tap ou une frappe au clavier. L’INP a remplacé le First Input Delay (FID) comme Core Web Vital le 12 mars 2024. Les articles qui parlent encore du FID sont dépassés.
Sources
- Web Vitals — web.dev (Google), 31 oct. 2024, consulté le 28 sept. 2026
- Largest Contentful Paint (LCP) — web.dev (Google), 4 sept. 2025, consulté le 28 sept. 2026
- Interaction to Next Paint (INP) — web.dev (Google), 2 sept. 2025, consulté le 28 sept. 2026
- Cumulative Layout Shift (CLS) — web.dev (Google), 12 avr. 2023, consulté le 28 sept. 2026
- À propos de PageSpeed Insights — Google for Developers, 21 oct. 2024, consulté le 28 sept. 2026
- Interaction to Next Paint est officiellement un élément Core Web Vitals — web.dev (Rick Viscomi), 12 mars 2024, consulté le 28 sept. 2026
- Optimiser le Largest Contentful Paint — web.dev (Google), 31 mars 2025, consulté le 28 sept. 2026
- Choisir le bon format d’image — web.dev (Google), 13 août 2024, consulté le 28 sept. 2026
- Optimiser le Cumulative Layout Shift — web.dev (Google), 7 févr. 2025, consulté le 28 sept. 2026
- Charger du code JavaScript tiers — web.dev (Google), 19 févr. 2024, consulté le 28 sept. 2026
- Optimiser les longues tâches — web.dev (Google), 19 déc. 2024, consulté le 28 sept. 2026
- Rapport Core Web Vitals — Aide Search Console, consulté le 27 sept. 2026
- Évaluation des performances Lighthouse — Chrome for Developers, consulté le 28 sept. 2026
- Méthodologie CrUX — Chrome for Developers, 20 juin 2024, consulté le 28 sept. 2026
- Comprendre l’expérience sur la page dans Google — Google Search Central, 22 sept. 2026, consulté le 28 sept. 2026
- Vodafone : l’amélioration de 31 % du LCP a permis d’augmenter les ventes de 8 % — web.dev (Google), 17 mars 2021, consulté le 28 sept. 2026
- Web Almanac 2025: Performance — HTTP Archive, 5 mai 2026, consulté le 27 sept. 2026