Checklist de correction des Core Web Vitals

Checklist : Correction des Core Web Vitals. Timebox : un jour ouvré pour confirmer le périmètre et le diagnostic ; un à dix jours ouvrés pour un correctif et un déploiement typiques, selon que la cause réside dans un actif, un template partagé, un script tiers, le serveur d’origine ou un CDN. La vérification terrain suit la fenêtre de données glissante de 28 jours et est planifiée séparément. Responsable : un ingénieur performance ou un ingénieur front-end senior est garant. Le responsable SEO technique possède les critères d’acceptation terrain ; les responsables plateforme, design, analytique et produit approuvent les changements dans leurs systèmes.

Cette checklist transforme un constat de performance diagnostiqué en un correctif déployé et vérifié sur le terrain. Les Core Web Vitals sont les mesures par Google des utilisateurs réels pour le chargement, la réactivité et la stabilité visuelle : Largest Contentful Paint (LCP), Interaction to Next Paint (INP) et Cumulative Layout Shift (CLS). Le Time to First Byte (TTFB) et le First Contentful Paint (FCP) sont des métriques de diagnostic complémentaires. Ils sont inclus car une réponse lente ou un écran blanc consomme le temps disponible pour atteindre un bon LCP.

Pourquoi cette checklist, et pourquoi ici

Cette checklist consomme le registre de correction issu de l’audit des performances et des Core Web Vitals . Cette phase antérieure identifie la métrique en échec, l’URL et le template affectés, la référence utilisateur réel, la condition de laboratoire reproductible, la cause suspectée, la priorité et le responsable. La correction ne commence qu’après que ces champs existent. Sinon, on demande à un développeur de « rendre le site plus rapide » et il changera naturellement ce qu’un outil met en avant en premier, que cela cause ou non l’échec terrain.

Le diagnostic doit cibler trois niveaux avant d’agir : quelle métrique, quel template et quel élément ou tâche. Un échec de TTFB à l’échelle du domaine nécessite un correctif plateforme ; un LCP qui échoue uniquement sur les pages articles peut provenir de leur composant hero ; un INP après l’ouverture d’un filtre produit peut provenir d’un seul gestionnaire d’événement ; un CLS sur les pages promotionnelles peut provenir d’une bannière sans réservation d’espace. Traiter ces problèmes comme un seul produit des changements trop larges et un manque de clarté sur la responsabilité.

L’ordre compte dans le correctif. Le TTFB est en amont : tant que le premier octet de réponse n’arrive pas, le navigateur ne peut pas découvrir les ressources HTML normales ni afficher le contenu de la page. Si le TTFB est mauvais, corrigez la génération de la réponse, la mise en cache, les redirections et la livraison en périphérie avant de compresser l’image LCP. Une fois le temps de réponse dans le budget, avancez dans l’ordre via la découverte des ressources, le téléchargement des ressources, le rendu, les interactions et la stabilité de la mise en page.

Sauter cette checklist laisse l’audit à l’état de rapport. L’appliquer avant le diagnostic invite à la chasse aux symptômes : compresser une image alors que la découverte tardive domine, ou différer des scripts alors que le serveur d’origine est lent.

Entrées et sorties

Les sorties permettent à un futur responsable de reproduire l’échec, d’identifier ce qui a été déployé et de distinguer l’acceptation en laboratoire de la confirmation terrain.

La checklist

Réalisez les éléments 1 à 4 avant de modifier la production. Les éléments 5 à 8 implémentent le correctif ordonné par dépendance. Les éléments 9 à 11 séparent l’acceptation immédiate du déploiement de la vérification terrain.

1. Verrouiller la métrique, le template et l’élément en échec

Quoi : réduire le constat à une métrique, un ensemble de templates affectés et un élément, une requête, une tâche ou une période serveur nommé. Pourquoi : un score à l’échelle du site n’identifie pas de travail déployable, et deux URL peuvent échouer pour des raisons différentes. Comment : reliez l’échec p75 aux traces et comparez les templates affectés et non affectés ; nommez l’élément LCP et son retard, l’interaction INP et sa tâche, l’élément CLS et son déclencheur, ou le chemin de requête TTFB et son état de cache. Outil : preuves CrUX, trace navigateur, waterfall, timing serveur, inventaire des templates et outil de suivi des tickets. Terminé quand : les preuves établissent que « la métrique X échoue sur le template Y parce que Z crée un délai ou un mouvement sous la condition C. »

