Audit des performances et des Core Web Vitals

Phase P3 · Étape A — Comprendre
Durée indicative : 4 à 8 heures pour un audit représentatif ; 2 à 5 jours ouvrés pour une enquête couvrant l’ensemble des modèles avec traces d’ingénierie. La validation terrain sur 28 jours intervient après les correctifs et ne prolonge pas la durée initiale de l’audit.
Responsable : le responsable SEO technique définit le périmètre et les critères d’acceptation. Un ingénieur performance ou un ingénieur front-end senior est en charge du diagnostic ; les responsables plateforme, CDN, analytique, design et produit contribuent lorsque leurs systèmes génèrent des délais ou de l’instabilité.

Cette phase transforme les preuves terrain issues d’utilisateurs réels et les tests de laboratoire reproductibles en un registre de correctifs associé à des URL, des modèles, des métriques, des responsables et des critères de complétion — et non en un simple score de vitesse générique.

Pourquoi cette phase, et pourquoi ici

La performance appartient à l’étape A car une page qui exprime est un problème d’exploration avant d’être un problème d’expérience utilisateur. Un robot d’exploration ou un agent de récupération dispose d’un budget de requêtes limité. Si l’origine bloque, redirige plusieurs fois ou renvoie une réponse incomplète, le client peut abandonner la page avant même d’évaluer le contenu. Des titres plus rapides, un meilleur contenu et un schéma plus fort ne peuvent pas aider un contenu qui n’est pas récupéré de manière fiable.

La phase P3 consomme les hôtes canoniques, les modèles indexables prévus, les parcours prioritaires, les preuves de codes de statut et les conclusions d’infrastructure non résolues issues de l’audit technique de référence . Cet ordre évite les faux diagnostics. Par exemple, un « chargement de page » de cinq secondes dû à une boucle de redirection n’est pas une tâche d’optimisation d’images, et un test rapide d’une page d’erreur en cache n’est pas un succès. La phase P2 établit que la bonne URL peut être demandée et sélectionnée ; la phase P3 établit qu’elle peut être délivrée et utilisée dans des limites de temps et de stabilité acceptables.

Réaliser cette phase tardivement crée des reprises. Une équipe de contenu peut publier sur un modèle dont le héros est toujours l’élément le plus lent, ou approuver un emplacement promotionnel qui décale chaque fiche produit. Le défaut se multiplie alors sur les nouvelles pages.

Entrées et sorties

Les entrées rendent l’échantillon représentatif. Les sorties forment le contrat avec la phase suivante : exactement quelles pages sont disponibles de manière fiable, quelles conditions restent faibles, et quelles limitations de performance doivent qualifier les mesures ultérieures.

Les données terrain et les données de laboratoire sont des preuves différentes

Les données terrain décrivent ce que les utilisateurs Chrome éligibles ont réellement vécu. Le Chrome User Experience Report, généralement abrégé en CrUX, agrège les mesures issues de visites réelles et rapporte le 75e percentile : la valeur à laquelle ou en dessous de laquelle 75 % des expériences enregistrées se situent. Il inclut l’imprévisibilité des appareils réels, des réseaux, des emplacements, des caches, des outils de consentement, des sessions et des interactions. Utilisez-le pour décider si les utilisateurs franchissent les seuils publiés et si un changement déployé a finalement amélioré la population.

Les données de laboratoire décrivent un chargement de page ou une interaction contrôlée dans des conditions déclarées. Lighthouse est un test de laboratoire qui applique une simulation d’appareil et de réseau, capture une trace et explique les causes probables. Utilisez-le pour reproduire un problème, comparer deux versions dans la même configuration, inspecter les chaînes de requêtes et identifier le travail à effectuer. Un score de laboratoire est une preuve utile, mais il ne prouve pas que les utilisateurs réels réussissent.

Les deux sources peuvent diverger sans que l’une ou l’autre soit erronée. Un test de laboratoire rapide peut utiliser un emplacement proche, un CDN chaud et aucune interaction significative, tandis que les visiteurs terrain incluent des téléphones plus anciens et des réseaux distants. Enregistrez la divergence et étudiez ses conditions ; ne faites jamais la moyenne des valeurs et ne choisissez pas celle qui semble la plus favorable.

La liste de vérification

