Core Web Vitals et PageSpeed : pourquoi les pages lentes coûtent des clients et du classement

Les Core Web Vitals sont trois indicateurs définis par Google pour mesurer l'expérience utilisateur d'un site web : Largest Contentful Paint (LCP) pour la performance de chargement, Interaction to Next Paint (INP) pour l'interactivité et Cumulative Layout Shift (CLS) pour la stabilité visuelle. Ils entrent dans le classement Google en tant que signal d'expérience de page. État en 2026.

Que sont les Core Web Vitals – et quelles sont les trois métriques qui comptent en 2026 ?

Les trois Core Web Vitals actuels sont Largest Contentful Paint (LCP), Interaction to Next Paint (INP) et Cumulative Layout Shift (CLS). Selon web.dev (Google), ils mesurent la performance de chargement, l'interactivité et la stabilité visuelle d'une page. Ils couvrent ainsi les trois moments où les utilisateurs perçoivent une page comme rapide ou laborieuse : le chargement, la réaction aux clics et l'immobilité de la mise en page.

Un changement important : INP est devenu officiellement un Core Web Vital le 12 mars 2024 et a remplacé First Input Delay (FID), comme le confirme web.dev (Google). FID n'est donc plus un Core Web Vital. Quiconque optimise encore pour FID mesure le mauvais indicateur.

Quels seuils sont considérés comme « bon », « à améliorer » et « mauvais » ?

Google fixe des limites précises pour chaque Core Web Vital, mesurées au 75e percentile de toutes les consultations de page. Cela signifie qu'une page n'est considérée comme « bonne » que si 3 visites sur 4 atteignent le niveau cible. Important : selon web.dev (Google, 2020), les seuils eux-mêmes sont identiques pour mobile et ordinateur – seule la mesure au 75e percentile est relevée séparément par type d'appareil, pas la limite.

Les valeurs situées entre « bon » et « mauvais » sont considérées comme « à améliorer ». Ces seuils ne sont pas arbitraires : Google confirme expressément, dans web.dev (2020), les limites de 2,5 s / 4 s pour le LCP et de 0,1 / 0,25 pour le CLS comme des limites fondées, qui concilient une bonne expérience utilisateur et une atteignabilité réaliste.

Que mesure le Largest Contentful Paint (LCP) – et pourquoi 2,5 secondes ?

Le LCP mesure le temps nécessaire pour que le plus grand élément visible dans la fenêtre d'affichage soit rendu – le plus souvent une image principale ou un grand titre. Selon web.dev (Google), le LCP est « bon » à ≤ 2,5 secondes et « mauvais » à > 4 secondes, dans les deux cas au 75e percentile.

Les 2,5 secondes marquent le point à partir duquel les utilisateurs perçoivent encore une page comme chargée rapidement. Si l'élément principal tarde au-delà, la page paraît lente – même si le reste est là depuis longtemps. Le LCP reflète ainsi la vitesse de chargement ressentie, et pas seulement le premier pixel.

Que signifie Interaction to Next Paint (INP) – et en quoi diffère-t-il de FID ?

L'INP mesure la rapidité avec laquelle une page réagit visiblement aux actions de l'utilisateur. Selon web.dev (Google), il est « bon » à ≤ 200 millisecondes et « mauvais » à > 500 millisecondes (75e percentile). On mesure l'intervalle entre l'action et la prochaine image rendue.

La différence avec FID, désormais abandonné, est déterminante : FID ne mesurait que le délai d'entrée de la toute première interaction. Selon web.dev, l'INP observe toutes les interactions d'une page – du délai d'entrée aux gestionnaires d'événements jusqu'à la prochaine image rendue. L'INP détecte ainsi aussi les réactions saccadées en plein milieu de la navigation, que FID ignorait tout simplement.

Qu'est-ce que le Cumulative Layout Shift (CLS) – et pourquoi ma mise en page saute-t-elle ?

Le CLS mesure l'ampleur des décalages inattendus de la mise en page pendant le chargement. Selon web.dev (Google), la valeur est « bonne » à ≤ 0,1 et « mauvaise » à > 0,25 (75e percentile). Contrairement au LCP et à l'INP, le CLS n'est pas une durée, mais un indicateur de décalage sans dimension.

Les sauts de mise en page résultent typiquement d'images sans espace réservé, de publicités insérées après coup ou de polices chargées tardivement. Le préjudice concret : quand on veut cliquer sur un bouton et que la mise en page saute au même moment, on atterrit sur le mauvais élément. Le CLS sanctionne précisément cette frustration.

Les Core Web Vitals influencent-ils vraiment le classement Google ?

Oui, mais dans un ensemble de facteurs, pas comme un facteur isolé. Dans Google Search Central, Google range les Core Web Vitals parmi les aspects de l'expérience de page : « This, along with other page experience aspects, aligns with what our core ranking systems seek to reward. » C'est donc un signal pertinent pour le classement – mais pas un levier pondéré individuellement qui propulserait une page faible vers le haut.

L'appréciation honnête : de bons Core Web Vitals ne remplacent pas un bon contenu. À pertinence comparable, ils peuvent toutefois faire la différence – et de mauvaises valeurs constituent un handicap évitable. Un site techniquement bien construit, tel que le fournit un web design professionnel, maîtrise cette base dès le départ.

Les pages lentes coûtent-elles de vrais clients ?

