Core Web Vitals expliqués : un guide pratique pour corriger d'abord

Les Core Web Vitals sont trois métriques de terrain relatives au chargement, à la réactivité et à la stabilité visuelle : Largest Contentful Paint (LCP), Interaction to Next Paint (INP) et Cumulative Layout Shift (CLS). Pour réussir, visez le seuil de qualité pour les trois au 75e percentile, segmenté entre mobile et ordinateur. Les objectifs actuels sont un LCP inférieur ou égal à 2,5 secondes, un INP inférieur ou égal à 200 millisecondes et un CLS inférieur ou égal à 0,1.

La règle pratique est simple : mesurez les utilisateurs réels, utilisez les traces de laboratoire pour reproduire la cause et corrigez le goulot d'étranglement propre à la métrique plutôt que de poursuivre un score synthétique unique.

Comment les Core Web Vitals sont évalués

Un percentile décrit l'expérience d'une tranche de pages vues, et non une moyenne. Au 75e percentile, au moins trois quarts des visites mesurées sont égales ou inférieures à la valeur rapportée. Segmentez les résultats par appareil, modèle, zone géographique, connexion et version lorsque les données le permettent. Une moyenne rapide sur ordinateur peut masquer une mauvaise expérience sur mobile.

Les données de terrain proviennent de vrais navigateurs et incluent la vitesse des appareils, les conditions réseau, les interactions utilisateur et le cycle de vie complet de la page. Chrome User Experience Report, PageSpeed Insights, Search Console et une configuration de real-user monitoring peuvent fournir des signaux de terrain. Les outils de laboratoire sont reproductibles et excellents pour le développement, mais ils simulent une visite et ne peuvent pas observer les véritables schémas d'interaction. En laboratoire, le Total Blocking Time est un proxy de diagnostic utile pour la réactivité ; ce n'est pas l'INP.

LCP : charger le contenu principal

Le LCP enregistre le moment où le plus grand bloc de texte, image ou poster vidéo visible est affiché. C'est un signal centré utilisateur indiquant quand le contenu principal apparaît, pas une mesure de toutes les ressources de la page.

Corriger le LCP dans cet ordre

1. Réduisez le TTFB. Une réponse serveur qui démarre tard retarde l'analyse du HTML et la découverte de la ressource LCP. Inspectez le DNS, l'établissement de connexion, l'état du CDN, la mise en file d'attente à l'origine, le temps applicatif et les dépendances de base de données.
2. Découvrez tôt la ressource LCP. Placez le balisage critique dans le HTML initial, évitez de le cacher derrière un rendu côté client et utilisez un preload ou une priorité de récupération appropriés uniquement lorsque la ressource est véritablement critique.
3. Diffusez moins d'octets. Redimensionnez l'image à ses dimensions rendues, utilisez un format moderne lorsque c'est pertinent, compressez le texte et retirez les redirections du chemin critique.
4. Ne chargez pas la ressource LCP à la demande. Le chargement différé des images sous la ligne de flottaison est utile, mais retarder l'image principale visible crée précisément le problème que le LCP doit révéler.
5. Réduisez le travail bloquant le rendu. Gardez le CSS critique ciblé et différez le JavaScript non essentiel et le code tiers.

Les guides CDN managé et images adaptatives couvrent deux leviers de diffusion, mais aucun ne peut compenser une origine qui passe plusieurs secondes à construire le document.

INP : répondre aux interactions

L'INP mesure la latence entre les interactions utilisateur qualifiantes et la prochaine mise à jour visuelle durant une visite de page. Il capture la réactivité après le chargement initial, y compris les clics, appuis et saisies au clavier. Une page peut avoir un bon LCP et néanmoins sembler défaillante si JavaScript bloque le thread principal lorsque les utilisateurs interagissent.

Corriger l'INP dans cet ordre

• Utilisez les traces de performance DevTools ou l'attribution de terrain pour identifier l'interaction lente et le gestionnaire d'événement responsable.
• Découpez les tâches longues en éléments plus petits afin que le navigateur puisse afficher entre les unités de travail.
• Réduisez le JavaScript livré et exécuté sur la route. Retirez les dépendances inutilisées et différez le code pour des interactions qui n'ont pas eu lieu.
• Évitez les recalculs de style coûteux et le layout thrashing. Lisez les valeurs de mise en page par lots, puis écrivez les changements par lots.
• Gardez les gestionnaires d'événements courts. Déplacez les analytics et le travail non urgent vers une tâche ultérieure ou une période d'inactivité appropriée.
• Vérifiez les widgets tiers, les outils de consentement, le chat, la personnalisation et les gestionnaires de tags. Ils concurrencent souvent le code applicatif sur le même thread principal.