2. Confirmer le périmètre avec des pages représentatives

Quoi : tester le constat sur une URL typique et une URL dans le pire cas pour chaque template impliqué, plus un témoin non affecté. Pourquoi : un correctif sur une seule page peut masquer un défaut partagé, tandis qu’un changement global peut être inutile lorsqu’une seule variante de contenu cause le problème. Comment : maintenez constants le dispositif, le réseau, l’emplacement, le consentement, la connexion et les conditions de cache ; comparez l’utilisation des composants, le poids des actifs, le temps de réponse, l’activité tierce et la longueur du contenu. Outil : analytics, inventaire des templates, outils de performance navigateur, moniteur de requêtes et matrice de test. Terminé quand : chaque template du périmètre est marqué comme affecté ou témoin, chacun dispose de preuves reproductibles, et le périmètre de déploiement nomme le composant, la route, la famille d’actifs ou la couche plateforme qui doit changer.

3. Définir le budget et protéger le comportement requis

Quoi : définir la cible numérique, les garde-fous de régression et les fonctions qui doivent survivre. Pourquoi : « plus rapide » n’a pas de limite d’acceptation, et supprimer un gestionnaire de consentement, une balise analytics, un comportement d’accessibilité au focus ou une fonctionnalité produit peut créer un succès trompeur. Comment : fixez la cible à partir du tableau de décision ci-dessous, ajoutez une marge interne plus stricte là où les tests répétés varient, et listez les parcours critiques et les métriques non ciblées à retester. Outil : registre des constats, exigences produit, plan analytics, vérifications d’accessibilité et budget de performance. Terminé quand : le ticket mentionne la métrique cible et sa valeur, la méthode d’acceptation en laboratoire, la méthode d’acceptation terrain, les comportements protégés, les compromis autorisés, la condition de rollback et les approbateurs nommés.

4. Vérifier le TTFB avant le travail front-end

Quoi : mesurer le TTFB en conditions de cache à froid et à chaud depuis des emplacements pertinents pour l’audience. Pourquoi : le TTFB est inclus dans chaque temps d’affichage ultérieur ; le travail front-end ne peut pas rattraper le temps déjà passé à attendre le HTML. Comment : décomposez la requête en DNS, connexion, redirections, attente CDN, calcul serveur, temps base de données ou API externe, et comportement de streaming là où l’instrumentation le permet. Comparez les réponses avec et sans cache et confirmez que la personnalisation ou les cookies ne désactivent pas la mise en cache de manière inattendue. Outil : waterfall de requête, timing serveur, journaux CDN et serveur, profilage d’application et surveillance synthétique des requêtes. Terminé quand : le TTFB est dans le budget convenu ou un constat bloquant de plateforme séparé est attribué et planifié. Ne commencez pas le réglage du LCP tant qu’un mauvais TTFB reste inexpliqué.

5. Supprimer d’abord les délais serveur et de livraison

Quoi : corriger une réponse serveur lente, des absences de cache, des redirections ou une livraison distante. Pourquoi : ces causes retardent chaque élément et affectent souvent plusieurs templates. Comment : supprimez les redirections évitables ; mettez en cache le HTML et les données sûrs ; réduisez le travail lent de base de données ou d’API ; déplacez le travail hors du chemin critique ; ajustez le routage CDN et les clés de cache. Ne mettez jamais en cache des réponses privées sans une conception approuvée. Outil : profileur d’application, traces de requêtes, configuration CDN, en-têtes de réponse, surveillance et tests de charge. Terminé quand : les tests répétés à froid et à chaud respectent le budget, les variantes de cache restent correctes, les erreurs ne régressent pas et les URL prioritaires renvoient la réponse prévue sans saut supplémentaire.

6. Corriger le retard de découverte, transfert et rendu du LCP

Quoi : raccourcir le Largest Contentful Paint , lorsque le plus grand bloc de texte ou image visible s’affiche. Pourquoi : des héros surdimensionnés sont courants, mais une découverte tardive, une faible priorité, du CSS bloquant, du JavaScript ou des polices peuvent dominer. Comment : servez une image responsive correctement dimensionnée ; ne chargez pas en lazy-load l’actif LCP au-dessus de la ligne de flottaison ; exposez-le dans le HTML initial ; priorisez ou préchargez uniquement avec preuve ; supprimez le blocage du rendu ; et utilisez des polices subsettées, cachables avec un fallback adapté. Outil : décomposition LCP, waterfall, inspection d’image, rapport de couverture, trace et comparaison visuelle. Terminé quand : l’élément LCP prévu est cohérent, son délai dominant diminue, les pages représentatives respectent le budget, et la bande passante, la visibilité du texte et le rendu ne régressent pas.

