Les seuils des Core Web Vitals 2026 définissent les normes de vitesse de page et de réactivité aux interactions sur les ordinateurs de bureau et les appareils mobiles. Google évalue ces mesures au 75e centile des chargements de page : le Largest Contentful Paint (LCP) est considéré comme bon à 2,5 secondes ou moins et médiocre au-dessus de 4,0 secondes ; l’Interaction to Next Paint (INP) est considéré comme bon à 200 millisecondes ou moins et médiocre au-dessus de 500 millisecondes ; et le Cumulative Layout Shift (CLS) est considéré comme bon à 0,1 ou moins et médiocre au-dessus de 0,25.
Quels sont les seuils des Core Web Vitals 2026 ?
Google évalue l’expérience utilisateur des sites Web via trois mesures principales, soutenues par des mesures au niveau du serveur telles que le Time to First Byte (TTFB). Chaque mesure contient trois évaluations de performance : Bon, À améliorer et Médiocre. Google calcule ces mesures indépendamment pour les visites mobiles et sur ordinateur en utilisant les données de terrain réelles des utilisateurs collectées par le Chrome User Experience Report.
- Largest Contentful Paint (LCP) : Bon est 2,5 secondes ou moins ; Médiocre est supérieur à 4,0 secondes.
- Interaction to Next Paint (INP) : Bon est 200 millisecondes ou moins ; Médiocre est supérieur à 500 millisecondes.
- Cumulative Layout Shift (CLS) : Bon est 0,1 ou moins ; Médiocre est supérieur à 0,25.
- Time to First Byte (TTFB) : L’objectif pour une bonne performance est de 0,8 seconde ou moins pour assurer la livraison de la réponse initiale.
Pour obtenir une note de passage dans les rapports de la Search Console, 75 pour cent des visites de page enregistrées sur une période de 28 jours doivent atteindre le seuil « Bon » pour chaque mesure. Si ne serait-ce qu’une seule mesure tombe dans la catégorie « À améliorer » ou « Médiocre » au 75e centile, l’URL échoue à l’évaluation globale.
Pourquoi Google évalue-t-il le 75e centile séparément pour le mobile et le bureau ?
Les capacités des appareils et les vitesses de réseau varient considérablement entre les ordinateurs de bureau et les appareils mobiles. Les processeurs des smartphones sont généralement moins puissants que les processeurs de bureau, et la latence du réseau mobile change en fonction de la puissance du signal. Mesurer les performances séparément empêche les mesures solides sur ordinateur de masquer les mauvaises expériences utilisateur sur mobile.
Le seuil du 75e centile garantit que la majorité des visiteurs bénéficient d’une expérience Web performante. Si 74 pour cent des sessions mobiles se chargent en moins de 2,5 secondes mais que 26 pour cent subissent des temps d’attente plus longs, la page tombe dans la catégorie « À améliorer ». Cette approche encourage les équipes techniques à créer des sites résilients qui fonctionnent de manière cohérente sur les appareils bas de gamme et les connexions plus lentes.
Comment corriger les scores élevés de Largest Contentful Paint (LCP) ?
Le Largest Contentful Paint suit le temps nécessaire pour afficher l’élément de contenu principal dans la fenêtre d’affichage de l’utilisateur, comme une image de bannière principale, une vignette vidéo ou un grand bloc de texte. Des valeurs LCP élevées proviennent généralement de temps de réponse du serveur lents, de CSS ou de JavaScript bloquant le rendu et de téléchargements d’actifs retardés. Visez un Time to First Byte (TTFB) de 0,8 seconde ou moins pour donner au navigateur suffisamment de temps pour charger les actifs critiques.
Dans une boutique e-commerce typique avec des images haute résolution, l’image principale sur les pages produits sert souvent d’élément LCP. Lorsque les pages Web appliquent le chargement différé (lazy loading) aux médias situés au-dessus de la ligne de flottaison, les navigateurs retardent le téléchargement de ces actifs jusqu’à ce que l’exécution de JavaScript soit terminée. Pour accélérer le chargement, supprimez le chargement différé des images d’en-tête principales et appliquez l’attribut fetchpriority=”high” directement à la balise HTML.
L’optimisation de la livraison CSS améliore également les temps LCP. Les règles CSS superflues bloquent le rendu du thread principal avant que le navigateur ne puisse dessiner le bloc visuel principal. Extrayez le CSS critique nécessaire au rendu initial de la fenêtre d’affichage dans des balises de style en ligne, tout en différant les feuilles de style externes non critiques.
Comment réduire le délai d’Interaction to Next Paint (INP) ?
L’Interaction to Next Paint évalue la réactivité globale de la page en mesurant le temps entre les actions de l’utilisateur (comme appuyer sur un bouton ou saisir du texte) et la mise à jour visuelle du cadre qui suit. Des valeurs INP élevées se produisent lorsque des tâches longues s’exécutent sur le thread principal du navigateur, empêchant le rendu immédiat de l’interface utilisateur.
Pour maintenir l’INP en dessous de 200 millisecondes, le code front-end doit éviter d’exécuter des tâches longues dépassant 50 millisecondes. Les développeurs peuvent diviser les fonctions monolithiques en blocs d’exécution asynchrones plus petits en utilisant des options d’API natives comme setTimeout ou scheduler.yield(). Cela permet au thread principal du navigateur de traiter rapidement les événements utilisateur entre les étapes d’exécution.
Les scripts tiers comme les widgets de chat en direct, les trackers d’analyse et les pixels marketing déclenchent souvent des retards inattendus du thread principal. Lors d’un audit de site typique, l’exécution simultanée de plusieurs balises tierces bloque l’exécution du thread lors des clics sur les boutons. Auditez régulièrement les scripts externes, chargez les balises non essentielles de manière asynchrone ou envoyez les calculs en arrière-plan vers des web workers.
Quelles sont les causes du Cumulative Layout Shift (CLS) et comment le prévenir ?
Le Cumulative Layout Shift quantifie la stabilité visuelle en mesurant la fréquence à laquelle les éléments de mise en page se déplacent de manière inattendue pendant le rendu de la page. Les changements de mise en page se produisent lorsque les éléments se chargent de manière asynchrone sans espace pré-réservé, provoquant le déplacement soudain du contenu existant.
La cause principale des scores CLS élevés est l’absence de dimensions de mise en page sur les images, les conteneurs intégrés et les publicités chargées dynamiquement. Lorsque le navigateur manque de dimensions prédéfinies, il ne peut pas calculer la géométrie de la page tant que le téléchargement des actifs n’est pas terminé, ce qui entraîne des reflows.
- Spécifiez des attributs de largeur et de hauteur explicites sur tous les éléments HTML d’image et de vidéo, ou définissez des rapports d’aspect explicites à l’aide de CSS.
- Réservez des conteneurs de mise en page dédiés pour le contenu dynamique comme les bannières publicitaires et les barres de notification afin d’éviter que les éléments environnants ne sautent.
- Utilisez font-display: swap ou font-display: optional avec le préchargement des polices pour éliminer les changements de reflow de texte causés par les retards de chargement des polices Web.
- Évitez d’injecter du nouveau contenu HTML au-dessus des éléments visibles existants après le rendu de la page, sauf si cela est explicitement initié par une entrée directe de l’utilisateur.
Comment auditer les Core Web Vitals dans DevTools et la Google Search Console
Une optimisation efficace repose sur la combinaison de la surveillance sur le terrain avec des diagnostics de laboratoire détaillés. La Google Search Console met en évidence les données de performance sur le terrain collectées à partir des visites réelles des utilisateurs, regroupant les URL avec des profils de performance similaires pour exposer les problèmes systémiques du site.
Pour le débogage local, utilisez le panneau Performance de Chrome DevTools pour enregistrer les traces d’interaction et identifier les tâches JavaScript longues. La vue chronologique marque les tâches de plus de 50 millisecondes avec des drapeaux rouges et localise les éléments DOM précis provoquant des changements de mise en page. Chez Alien Road, les équipes de développement utilisent ces traces de diagnostic locales ainsi que des vérifications d’intégration continue automatisées pour maintenir les budgets de performance avant de publier des mises à jour.
Plan d’action : Par où commencer cette semaine
Commencez par ouvrir la Google Search Console pour examiner les rapports mobiles des Core Web Vitals et identifier les modèles d’URL défaillants. Donnez la priorité aux correctifs sur les pages de destination à fort trafic où le LCP dépasse 2,5 secondes, l’INP dépasse 200 millisecondes ou le CLS dépasse 0,1.
Concentrez-vous sur des correctifs structurels rapides lors du premier sprint : définissez des dimensions d’image explicites, optimisez les priorités des images principales avec fetchpriority=”high” et assurez-vous que le TTFB reste à 0,8 seconde ou moins grâce à la mise en cache en périphérie. Vérifiez les améliorations dans les environnements de test en utilisant la limitation du réseau mobile simulée avant de déployer les modifications de code en production.
Continuer la lecture : Conception et développement Web · Conception Web