Passer au contenu principal

Vitesse web & Core Web Vitals

52 concepts · 45 preuves

Appartient à : Technique

La vitesse d'une page n'est pas qu'une affaire de chronomètre : c'est l'expérience perçue par un humain qui attend. Les Core Web Vitals de Google traduisent cette attente en trois mesures concrètes — le chargement, la réactivité, la stabilité — et en font un signal de classement réel, quoique secondaire. Comprendre ce qu'elles mesurent vraiment évite de courir après un score au lieu d'améliorer le SEO technique de fond.

Trois métriques pour trois facettes de l'expérience

Les Core Web Vitals sont une initiative de Google (ouvre un nouvel onglet) pour unifier les signaux de qualité d'expérience. Elles se concentrent sur trois aspects distincts : le chargement, l'interactivité et la stabilité visuelle. Chacune se mesure en conditions réelles et reflète un résultat centré sur l'utilisateur. C'est le socle de la page experience.

MétriqueCe qu'elle mesureSeuil « bon » (75e centile)
LCP — Largest Contentful PaintLe rendu du plus grand élément visible (chargement perçu)≤ 2,5 secondes
INP — Interaction to Next PaintLa latence de réponse aux interactions (réactivité)≤ 200 millisecondes
CLS — Cumulative Layout ShiftLa somme des décalages de mise en page inattendus (stabilité)≤ 0,1

Ces seuils proviennent directement de la documentation Google (ouvre un nouvel onglet). Le choix des métriques n'est pas anodin : elles ont été conçues pour capter la charge perçue, pas le temps brut (ouvre un nouvel onglet). Une page chargée en 6 secondes côté serveur peut sembler prête en une seconde si son contenu visible apparaît tôt — et inversement.

Pourquoi le 75e centile

Google n'évalue pas la moyenne mais le 75e centile des chargements (ouvre un nouvel onglet), segmenté mobile et desktop. Autrement dit : trois utilisateurs sur quatre doivent vivre une bonne expérience. Une page ne « passe » que si les trois métriques atteignent leur cible à ce seuil. La performance n'est pas un confort de quelques-uns mais une garantie pour la majorité.

À retenir

Les CWV se calculent page par page (ouvre un nouvel onglet). Une page d'accueil rapide ne dit rien des pages produit ou article : un audit sérieux couvre plusieurs URL représentatives.

LCP, INP, CLS : ce que chaque métrique attrape

LCP — le chargement du contenu principal

Le Largest Contentful Paint mesure le temps de rendu du plus grand élément visible dans le viewport — une image, une vidéo, un grand bloc de texte. Cible : moins de 2,5 secondes (ouvre un nouvel onglet). Pour diagnostiquer un mauvais LCP, deux métriques de support : un TTFB (Time to First Byte) élevé pointe une réponse serveur lente ; un FCP (First Contentful Paint) tardif trahit des ressources bloquant le rendu (ouvre un nouvel onglet).

INP — la réactivité de toutes les interactions

Depuis mars 2024, INP a remplacé FID (ouvre un nouvel onglet) comme métrique officielle de réactivité. Là où FID ne mesurait que le délai de la première interaction, INP observe toutes les interactions de la session (clic, tap, touche clavier) et retient la pire, hors aberrations. Chaque interaction se décompose en trois phases : input delay, processing, presentation delay (ouvre un nouvel onglet). C'est la plus longue qui détermine la latence mesurée.

CLS — la stabilité visuelle

Le Cumulative Layout Shift additionne tous les décalages de mise en page inattendus durant la vie de la page. Le cas typique : une publicité ou une image sans dimensions qui charge en retard et pousse le texte que l'on était en train de lire. Une page passe sous un score de 0,1 (ouvre un nouvel onglet). La parade : réserver l'espace en déclarant les dimensions des images et iframes, et ne jamais injecter de contenu au-dessus de l'existant.

FID, une métrique périmée, pas fausse

FID (seuil historique : < 100 ms) mesurait le premier délai d'interaction (ouvre un nouvel onglet). Il n'était pas erroné — il était partiel : une seule interaction, le délai initial seulement. INP couvre toute la session et reflète mieux la réactivité globale, ce qui a justifié le remplacement.

Donnée terrain vs labo : ne pas confondre