Effectuez ces vérifications dans l’ordre. Chaque élément indique l’action, la raison, la méthode, l’outil et la condition d’acceptation afin de pouvoir être assigné et retesté.

1. Geler la matrice d’URL et de conditions représentatives

Quoi : définir les URL, les modèles, les profils d’appareils, les zones géographiques, les états de consentement et les états de cache à tester. Pourquoi : un audit limité à la page d’accueil peut réussir alors que le modèle produit, article ou panier échoue. Comment : croisez l’inventaire P2 avec les données de trafic et de priorité métier ; sélectionnez des exemples typiques, lourds et critiques pour la conversion. Outil : analytique, inventaire d’exploration, registre des versions et feuille de test partagée. Fait quand : chaque modèle prioritaire dispose d’un échantillon de production approuvé par le responsable et chaque test enregistre les hypothèses d’appareil, de réseau, d’emplacement, de connexion, de consentement et de cache.

2. Capturer la référence terrain CrUX

Quoi : enregistrer les métriques terrain p75 disponibles au niveau URL et, séparément, au niveau origine. Pourquoi : l’origine peut masquer un modèle faible, tandis qu’une URL individuelle à faible trafic peut ne pas avoir de données publiables. Comment : utilisez la même date d’observation et la même fenêtre de 28 jours, étiquetez explicitement URL vs origine, et enregistrez les valeurs vides comme « données insuffisantes ». Outil : AmICited Web Vitals et CrUX. Fait quand : chaque URL échantillonnée dispose des valeurs LCP, INP, CLS, FCP et TTFB ou d’un état inconnu documenté ; le niveau de source et la fenêtre sont sans ambiguïté.

3. Vérifier la fiabilité de la réponse avant d’évaluer les pixels

Quoi : répéter les requêtes et enregistrer le statut, les redirections, le Time to First Byte (TTFB), les délais d’attente et les réponses incohérentes. Le TTFB est l’intervalle entre le début de la requête et l’arrivée du premier octet de réponse. Pourquoi : une page ne peut pas s’afficher avant que son HTML ne commence à arriver, et une défaillance intermittente est plus grave qu’un ralentissement cosmétique. Comment : testez le comportement du cache à froid et à chaud depuis les régions concernées, inspectez le serveur timing et corrélez les anomalies avec les logs CDN et origine. Outil : moniteur de requêtes, panneau réseau du navigateur, observabilité CDN/origine et waterfall Lighthouse. Fait quand : les URL prioritaires renvoient la réponse 200 attendue sans sauts ni délais d’attente inattendus, et chaque réponse lente ou échouée fait l’objet d’un constat enregistré avec un responsable.

4. Diagnostiquer le Largest Contentful Paint

Quoi : identifier l’élément Largest Contentful Paint (LCP) et décomposer son temps en délai serveur, découverte de ressource, téléchargement de ressource et délai de rendu. Le LCP mesure le moment où le plus grand bloc de texte ou image visible termine son rendu. Pourquoi : compresser une image ne sert à rien lorsque le navigateur la découvre tardivement, et les modifications front-end ne peuvent pas effacer un délai d’origine lent. Comment : inspectez la trace et le waterfall, comparez les exécutions en cache et sans cache, vérifiez la priorité de préchargement, le dimensionnement d’image responsif, les ressources bloquant le rendu, le comportement des polices et le rendu côté client. Outil : Lighthouse, outils de performance du navigateur, waterfall des requêtes et inspection d’images. Fait quand : l’élément LCP réel et la sous-partie dominante sont nommés pour chaque modèle défaillant, avec une mesure avant reproductible et une hypothèse de correctif spécifique.

5. Diagnostiquer l’Interaction to Next Paint

Quoi : tester le parcours Interaction to Next Paint (INP) pour des actions réelles telles que l’ouverture de menu, le filtrage, l’ajout au panier, la saisie de formulaire et la fermeture du consentement. L’INP mesure le délai entre une interaction utilisateur et l’affichage de la prochaine mise à jour visuelle par le navigateur, en utilisant une interaction à haute latence de la visite. Pourquoi : une page peut sembler complète mais continuer à ignorer l’utilisateur pendant que JavaScript occupe le thread principal. Comment : reproduisez les actions importantes, inspectez les longues tâches et les gestionnaires d’événements, testez les scripts tiers, et séparez le délai d’entrée, le temps de traitement et le délai de présentation. Outil : CrUX, trace de performance du navigateur, profilage d’interaction et un appareil réaliste. Fait quand : chaque interaction importante a été exercée, l’interaction lente et la tâche responsable sont identifiées pour les modèles défaillants, et le correctif dispose d’un test d’interaction reproductible.

