Core Web Vitals : protocole reproductible, preuves et contre-tests

LCP, INP et CLS sont trois distributions différentes, pas un score unique de vitesse. Une évaluation terrain décrit le 75e centile des expériences éligibles. Un test de laboratoire décrit un appareil, un réseau, un état de page et un scénario. Lorsque CrUX, RUM, Lighthouse et une trace se contredisent, ne les moyennez pas. Nommez la population, isolez la métrique, localisez l’élément ou l’interaction responsable, corrigez une cause puis contre-testez à conditions comparables.

Ce guide publie le contrat de décision complet, un jeu de données bilingue ouvert et un instrument navigateur qui enregistre localement cette session. Il refuse volontairement trois raccourcis : TBT n’est pas rebaptisé INP ; l’absence de données CrUX n’est pas traitée comme une réussite ; une exécution laboratoire plus rapide n’est pas présentée comme une causalité de classement ou de revenu.

Les Core Web Vitals stables sont le Largest Contentful Paint, l’Interaction to Next Paint et le Cumulative Layout Shift. Les seuils publics de Google classent une page ou une origine comme « bonne » lorsqu’au moins 75 % des expériences éligibles respectent le seuil. Cette phrase porte l’information essentielle : la valeur est une distribution, ni la meilleure exécution, ni la moyenne, ni le score desktop affiché dans un rapport.

Un désaccord n’est pas automatiquement un défaut de données. Lighthouse peut révéler un problème de chargement à froid dilué chez les visiteurs récurrents. CrUX peut exposer des interactions lentes qu’un test de chargement n’exerce jamais. Le RUM peut isoler un gabarit de paiement masqué par un agrégat d’origine. La méthode conserve donc chaque couche et son horodatage au lieu d’élire un unique « vrai score ».

Si CrUX manque de données, inscrivez « non mesuré ». Un trafic faible, une URL récente ou un volume insuffisant de visites Chrome éligibles peuvent expliquer l’absence. Aucun ne prouve une bonne expérience. Cette distinction est cruciale pour un jeune site B2B : un laboratoire vert est une preuve opérationnelle utile, mais ne remplace pas une population terrain inexistante.

Les portes sont ordonnées. Elles bloquent les erreurs de catégorie les plus courantes avant toute optimisation : changer une image parce que « la performance est rouge », remplacer une bibliothèque parce que TBT est élevé, ou annoncer des Core Web Vitals réussis après un seul passage Lighthouse. Une livraison peut conserver un statut terrain ouvert ; elle ne peut pas transformer silencieusement cette inconnue en succès.

LCP n’est pas synonyme de poids d’image. Commencez par l’élément signalé par la trace. Il peut s’agir d’une image héro, d’un poster, d’un bloc de texte ou d’un arrière-plan. Décomposez ensuite son horodatage en quatre parties : temps de réponse initial, délai avant le démarrage de la ressource, durée de chargement et délai entre la fin de la ressource et le rendu.

Un TTFB élevé oriente vers le serveur d’origine, les échecs de cache, les redirections ou la distance réseau. Un délai de ressource élevé oriente vers une découverte tardive, un arrière-plan CSS, le rendu client ou la concurrence de priorités. Une durée de chargement élevée oriente vers les octets, la compression, la connexion ou la livraison. Un délai de rendu élevé oriente vers le contenu masqué, les polices, le thread principal ou une ressource chargée avant que l’élément soit affichable.

Cette décomposition évite les corrections contradictoires. Un preload ne répare pas une origine lente. Réencoder une image de 20 Ko ne répare pas une seconde de délai de rendu. Une image plus rapide peut laisser le LCP inchangé lorsque la baseline textuelle reste le plus grand candidat.

INP commence par une interaction réelle. Sa latence contient l’attente avant l’exécution des gestionnaires, leur temps de traitement et le délai avant la présentation de la trame suivante. Un clic lent peut donc venir d’un travail antérieur bloquant le thread principal, d’une logique applicative coûteuse, d’une mise en page synchrone, d’un rendu volumineux ou de plusieurs causes à la fois.

Exercez les parcours critiques : ouvrir la navigation, déplier la FAQ, soumettre les états invalides et valides d’un formulaire, lire un média, rechercher et activer le CTA principal. Conservez la cible et l’état de page. Les Long Animation Frames peuvent relier l’intervalle lent aux longues trames et aux scripts lorsque le navigateur expose l’API. Une attribution non prise en charge reste non prise en charge ; elle ne devient pas conforme.

Le laboratoire local rapporte la pire interaction observée pendant la session. Il ne revendique pas l’INP officiel d’une population terrain. La métrique officielle applique ses règles de sélection et d’agrégation aux visites réelles ; la valeur locale est un candidat diagnostique pour un rejeu contrôlé.