7. Corriger l’INP au niveau de l’interaction responsable

Quoi : réduire l’interaction responsable d’un mauvais Interaction to Next Paint , la métrique de réactivité. Pourquoi : supprimer du JavaScript arbitraire peut ne pas toucher l’événement lent. Comment : séparez le délai de saisie, de traitement et de présentation ; divisez les tâches longues ; supprimez le travail synchrone ; reportez les tiers non essentiels ; évitez les mises en page répétées ; réduisez les rerendus ; et cédez la main pour l’affichage. Testez sur du matériel réaliste avec des tiers de production. Outil : trace d’interaction, profil du thread principal, entrées de tâches longues, profileur de framework et dispositif réaliste. Terminé quand : les interactions critiques fonctionnent, la tâche responsable respecte le budget des tests répétés, le proxy terrain est documenté, et le comportement des analytics, du consentement, du clavier et du lecteur d’écran ne régresse pas.

8. Corriger le CLS en réservant la mise en page finale

Quoi : empêcher les mouvements contribuant au Cumulative Layout Shift , le score d’instabilité visuelle. Pourquoi : les images, polices, publicités, bannières, contenus embarqués et composants asynchrones peuvent tous décaler l’interface. Comment : définissez des dimensions intrinsèques ou un aspect-ratio ; réservez des emplacements pour les modules dynamiques ; utilisez des polices de secours compatibles ; et animez avec des transformations. Outil : régions de décalage de mise en page, trace, filmstrip, tests de régression visuelle et navigateur limité. Terminé quand : chaque groupe de décalage important a une source nommée, les pages respectent le budget CLS tout au long du chargement et des interactions critiques, et l’espace réservé n’obscurcit aucun contrôle.

9. Retester l’ensemble des métriques et les parcours protégés

Quoi : comparer le candidat au déploiement avec la référence figée dans des conditions identiques, puis tester en production. Pourquoi : améliorer une métrique peut en détériorer une autre : différer du JavaScript peut améliorer le LCP mais aggraver la première interaction, tandis qu’un changement agressif de police peut améliorer le temps d’affichage mais créer un décalage de mise en page. Comment : effectuez plusieurs échantillons contrôlés, comparez une statistique déclarée plutôt que le meilleur passage, inspectez les traces, exercez les parcours protégés, vérifiez l’exactitude des réponses et testez les templates affectés et témoins. Outil : Lighthouse ou un outil de laboratoire équivalent, outils de performance navigateur, moniteur de requêtes, tests visuels et fonctionnels, et checklist de déploiement. Terminé quand : la métrique cible respecte son budget de laboratoire selon la méthode de séries répétées déclarée, le TTFB/FCP/LCP/INP/CLS ne montre aucune régression critique, le comportement protégé réussit, la production sert le changement prévu et le rollback n’est pas déclenché.

10. Annoter le déploiement et planifier la révision terrain

Quoi : enregistrer l’horodatage du déploiement, le périmètre modifié, la métrique cible, la direction attendue et les dates de révision terrain. Pourquoi : CrUX utilise une fenêtre glissante de 28 jours, donc les expériences antérieures au déploiement restent dans le p75 rapporté après le déploiement. Sans annotation, l’équipe peut juger un bon correctif inefficace trop tôt ou attribuer un mouvement ultérieur au mauvais déploiement. Comment : attachez la version de production au constat, vérifiez les erreurs immédiatement, enregistrez les premières lectures terrain sans les traiter comme définitives, et planifiez un responsable pour réviser une fenêtre suffisamment rafraîchie. Outil : journal de déploiement, outil de suivi des tickets, CrUX, AmICited Web Vitals et surveillance. Terminé quand : le ticket est marqué Accepté en laboratoire, l’annotation de déploiement et les preuves immédiates sont attachées, et un responsable nommé et une date calendaire existent pour la vérification terrain.

11. Vérifier avec les données terrain et clore ou rouvrir