Oui, et on peut le chiffrer. Selon les données Google/SOASTA, la probabilité de rebond sur les pages mobiles augmente de 32 % lorsque le temps de chargement passe de 1 à 3 secondes, comme l'atteste Think with Google / SOASTA (2017). De 1 à 5 secondes, on atteint +90 %, de 1 à 10 secondes +123 %.

Dans la vie courante : chaque seconde de temps de chargement coûte de l'audience avant même que le contenu soit vu. Quiconque investit un budget dans des annonces ou du contenu en gaspille une partie au profit d'une page lente. La vitesse n'est donc pas un détail technique, mais un facteur de conversion.

Données de laboratoire et données de terrain : que dit réellement PageSpeed Insights ?

PageSpeed Insights combine deux sources de données qu'on confond souvent. Les données de terrain proviennent de sessions réelles d'utilisateurs : selon Google for Developers, l'outil affiche des valeurs de FCP, INP, LCP et CLS issues du Chrome User Experience Report (CrUX) sur les 28 derniers jours. Ces données de terrain sont pertinentes pour le classement.

Les données de laboratoire, en revanche, proviennent d'une mesure Lighthouse simulée dans des conditions standard – reproductible, mais différente de ce que vivent les utilisateurs réels. Selon Google, le score de performance Lighthouse est bon à partir de 90, à améliorer entre 50 et 89 et mauvais en dessous de 50. Important : le score de laboratoire est un outil de diagnostic, les données de terrain CrUX sont la référence pour l'évaluation.

Comment améliorer concrètement mes Core Web Vitals ?

Les leviers les plus efficaces diffèrent selon la métrique. web.dev (Google) indique, pour chacun des trois indicateurs, des mesures concrètes ayant le plus grand effet.

Améliorer le LCP : donner la priorité à la performance de chargement

• Rendre la ressource LCP détectable dans le HTML initial (un véritable img src plutôt qu'un chargement tardif par JavaScript).
• Définir fetchpriority="high" sur l'image LCP et y supprimer loading="lazy".
• Utiliser un CDN – selon web.dev, seuls 33 % des documents HTML sont servis via un CDN.

Améliorer l'INP : accroître la réactivité

• Fractionner les longues tâches et « céder la main » fréquemment pour que le thread principal reste libre.
• Réduire le JavaScript superflu – par le fractionnement du code (code splitting) et la suppression du code mort.
• Minimiser le travail de rendu, par exemple en évitant les Forced Layouts et en recourant au CSS Containment.

Améliorer le CLS : stabiliser la mise en page

• Définir width/height ou des dimensions CSS pour les images – selon web.dev, 66 % des pages comportent au moins une image sans dimensions.
• Activer le cache Retour/Avance (bfcache).
• Éviter les animations qui modifient la mise en page et utiliser plutôt CSS transform.

FAQ : questions fréquentes sur les Core Web Vitals et PageSpeed

Quels sont les trois Core Web Vitals en 2026 ?

Les trois Core Web Vitals sont LCP (performance de chargement), INP (interactivité) et CLS (stabilité visuelle), tels que les définit web.dev (Google). Depuis le 12 mars 2024, INP remplace l'ancien First Input Delay (FID).

Quelle valeur de LCP est bonne ?

Le LCP est « bon » à ≤ 2,5 secondes et « mauvais » à > 4 secondes, mesuré au 75e percentile de toutes les consultations de page (source : web.dev, Google).

INP est-il identique à FID ?

Non. FID ne mesurait que le délai de la première interaction. INP observe toutes les interactions d'une page jusqu'à la prochaine image rendue et est, depuis le 12 mars 2024, le Core Web Vital officiel (source : web.dev, Google).

Quelle est la différence entre données de laboratoire et données de terrain ?

Les données de laboratoire proviennent d'une mesure Lighthouse simulée, les données de terrain de sessions réelles d'utilisateurs dans le Chrome User Experience Report sur 28 jours. Pour l'évaluation, ce sont les données de terrain qui comptent (source : Google for Developers).

À partir de quel score PageSpeed une page est-elle bonne ?

Le score de performance Lighthouse est bon à partir de 90, à améliorer entre 50 et 89 et mauvais en dessous de 50 (source : Google for Developers). Ce score de laboratoire est une valeur de diagnostic, pas la référence du classement.

Les Core Web Vitals influencent-ils le classement ?

Oui, au sein des signaux d'expérience de page, mais pas comme facteur isolé. Google les décrit comme un aspect qui correspond à ce que récompensent les systèmes de classement principaux (source : Google Search Central).

Comment le temps de chargement influe-t-il sur les rebonds ?

Lorsque le temps de chargement mobile passe de 1 à 3 secondes, la probabilité de rebond augmente de 32 % (source : Think with Google / SOASTA, 2017). De 1 à 5 secondes, on atteint +90 %.

Sources

• web.dev (Google) – Web Vitals (2024)
• web.dev (Google) – How Core Web Vitals thresholds were defined (2020)
• web.dev (Google) – INP becomes a Core Web Vital on March 12 (2024)
• Google Search Central – Understanding Core Web Vitals and Google Search (2024)
• Think with Google / SOASTA Research – Mobile Page Speed Benchmarks (2017)
• Google for Developers – About PageSpeed Insights (2024)
• web.dev (Google) – The most effective ways to improve Core Web Vitals (2024)

Remarque : cet article propose une information technique générale et ne constitue pas une garantie contraignante de performance ou de classement. Les seuils et la logique d'évaluation reflètent l'état documenté par Google en 2026 et peuvent évoluer. Auteur : Alexander Weipprecht. État : juin 2026.