C'est la distinction la plus structurante de toute la mesure de performance. Les performances varient selon l'appareil et le réseau (ouvre un nouvel onglet) de chaque visiteur, ses processus actifs, ses interactions. Seule la mesure terrain (field data) peut en capturer l'image complète.

Le CrUX, source de vérité

La donnée terrain provient du Chrome User Experience Report — un composite de millions de visites réelles. C'est elle qu'expose le rapport Core Web Vitals de Google Search Console, la meilleure façon d'auditer (ouvre un nouvel onglet) à l'échelle du site. Quand cette donnée existe, elle prime sur tout le reste.

Le CrUX reste un agrégat : il ne livre pas la télémétrie par page nécessaire au diagnostic fin. Google recommande donc de mettre en place son propre RUM (ouvre un nouvel onglet) (Real User Monitoring), par exemple via la librairie web-vitals.

Le labo reste utile — avec ses limites

La mesure de labo (Lighthouse, PageSpeed Insights) teste en développement, avant production. Mais sans utilisateur réel, elle ne peut pas mesurer INP : elle utilise à la place le TBT (Total Blocking Time) comme proxy (ouvre un nouvel onglet). Améliorer le TBT en labo tend à améliorer l'INP sur le terrain.

Un piège fréquent : s'obséder sur le score global de PageSpeed. Joe Hall conseille de l'utiliser comme indicateur de progrès (ouvre un nouvel onglet), pas comme objectif. Viser 100/100 au détriment d'autres priorités SEO est un mauvais calcul.

Un facteur de classement — réel mais secondaire

La vitesse est un facteur de classement confirmé (ouvre un nouvel onglet), sur desktop comme sur mobile. Google l'a officialisé dès 2018. En 2022, John Mueller a confirmé que le moteur utilise les Core Web Vitals plutôt que les anciens signaux (ouvre un nouvel onglet) de vitesse. Cela vaut particulièrement en SEO mobile, où la patience des visiteurs est plus courte encore.

Les fondamentaux d'abord

Le mot « secondaire » est essentiel. La vitesse compte, mais les fondamentaux passent d'abord (ouvre un nouvel onglet) : contenu, autorité, technique de base. Optimiser la vitesse d'un site dont le contenu ne mérite pas de se classer ne mène nulle part. L'expérience de page agit surtout comme arbitre : entre deux pages de contenu et backlinks équivalents (ouvre un nouvel onglet), de meilleurs signaux peuvent faire pencher la balance.

Un second canal : crawl et indexation

La vitesse influence le classement par une voie indirecte : des pages qui chargent plus vite se laissent explorer plus rapidement (ouvre un nouvel onglet) par Googlebot, qui en indexe le contenu d'autant plus vite. C'est un levier distinct du facteur de ranking direct — utile à garder en tête lors d'un audit SEO.

Page experience : cinq signaux

Au-delà des CWV, l'expérience de page Google reste pertinente en recherche IA (ouvre un nouvel onglet) et combine cinq signaux : Core Web Vitals, compatibilité mobile, navigation sécurisée, HTTPS et absence d'interstitiels intrusifs (ouvre un nouvel onglet) — ces pop-ups qui rendent le contenu difficile à atteindre.

L'enjeu business : chaque seconde compte

Avant d'être un signal SEO, la vitesse est un levier de conversion. Selon Aberdeen Group, une seconde de délai supplémentaire réduit les conversions de 7 % (ouvre un nouvel onglet), les pages vues de 11 % et la satisfaction de 16 %. Walmart a, à l'inverse, observé +2 % de conversions par seconde gagnée (ouvre un nouvel onglet).

Le seuil de rupture est bas : près de 50 % des visiteurs abandonnent dès 3 secondes (ouvre un nouvel onglet) de chargement. Au-delà de cinq secondes, 90 % des utilisateurs partent (ouvre un nouvel onglet) sans interagir. Sur une page produit, la vitesse est cruciale (ouvre un nouvel onglet) : les acheteurs mobiles attendent un accès instantané.

Le seuil des 400 millisecondes

Des ingénieurs Google ont mesuré que 400 ms — à peine perceptibles (ouvre un nouvel onglet) — suffisent à faire chercher moins les utilisateurs. Sous 100 ms, le cerveau perçoit la réponse comme instantanée. La performance se joue à des échelles que l'œil ne distingue pas, mais que le comportement trahit.