6. Diagnostiquer le Cumulative Layout Shift

Quoi : localiser les mouvements inattendus contribuant au Cumulative Layout Shift (CLS). Le CLS est un score sans unité représentant les mouvements visuels inattendus pendant la vie de la page. Pourquoi : une bannière tardive, une image non dimensionnée, une police échangée, une publicité ou un composant hydraté peuvent déplacer le lien sur lequel l’utilisateur s’apprête à cliquer et modifier l’endroit où l’extraction automatisée trouve le contenu. Comment : utilisez les régions de décalage de mise en page et un filmstrip, testez les assets différés et les états de consentement, et inspectez les éléments sans dimensions réservées. Outil : CrUX, trace Lighthouse, diagnostics de rendu du navigateur et capture de régression visuelle. Fait quand : chaque décalage matériel a un élément source, un déclencheur et un correctif d’espace réservé ou de rendu ; les mouvements attendus causés immédiatement par une action utilisateur sont documentés séparément.

7. Utiliser le FCP pour isoler le délai d’écran vide

Quoi : mesurer le First Contentful Paint (FCP), le temps jusqu’à ce que le navigateur affiche le premier contenu texte, image, canvas ou SVG. Pourquoi : le FCP distingue un premier signe de progression d’une page qui reste vide, bien qu’il ne prouve pas que le contenu principal est prêt. Comment : comparez le FCP avec le TTFB et le LCP, puis inspectez le CSS bloquant, les polices, les scripts, le balisage rendu serveur et le comportement de streaming. Outil : CrUX, Lighthouse et la trace réseau/performance. Fait quand : chaque FCP lent est attribué à un délai serveur, à un blocage de rendu, à un rendu côté client uniquement ou à une autre cause prouvée, plutôt que d’être simplement décrit comme « la page semble lente ».

8. Classer les constats par sévérité, portée et dépendance

Quoi : ordonner le backlog par niveau d’échec, trafic et modèles concernés, criticité métier et dépendance amont. Pourquoi : corriger cinq scores jaunes peut consommer le sprint alors qu’un seul échec TTFB rouge retarde chaque page sur l’origine. Comment : placez les échecs de fiabilité en premier, puis les métriques mauvaises avant celles à améliorer ; au sein d’une même sévérité, corrigez les causes partagées de plateforme et le TTFB avant le travail LPC aval. Outil : registre des constats, analytique, inventaire des modèles et estimation d’ingénierie. Fait quand : chaque constat a une sévérité, un nombre d’URL ou un périmètre de modèle concerné, des preuves, un responsable, un effort, une dépendance et une priorité explicite.

9. Valider l’implémentation en laboratoire

Quoi : comparer la version modifiée avec la référence enregistrée dans des conditions identiques. Pourquoi : les données terrain ne peuvent pas fournir un retour immédiat sur la publication, et une exécution « après » non reproductible ne peut pas établir que le changement de code a causé la différence. Comment : effectuez plusieurs échantillons contrôlés, comparez les médianes plutôt que la meilleure exécution unique, inspectez la trace pour détecter les régressions, et testez les interactions et mises en page critiques. Outil : Lighthouse, outils de performance du navigateur, publication en staging ou en production contrôlée, et surveillance des requêtes. Fait quand : la cause visée est supprimée, la métrique cible atteint le budget laboratoire convenu sur plusieurs exécutions répétées, aucune autre métrique critique ne régresse, et les preuves sont jointes au constat.

10. Annoter la publication et attendre la confirmation terrain

Quoi : enregistrer l’heure de déploiement, le périmètre, la métrique attendue et les dates de validation. Pourquoi : CrUX est une fenêtre glissante de 28 jours, donc les visites pré-déploiement restent dans le percentile rapporté après la publication du correctif. Comment : surveillez les erreurs immédiatement, vérifiez l’évolution directionnelle des données terrain à mesure que de nouvelles données arrivent, et effectuez la comparaison finale uniquement lorsqu’assez de jours post-publication représentent la fenêtre. Outil : journal de déploiement, AmICited Web Vitals, CrUX et surveillance. Fait quand : les vérifications techniques immédiates réussissent, l’annotation de publication est visible, et un responsable nommé et une date existent pour la confirmation terrain ; le constat n’est pas marqué « vérifié » sur la seule base des preuves de laboratoire.