CLS cumule les déplacements inattendus dans des fenêtres de session. La preuve utile ne se limite pas au total : elle conserve l’instant, la valeur, les nœuds déplacés et l’action précédente. Les déplacements intervenant dans la fenêtre d’exclusion après une saisie récente sont traités différemment ; cliquer sur un accordéon et voir le contenu se déplacer ne crée donc pas automatiquement un défaut CLS.

Les causes fréquentes sont les médias sans géométrie réservée, les publicités ou embeds injectés au-dessus du contenu, les polices qui changent les métriques, les annonces ajoutées après le premier affichage et les animations de propriétés de mise en page. Réservez l’espace final, conservez des ratios responsives exacts, choisissez des fallbacks typographiques compatibles et animez les transformations plutôt que la géométrie lorsque c’est approprié.

Testez tout le cycle de vie. Une page peut rester stable au chargement puis bouger quand apparaissent un consentement, un lecteur audio, un résumé d’erreurs ou un composant différé. Une capture ne prouve pas la stabilité ; la séquence et les sources, oui.

Armez la prochaine navigation. La page se recharge depuis le haut et démarre automatiquement l’observation avant que vous ouvriez le sommaire, dépliiez des questions, activiez une action d’article ou lanciez l’audio s’il est disponible. Figez la preuve seulement après le scénario. L’export consigne le mode de capture, l’environnement, les API prises en charge, les candidats, les intervalles, la géométrie de l’élément, les changements de visibilité et les limites explicites. Il exclut les valeurs de formulaire et la preuve ne quitte jamais le navigateur.

La première visite reste volontaire et ne démarre aucun observateur. Seule l’action explicite d’armement provoque un rechargement de la page ; le module versionné lit ensuite les entrées de navigation en mémoire tampon et commence la session sans seconde interaction. Le marqueur d’URL est immédiatement retiré sans nouvelle requête. Cela évite de prendre un clic tardif ou une restauration de défilement pour une mesure de navigation propre.

Le passage a utilisé Lighthouse 9.6.8 avec une émulation mobile Moto G (4) et Headless Chrome 155. Il a transféré 158 995 octets en 16 requêtes. Ces valeurs sont publiées parce qu’elles constituent un contexte reproductible, pas parce qu’elles prouvent la qualité terrain actuelle. Le relevé précède cette nouvelle édition ; un futur contre-test devra conserver cette chronologie.

Le sous-score SEO était de 93 parce que cette version de Lighthouse ne reconnaissait pas la directive Content-signal d’Edikka. L’observation de performance et l’avertissement du parseur SEO sont deux constats séparés ; aucun ne doit être caché dans le score global. Aucun résultat PageSpeed terrain n’est revendiqué, faute de réponse CrUX valide obtenue pendant cette revue.

Les quatre fichiers v1.1 étaient des preuves utiles, pas des paires avant/après valides. Leur nom annonçait « chargement seul » ou « interactif », mais la preuve elle-même n’encodait ni le scénario ni son achèvement. Chaque paire d’un même navigateur mélangeait aussi une navigation avec transfert réseau et une navigation sans transfert. Un export Safari présenté comme « chargement seul » contenait même une interaction pointeur après la navigation.

Cet échec a produit la version 1.2 : scénario, achèvement, nombre d’actions de page et état du transfert sont désormais des portes de comparaison vérifiables par machine. Seuls les décomptes dérivés sont publiés ici ; les user-agents bruts ne sont pas reproduits.

La CI doit protéger les propriétés déterministes : budgets d’actifs, dimensions d’image absentes, requêtes tierces inattendues, preloads dupliqués, tâches longues sur un parcours nommé et écarts laboratoire dépassant une tolérance convenue. Conservez trace et environnement lorsqu’une porte échoue. Ne faites pas d’un centile CrUX d’origine une porte par commit : la fenêtre terrain de 28 jours ne peut pas identifier une livraison en temps réel.

Un bon relevé de livraison possède donc deux horloges. La boucle rapide exécute trace et contre-tests laboratoire avant déploiement. La boucle lente observe RUM ou CrUX après déploiement et attend une population et une fenêtre suffisantes. Si le trafic est faible, publiez les volumes bruts éligibles et conservez « données insuffisantes » au lieu d’ajuster le seuil jusqu’au vert.

Utilisez le protocole d’optimisation des images web pour les codecs, sources responsives, qualité perceptuelle et livraison. Utilisez le protocole d’audit SEO technique pour l’exploration, les canoniques, le rendu et les contrôles techniques plus larges. Utilisez l’analyse de l’impact business d’un site lent pour cadrer le risque commercial sans transformer un écart laboratoire en revenu attribué.

Cette découpe évite la cannibalisation et garde chaque affirmation avec la preuve qu’elle exige. Les Core Web Vitals sont l’interface de mesure et de diagnostic entre ces territoires, pas le synonyme de toute la qualité front-end.