Quoi : comparer les données terrain p75 comparables après que la fenêtre glissante s’est suffisamment rafraîchie. Pourquoi : les dispositifs, réseaux, géographie, comportement de cache, états de consentement et interactions des utilisateurs réels ne peuvent pas être représentés par un seul passage en laboratoire. Comment : utilisez le même niveau CrUX — URL ou domaine — la même métrique et un périmètre d’audience comparable ; tenez compte du déploiement partiel et des autres déploiements ; inspectez les représentants de template plutôt que de vous fier uniquement à un agrégat du domaine. Si le résultat est manqué, comparez la trace actuelle avec l’énoncé de cause original et rouvrez le diagnostic au lieu d’empiler des ajustements sans rapport. Outil : AmICited Web Vitals, historique CrUX, annotations de déploiement, segments analytics et dossier de preuves. Terminé quand : la cible atteint le seuil p75 convenu et le périmètre avec les limites enregistrées, auquel cas le statut devient Vérifié sur le terrain ; ou le ticket est explicitement rouvert avec de nouvelles preuves, un nouveau responsable et une nouvelle hypothèse.

Outils dans AmICited

Ouvrez AmICited Web Vitals pour voir le LCP, l’INP, le CLS, le FCP et le TTFB issus de CrUX pour votre domaine et vos concurrents suivis. Utilisez-le au moment du diagnostic pour capturer la référence terrain et après le déploiement pour vérifier le résultat terrain glissant. Une valeur vide signifie des données terrain éligibles insuffisantes, pas zéro et pas un succès. La vue produit soutient le verdict ; les traces, le timing serveur et les profils navigateur identifient toujours la cause.

Utilisez Performance Impact pour relier les preuves de performance au niveau de la page avec la position de citation et identifier les pages lentes à forte valeur. Cette association aide à prioriser la correction mais ne prouve pas que la performance seule a causé un résultat de citation. Préservez la pertinence, le contenu, l’autorité et le contexte de déploiement lors de l’interprétation des mouvements.

Pour le flux produit, suivez Comment vérifier vos Core Web Vitals dans AmICited . Le tutoriel explique où apparaissent les métriques et comment fonctionnent les comparaisons avec les concurrents ; cette checklist régit le diagnostic, l’implémentation et l’acceptation.

Règles de décision : ce à quoi ressemble un mauvais résultat

Utilisez le 75e percentile, abrégé p75, pour les décisions terrain : 75 % des expériences enregistrées éligibles sont à ou en dessous de cette valeur. Une valeur limite appartient à la meilleure catégorie. Le LCP, l’INP et le CLS déterminent le statut des Core Web Vitals ; le TTFB et le FCP sont des mesures de soutien utilisées pour ordonner et diagnostiquer le travail.

Appliquez ces règles dans l’ordre :

1. Un délai d’attente, une erreur serveur, une réponse incorrecte ou un parcours critique cassé bloque le déploiement quel que soit le score de la métrique.
2. Un TTFB mauvais est en amont du LCP et est corrigé en premier. Ne prétendez pas à une solution uniquement basée sur l’image alors que le serveur a déjà consommé la majeure partie du budget d’affichage.
3. Les métriques terrain mauvaises priment sur les métriques à améliorer. Dans une même catégorie, priorisez les causes de template partagé, le trafic et les parcours critiques pour l’activité.
4. Une valeur terrain vide au niveau URL est inconnue. Utilisez des preuves de laboratoire et un proxy documenté, mais ne requalifiez pas « inconnu » en « bon ».
5. Un seul passage réussi en laboratoire est insuffisant. Déclarez le profil dispositif/réseau et la méthode de séries répétées avant de tester.
6. Un correctif est Accepté en laboratoire lorsque le comportement déployé et les tests contrôlés réussissent. Il est Vérifié sur le terrain uniquement après que des données terrain glissantes comparables atteignent le seuil convenu.
7. Si les données du domaine passent mais qu’un template à fort trafic échoue, le résultat du template l’emporte pour ce périmètre. L’agrégation ne doit pas effacer un problème utilisateur concentré.

Livrable : le dossier de correction et de vérification

Transmettez un ticket ou une entrée de registre par cause racine, avec des sous-périmètres lorsqu’une cause affecte plusieurs templates. Utilisez un tableur, un outil de suivi des tickets ou un document d’ingénierie, mais préservez ces champs :