Outils dans AmICited

Ouvrez https://app.amicited.com/audit/web-vitals pour comparer votre domaine avec des concurrents suivis à l’aide des données utilisateur réelles CrUX. L’audit place LCP, INP, CLS, FCP et TTFB dans un seul tableau, marque votre domaine et rend visibles les données terrain manquantes plutôt que de les transformer en zéro trompeur. Utilisez la comparaison pour répondre à deux questions : le domaine franchit-il les seuils publiés, et un concurrent servant la même audience a-t-il démontré un résultat terrain significativement meilleur.

La fonctionnalité Performance Impact relie les performances au niveau de la page avec la position et la probabilité de citation. Traitez cette relation comme une preuve de priorisation, et non comme une preuve que la vitesse seule a causé un changement de citation. Si une page lente citée et une page rapide non citée diffèrent en autorité, pertinence ou contenu, la performance n’est qu’une variable. Le signal utile est qu’une page concernée a suffisamment de valeur pour être corrigée et surveillée.

Pour l’utilisation opérationnelle, suivez Comment vérifier vos Core Web Vitals dans AmICited . Ce playbook définit le périmètre de l’audit, les décisions et la transmission ; le tutoriel couvre les clics et les lectures, donc le dupliquer ici créerait deux instructions qui pourraient diverger.

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

Évaluez les Core Web Vitals à partir des données terrain au 75e percentile. « Bon » signifie que la valeur p75 est inférieure ou égale à la limite du bon. Une valeur sur la limite appartient à la meilleure catégorie ; par exemple, un LCP d’exactement 2,5 secondes est bon. Les seuils de support FCP et TTFB guident le diagnostic et l’acceptation, mais ils ne font pas partie de l’évaluation de réussite des trois métriques des Core Web Vitals.

Utilisez ces règles de priorité :

1. Les requêtes échouées, les délais d’attente et les réponses invalides priment sur les scores. La fiabilité est la porte de livraison.
2. Corrigez les catégories mauvaises avant les catégories à améliorer. Le rouge est une expérience démontrée comme mauvaise, pas une opportunité de polissage.
3. Corrigez le TTFB avant le LCP lorsque le TTFB est défaillant. Le LCP ne peut pas se produire avant le début de la réponse, donc le délai backend consomme le budget LCP avant que le navigateur puisse afficher quoi que ce soit.
4. Privilégiez les causes partagées aux symptômes isolés. Une réparation de politique de cache sur quatre modèles prime sur quatre ajustements d’image distincts ayant une portée plus réduite.
5. Utilisez le trafic et la valeur du parcours au sein d’une même sévérité. Un INP de paiement mauvais ou un LCP d’article à fort trafic prime sur une archive à faible trafic dans la même catégorie.
6. Ne considérez pas une valeur CrUX vide comme bonne. Elle est inconnue. Utilisez des preuves de laboratoire reproductibles et un modèle comparable jusqu’à ce que le volume terrain existe.
7. Ne promettez pas un changement terrain immédiat. Validez le déploiement maintenant, puis laissez la fenêtre glissante remplacer les expériences plus anciennes avant d’accepter ou de rejeter le résultat terrain.

Livrable : le registre de correctifs de performance

Remettez à l’ingénierie un registre accompagné de son dossier de preuves. Un tableur, un outil de suivi de tickets ou un tableau de projet structuré est acceptable s’il préserve ces champs et permet le filtrage par modèle, sévérité, responsable et statut :

ID et constat :
URL et modèles concernés :
Parcours prioritaire et contexte de trafic :
Métrique et catégorie terrain :
Niveau CrUX, valeur p75 et fenêtre de 28 jours :
Configuration laboratoire et référence répétée :
Cause observée et référence de preuve :
Condition attendue et objectif :
Modification recommandée :
Sévérité et justification de priorité :
Responsable, dépendance et effort :
Date de publication et annotation :
Résultat d'acceptation laboratoire immédiat :
Date et résultat de confirmation terrain :
Statut : Ouvert | Planifié | Accepté en laboratoire | Vérifié terrain | Risque accepté

