Mesurer la vitesse de chargement d’un site web ne se résume plus à chronométrer l’affichage d’une page. Depuis mars 2024, Google a remplacé le First Input Delay (FID) par l’Interaction to Next Paint (INP) dans ses Core Web Vitals, modifiant la grille d’évaluation utilisée pour le référencement.
Plus récemment, la core update de mars 2026 a introduit un scoring agrégé au niveau du domaine entier. Quelles métriques pèsent réellement sur le classement, et où se situent les écarts de performance les plus coûteux en SEO ?
Core Web Vitals 2026 : les trois métriques et leurs seuils
Depuis la mise à jour de mars 2026, LCP, INP et CLS ont un poids égal dans le signal de classement Google. Le tableau ci-dessous synthétise les seuils officiels et ce que chaque métrique évalue concrètement.
| Métrique | Ce qu’elle mesure | Seuil « bon » | Seuil « à améliorer » |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Temps d’affichage du plus grand élément visible | ≤ 2,5 s | 2,5 s – 4 s |
| INP (Interaction to Next Paint) | Réactivité sur toutes les interactions utilisateur | ≤ 200 ms | 200 ms – 500 ms |
| CLS (Cumulative Layout Shift) | Stabilité visuelle de la page pendant le chargement | ≤ 0,1 | 0,1 – 0,25 |
Le changement majeur par rapport aux années précédentes tient au remplacement du FID par l’INP. Le FID ne mesurait que le délai de la première interaction. L’INP évalue la latence de toutes les interactions, du clic au scroll en passant par la saisie clavier, puis retient la valeur la plus défavorable (au 75e percentile).
Un site peut afficher un LCP correct tout en échouant sur l’INP à cause d’un script JavaScript bloquant qui se déclenche après le premier affichage. C’est un scénario que les anciens audits orientés « temps de chargement brut » ne détectaient pas.
Scoring au niveau du domaine : pourquoi quelques pages lentes pénalisent tout le site
Avant 2026, les Core Web Vitals étaient évalués page par page. La core update de mars 2026 a changé cette logique : Google agrège les données de performance sur l’ensemble du domaine. Concrètement, un site de 500 pages dont 30 présentent un CLS supérieur à 0,25 verra son score global dégradé, même si les pages stratégiques (accueil, pages produits) respectent les seuils.
Ce mécanisme a une conséquence directe sur les priorités d’optimisation. Corriger uniquement les pages à fort trafic ne suffit plus. Les pages secondaires (mentions légales avec des polices chargées tardivement, articles de blog avec des iframes non dimensionnées) contribuent désormais au signal envoyé à Google.
Identifier les pages qui tirent le score vers le bas
Le rapport Core Web Vitals de la Google Search Console reste le point de départ. Il regroupe les URL par statut (« bon », « à améliorer », « médiocre ») et permet de repérer les clusters de pages problématiques.
- Filtrer par statut « médiocre » et trier par nombre d’URL affectées pour cibler les correctifs à fort impact
- Croiser avec les données de terrain du Chrome User Experience Report (CrUX), qui reflète les performances réelles mesurées sur les navigateurs Chrome des visiteurs
- Vérifier les écarts entre données de laboratoire (Lighthouse, PageSpeed Insights) et données de terrain : un bon score Lighthouse avec un mauvais score CrUX signale un problème lié au comportement réel des utilisateurs ou au serveur en charge
Optimisation du LCP : les leviers techniques qui réduisent le temps d’affichage
Le LCP dépend de l’élément le plus volumineux visible dans le viewport initial. Sur la majorité des pages, il s’agit d’une image hero ou d’un bloc de texte principal. Trois facteurs techniques concentrent l’essentiel des gains.
Compression et format des images
Servir des images en WebP ou AVIF plutôt qu’en JPEG ou PNG réduit significativement le poids des fichiers sans perte de qualité perceptible. L’attribut fetchpriority="high" sur l’image LCP indique au navigateur de la télécharger en priorité, avant les ressources secondaires.
Réponse serveur et hébergement
Le Time to First Byte (TTFB) conditionne tout le reste. Un serveur mutualisé surchargé ou un backend qui génère chaque page dynamiquement sans cache allonge le TTFB de plusieurs centaines de millisecondes. Un hébergement avec cache serveur et CDN réduit le TTFB bien en dessous de la seconde dans la plupart des configurations.
Ressources bloquant le rendu
Les feuilles CSS et scripts JavaScript chargés dans le <head> sans attribut defer ou async retardent l’affichage du contenu. Minifier le CSS, différer le JavaScript non critique et inliner le CSS critique (celui nécessaire au viewport initial) sont trois actions qui améliorent directement le LCP.
INP et réactivité : le terrain où la plupart des sites échouent
L’INP est la métrique la plus récente et celle sur laquelle le plus grand nombre de sites affichent un score « à améliorer » ou « médiocre ». Le problème ne vient généralement pas du réseau ni du serveur, mais du navigateur lui-même, saturé par du JavaScript.
- Les scripts tiers (analytics, widgets de chat, pixels publicitaires) ajoutent des tâches longues sur le thread principal, retardant la réponse aux clics
- Les gestionnaires d’événements JavaScript trop lourds (recalcul de layout, manipulation du DOM à chaque interaction) gonflent la latence mesurée par l’INP
- Le manque de
requestAnimationFrameou de découpage des tâches longues viascheduler.yield()empêche le navigateur de traiter les interactions en attente
Réduire les tâches JavaScript longues est le levier principal pour passer sous le seuil de 200 ms. Auditer les scripts tiers avec l’onglet Performance de Chrome DevTools permet d’identifier ceux qui monopolisent le thread principal pendant plus de 50 ms.
CLS et stabilité visuelle : les pièges courants sur mobile
Le CLS pénalise les décalages de mise en page qui surviennent sans action de l’utilisateur. Sur mobile, les causes les plus fréquentes sont les images sans dimensions explicites (attributs width et height), les publicités injectées dynamiquement et les polices web qui provoquent un flash de texte invisible (FOIT).
Dimensionner toutes les images et réserver l’espace des éléments chargés dynamiquement élimine la majorité des problèmes de CLS. L’utilisation de font-display: swap pour les polices web réduit aussi les décalages liés au chargement typographique.
Le scoring agrégé au niveau du domaine rend ces corrections d’autant plus urgentes : une poignée de pages avec des publicités mal dimensionnées peut dégrader le CLS global du site, avec un impact sur le référencement de l’ensemble des URL indexées.
La vitesse de chargement, telle que Google la mesure en 2026, ne se réduit plus à un temps en secondes. C’est un triplet de métriques (LCP, INP, CLS) évaluées sur l’intégralité du domaine, avec un poids identique. Corriger le LCP sans traiter l’INP ou le CLS revient à optimiser un tiers du signal. Les sites qui gagnent en positionnement sont ceux qui traitent les trois métriques simultanément, en commençant par les pages qui tirent le score global vers le bas.