Identifiant du constat et métrique principale :
Source terrain : URL | Domaine
p75 terrain, catégorie et fenêtre de 28 jours :
Templates affectés et URL représentatives :
Template témoin et URL :
Élément, interaction, requête ou période serveur :
Énoncé de cause et liens vers les preuves :
Profil de laboratoire et référence de séries répétées :
Cible, garde-fous et parcours protégés :
Correction choisie et alternatives rejetées :
Responsable technique, approbateurs et dépendances :
Identifiant de version/déploiement et horodatage de déploiement :
Résultats immédiats en production et en laboratoire :
Responsable et date de révision terrain CrUX :
Résultat terrain comparable et limites :
Seuil de surveillance et règle de réouverture :
Statut : Ouvert | En cours d'implémentation | Accepté en laboratoire | Vérifié sur le terrain | Rouvert | Risque accepté

Attachez les traces, waterfalls, périodes serveur, enregistrements de décalage, profils d’interaction, résultats de test et annotation de déploiement. Le statut « Risque accepté » nécessite un périmètre, une raison, un approbateur, une date d’expiration et un déclencheur de surveillance ; ce n’est pas un succès.

Le dossier est accepté lorsqu’un autre ingénieur peut reproduire le problème original, identifier pourquoi ce changement y répond, confirmer ce qui a atteint la production et répéter la comparaison terrain sans demander à l’enquêteur original de reconstruire le travail.

Ce qui peut mal tourner

Optimiser avant d’isoler la cause. La compression générique et la suppression de scripts remplacent le diagnostic. Exigez d’abord des preuves métrique-template-élément.

Compresser le héros alors que le serveur d’origine est lent. Une image plus petite ne peut pas s’afficher avant que le HTML n’arrive. Mesurez et corrigez le TTFB en premier lorsqu’il est hors budget.

Corriger le mauvais décalage. Le CLS peut provenir d’une publicité, d’une bannière de consentement, d’une police, d’un contenu embarqué ou d’un composant hydraté. Nommez la source du décalage.

Différer tous les scripts. Un report indiscriminé peut casser l’ordre du consentement, les analytics, la navigation, les formulaires ou la première interaction. Modifiez le chemin d’exécution responsable et testez la régression du comportement requis.

Vérifier une seule URL après un déploiement sur template partagé. L’exemple choisi peut réussir tandis qu’une variante de contenu plus lourde ou une autre configuration de composant échoue encore. Testez les pages typiques, lourdes et témoins.

Lire les données au niveau du domaine comme un succès de template. Des pages à fort trafic en bonne santé peuvent masquer une catégorie, un article ou un template produit faible. Maintenez le diagnostic et l’acceptation au périmètre fiable le plus étroit.

Clore le jour du déploiement. Les tests immédiats établissent l’acceptation en laboratoire. Ils ne remplacent pas la fenêtre de données terrain glissante.

Attendre 28 jours pour découvrir un déploiement cassé. La confirmation terrain prend du temps, mais les codes de statut, les erreurs, les parcours, la stabilité visuelle et les métriques contrôlées sont vérifiés immédiatement. Les données glissantes ne sont pas une excuse pour sauter l’assurance qualité du déploiement.

Phase suivante : surveillance continue et itération

Transmettez l’enregistrement de vérification terrain, l’annotation de déploiement, les templates affectés, les limites et les seuils à la phase de rafraîchissement et itération continus . Celle-ci a besoin d’une référence stable afin que les modifications ultérieures de contenu, médias, templates, campagnes et tiers puissent être comparées plutôt que redécouvertes comme un mouvement inexpliqué.

Le prochain responsable enregistre qui surveille chaque seuil, où les preuves se trouvent, à quelle fréquence elles sont révisées et ce qui rouvre une correction. Une métrique redevenue mauvaise, une tendance répétée à l’amélioration sur toute la fenêtre rafraîchie, un élément LCP changé, une nouvelle interaction lente ou un déploiement de template qui modifie le chemin diagnostiqué doivent rouvrir la checklist à l’élément 1. Ne répétez pas automatiquement le correctif précédent : la même métrique peut échouer pour un élément différent après une refonte.

Le transfert est complet lorsque le statut terrain est explicite, chaque limite acceptée a un responsable et une date de révision, et la surveillance peut relier une régression à un template et à un déploiement. Si la vérification terrain reste en attente, le prochain responsable reçoit la date de révision planifiée et le ticket reste en statut Accepté en laboratoire, pas clos.

FAQ

FAQ sur la correction des Core Web Vitals