Joignez la matrice d’URL, l’export CrUX, les traces laboratoire, les waterfalls, les filmstrips, les enregistrements d’interaction, les preuves de décalage de mise en page et les annotations de publication. Dédupliquez par cause : si la même requête d’origine non mise en cache crée un mauvais TTFB sur trois modèles, créez un constat parent avec trois périmètres concernés plutôt que trois diagnostics concurrents.

« Risque accepté » nécessite un approbateur nommé, une raison, un périmètre concerné, une date d’expiration ou de révision et une condition de surveillance. Ce n’est pas un substitut à un responsable. La transmission est complète lorsqu’un ingénieur peut reproduire l’échec et que le responsable de la phase suivante peut identifier quels résultats restent limités par la performance.

Ce qui peut mal tourner

Traiter Lighthouse comme verdict. Un score de 100 lors d’un test de laboratoire unique n’annule pas de mauvaises données terrain p75. Conservez Lighthouse comme preuve diagnostique et CrUX comme preuve populationnelle.

Tester uniquement la page d’accueil. Échantillonnez chaque modèle à forte valeur plus un exemple lourd, sinon les défauts de modèles échapperont à l’audit.

Optimiser l’image LCP avant de vérifier le TTFB. L’asset peut être petit pendant que l’origine passe deux secondes à générer le HTML. Décomposez le LCP en ses composants et corrigez le temps amont en premier.

Utiliser l’exécution la plus rapide unique. La chaleur du cache, l’activité en arrière-plan et la variation réseau peuvent créer un résultat flatteur aberrant. Gardez la configuration fixe et comparez les médianes des exécutions répétées.

Déclarer victoire le lendemain de la publication. Le laboratoire peut prouver que le code et la livraison ont changé immédiatement ; la fenêtre terrain de 28 jours ne le peut pas. Annotez la publication et planifiez l’acceptation terrain.

Marquer les données CrUX manquantes comme zéro. Aucune donnée signifie que le seuil d’éligibilité ou de trafic n’a pas été atteint. Cela ne dit rien sur la qualité des performances.

Chercher le score composite plutôt que l’expérience défaillante. Un score récapitulatif peut s’améliorer alors qu’une interaction de paiement continue de bloquer ou qu’un héros continue de se décaler. Acceptez des métriques et des parcours nommés, pas un mouvement de score cosmétique.

Supprimer des fonctionnalités utiles pour gagner un test. Supprimer le consentement, la personnalisation, l’analytique ou l’accessibilité de la variante laboratoire produit un résultat que les utilisateurs ne reçoivent jamais. Optimisez l’exigence de production ou prenez une décision produit explicite.

Ignorer les régressions en dehors de la métrique cible. Reporter les scripts peut améliorer le LCP mais créer un mauvais INP à la première interaction ; réserver les mauvaises dimensions peut remplacer un délai de chargement par du CLS. Retestez les cinq métriques et le parcours critique.

Phase suivante : accessibilité IA et préparation aux agents

La phase Accessibilité IA et préparation aux agents reçoit la matrice d’URL représentative, les preuves de fiabilité des réponses, la distribution du TTFB, les constats de performance non résolus et une déclaration sur le contenu présent dans la réponse initiale. Son responsable utilise ces preuves pour distinguer un échec de politique d’accès d’un échec de livraison et pour reproduire les conditions réelles dans lesquelles un agent récupère la page.

La phase suivante peut commencer lorsque les URL critiques répondent de manière fiable et qu’aucun défaut de performance non résolu ne rend les preuves de récupération ininterprétables. Elle peut avancer avec une limitation écrite lorsqu’une métrique à améliorer affecte les utilisateurs mais n’empêche pas un accès stable. Elle doit marquer une pause pour les modèles concernés lorsque les requêtes expirent, renvoient des erreurs intermittentes, ou que la réponse principale dépasse régulièrement le seuil critique convenu.

La transmission est complète lorsque le prochain responsable sait quelles URL représentent chaque modèle, les conditions de test, les échecs de livraison restants, et si les preuves de la phase P3 expliquent déjà une récupération lente par un agent.

FAQ

Questions fréquentes