Ne résolvez pas l'INP en ajoutant uniquement une règle CDN à JavaScript. Un téléchargement plus rapide aide, mais l'exécution et la gestion des événements se produisent sur l'appareil de l'utilisateur.

CLS : maintenir la stabilité de la page

Le CLS mesure les mouvements visuels inattendus pendant le cycle de vie de la page. Un score faible signifie que les utilisateurs risquent moins de perdre leur position ou de cliquer sur le mauvais contrôle. Les décalages de mise en page causés par une action utilisateur, comme l'ouverture d'un menu, ne sont pas automatiquement un problème ; ce sont les mouvements inattendus qui le sont.

Corriger le CLS dans cet ordre

• Définissez des attributs width et height ou un aspect-ratio pour les images et vidéos.
• Réservez de l'espace pour les publicités, contenus embarqués, bannières de consentement et emplacements de recommandation avant l'arrivée de leur contenu.
• Évitez d'insérer du contenu au-dessus du contenu existant après le rendu initial.
• Préchargez uniquement les polices nécessaires à la première vue, utilisez des métriques de repli appropriées et surveillez les remplacements de police qui déplacent le texte.
• Préférez les animations basées sur les transformations aux propriétés qui déclenchent la mise en page.
• Reproduisez les décalages avec la piste Layout Shifts et identifiez l'élément qui a bougé, pas seulement celui qui l'a provoqué.

Un workflow de mesure orienté correction

1. Établissez la référence

Collectez les données de terrain pour les modèles principaux et enregistrez le 75e percentile sur mobile et ordinateur. Ajoutez un marqueur de version si votre outil RUM le permet. Utilisez PageSpeed Insights ou Search Console pour localiser les groupes d'URL concernés, puis inspectez une URL représentative au lieu de supposer que chaque page se comporte de la même façon.

2. Reproduisez la cause

Exécutez une trace de laboratoire bridée en documentant l'état du cache et la catégorie d'appareil. Comparez un chargement à froid avec une vue répétée. Utilisez les panneaux Network, Performance, Coverage et Rendering pour relier la métrique à une requête, une tâche longue ou un décalage de mise en page. Mesurez le temps serveur et les en-têtes de cache séparément du rendu navigateur.

3. Déployez une catégorie de correction

Modifiez une variable significative à la fois lorsque c'est possible : priorité d'image, requête serveur, découpage JavaScript, espace de mise en page réservé ou règle de cache. Le résultat est ainsi attribuable et le retour arrière reste sûr. Ne regroupez pas dix optimisations sans rapport et ne devinez pas ensuite laquelle a aidé.

4. Vérifiez sur le terrain

Vérifiez à nouveau les mêmes modèles après que la version a reçu suffisamment de trafic. Confirmez que le 75e percentile s'est amélioré sans régressions dans les parcours de conversion, l'accessibilité, la localisation, le consentement, l'authentification ou la justesse du cache.

Erreurs qui créent des succès trompeurs

Ne confondez pas un bon premier affichage avec un bon LCP. N'utilisez pas une moyenne lorsque l'objectif est un percentile. Ne traitez pas CrUX comme une trace de débogage ; c'est un signal large qui peut être décalé par rapport à une version. Ne marquez pas toutes les images comme hautement prioritaires. Ne différez pas chaque script sans vérifier le comportement des interactions. N'ignorez pas une réponse serveur lente parce que le waterfall de laboratoire paraît acceptable sur un serveur de test proche.

Pour la partie serveur du LCP, lisez Comment réduire le TTFB. Pour la politique de diffusion et la sécurité du cache, poursuivez avec La mise en cache CDN expliquée. Le SEO/GEO technique est également utile lorsque le comportement d'exploration et la fiabilité des réponses font partie du problème.

Checklist de validation

Avant de déclarer une page saine, confirmez les trois métriques au 75e percentile pour chaque segment d'appareils important, vérifiez que l'élément LCP est compris, inspectez l'interaction la plus lente pour l'INP, capturez les sources de décalage de mise en page pour le CLS et comparez les données de terrain à une trace de laboratoire reproductible. Conservez un budget de performance et alertez sur les régressions après les déploiements et les changements majeurs de contenu.

There are only two hard things in Computer Science: cache invalidation and naming things.