Les leviers d'optimisation

Steve Souders, ancien Head Performance Engineer de Google, posait la règle d'or : 80-90 % du temps se joue côté front-end (ouvre un nouvel onglet). C'est donc là qu'il faut commencer, et non sur le seul serveur.

Les images, premier levier de poids

Selon HTTP Archive, les images représentent en moyenne 66 % du poids d'une page (ouvre un nouvel onglet). C'est le levier de taille le plus rentable. Le détail relève de l'optimisation des images : bon format (WebP, AVIF), redimensionnement aux dimensions réelles, compression, et lazy loading des images et iframes hors écran pour ne charger que le visible.

Alléger le JavaScript pour l'INP

L'INP se gagne surtout sur le JavaScript : code splitting et chargement différé, décomposition des tâches longues (> 50 ms) pour libérer le thread principal, report des scripts tiers lourds. Google prévient toutefois qu'améliorer l'INP demande du temps (ouvre un nouvel onglet). L'outil Chrome DevTools aide à isoler les interactions coûteuses.

Cache, CDN et compression côté livraison

Pour le LCP, la chaîne de livraison compte. La mise en cache sert des copies statiques (ouvre un nouvel onglet) sans repasser par le serveur. Un CDN distribue le contenu vers le nœud le plus proche du visiteur, réduisant la latence. La compression GZIP allège les fichiers texte, et la minification supprime espaces et commentaires superflus du JS, CSS et HTML.

La WPO, une spécialité à part entière

L'optimisation de performance web (WPO) est un champ spécialisé, pas une case à cocher (ouvre un nouvel onglet). Ce n'est pas une tâche d'une semaine que tout développeur maîtrise : elle demande du temps, de la planification et parfois un spécialiste dédié.

Questions fréquentes

FID, FCP, TTFB : sont-ce des Core Web Vitals ?

Non. Les trois Core Web Vitals actuels sont LCP, INP et CLS. FID a été remplacé par INP en mars 2024 (ouvre un nouvel onglet). TTFB et FCP ne sont pas des CWV mais des métriques diagnostiques (ouvre un nouvel onglet) utiles pour comprendre un mauvais LCP.

Faut-il viser 100/100 sur PageSpeed Insights ?

Non. Le score n'est qu'un indicateur de progrès (ouvre un nouvel onglet), basé sur des données de labo. La donnée terrain (CrUX, dans Search Console) est plus significative. Un bon temps de réponse aide, mais ne supplante pas un contenu de qualité.

Améliorer la vitesse va-t-il faire grimper mon classement ?

Pas mécaniquement. La vitesse est un facteur réel mais secondaire (ouvre un nouvel onglet) : elle arbitre entre pages de qualité comparable et accélère le crawl. Réglez d'abord le contenu, l'autorité et le SEO technique de fond.

Sources

  1. web.dev — Web Vitals (Philip Walton) (ouvre un nouvel onglet)
  2. web.dev — Optimize INP (ouvre un nouvel onglet)
  3. Google Search — Introducing INP (ouvre un nouvel onglet)
  4. Google Search — Page speed ranking factor (ouvre un nouvel onglet)
  5. Google Search — Succeeding in AI search (ouvre un nouvel onglet)
  6. Google Search Central — Guide de démarrage SEO (ouvre un nouvel onglet)
  7. SEOSLY — Google Page Experience audit (ouvre un nouvel onglet)
  8. Builtvisible — Page experience et INP (ouvre un nouvel onglet)
  9. Hall Analysis — Optimizing for performance (ouvre un nouvel onglet)
  10. Kinsta — Page speed (ouvre un nouvel onglet)
  11. HTTP Archive — State of the web (ouvre un nouvel onglet)
  12. Akamai / SOASTA — Online retail performance (ouvre un nouvel onglet)
  13. Ahrefs — SEO audit (ouvre un nouvel onglet)
  14. Ahrefs — SEO basics (ouvre un nouvel onglet)
  15. Steve Souders — Performance golden rule (ouvre un nouvel onglet)
  16. Mangools / Google — Search Ads speed (ouvre un nouvel onglet)
  17. Yoast — Product page SEO (ouvre un nouvel onglet)