LA CHECKLIST CWV
Les douze vérifications que j'effectue avant de considérer qu'un site ou un modèle est prêt à être mis en ligne. Suffisamment succinctes pour être faciles à utiliser, mais suffisamment rigoureuses pour détecter les véritables défaillances.
← Tous les guides Tous les guides de ce sujet
Pourquoi les listes de contrôle courtes sont efficaces
Les audits de performances trop longs sont souvent négligés. On préfère utiliser une liste de douze points qu’un développeur principal peut traiter en un après-midi. C’est cette liste que j’applique avant un lancement, avant une modification majeure du modèle, et après toute surprise du type « on a ajouté un petit script ».
Cette page part du principe que vous connaissez déjà les indicateurs. Si vous avez besoin d'un diagnostic, consultez l'article « Pourquoi votre site web est-il lent ? ». Si vous devez intervenir sur un indicateur en particulier, consultez le guide sur le LCP, l'INP et le CLS. Cette page sert de point d'entrée.
Point à retenir : une liste de contrôle que vous menez à bien vaut mieux qu'un rapport d'audit de 40 pages que personne ne relit jamais.
Les 12 articles
| # | Vérifier | Le pass ressemble à ceci : |
|---|---|---|
| 1 | Données de terrain extraites | CrUX ou RUM pour les modèles de clés, 75e centile mobile |
| 2 | Élément LCP identifié | Vous pouvez indiquer le nom de l'élément et son URL sur la page « money » |
| 3 | Budget média LCP | Hero : poids raisonnable, format moderne, dimensions adaptées, préchargé si nécessaire |
| 4 | TTFB raisonnable | Le code HTML mis en cache ou statique permet d'éviter que le TTFB n'atteigne la zone à risque |
| 5 | JS sur le chemin critique | Pas de discussion, pas de test A/B ni d'hydratation excessive avant la première interaction |
| 6 | Contrôle ponctuel de l'INP | Les boutons principaux restent réactifs sur un téléphone de milieu de gamme |
| 7 | Polices | Sous-ensemble, hébergement autonome ou CDN contrôlé, pas de texte invisible de plusieurs secondes |
| 8 | Espace réservé à CLS | Les images, les éléments intégrés et les publicités sont associés à des encadrés indiquant leurs dimensions ou leur rapport d'aspect |
| 9 | Tiers répertoriés | Chaque balise a un propriétaire et une raison d'être |
| 10 | En-têtes de cache | Les fichiers HTML et les ressources font l'objet d'une politique de mise en cache délibérée, et non pas fortuite. |
| 11 | Parité des modèles | Les modèles de page d'accueil, de page centrale et d'article ont tous été vérifiés, et pas seulement la page d'accueil |
| 12 | Règle d'arrêt | On s'arrête lorsque le CWV de champ est dépassé, et non lorsque le Lighthouse atteint 100. |
Imprimez-le, collez-le dans le ticket de lancement ou utilisez-le comme liste de contrôle pour les PR. L'important, c'est d'indiquer « réussi » ou « échoué » pour chaque ligne, et non de donner des réponses détaillées.
Point essentiel à retenir : si vous ne pouvez pas cocher les points 1 et 2, vous n'êtes pas prêt pour les points 3 à 12.
Comment s'en servir concrètement
Appliquez cette liste aux modèles qui génèrent des revenus ou améliorent le référencement : page d'accueil, page d'atterrissage principale, catégorie ou rubrique, ainsi qu'un article ou une fiche produit représentatifs. Une page d'accueil verte associée à un modèle d'article rouge constitue tout de même un lancement raté.
Désignez un responsable pour chaque défaillance. Les travaux liés aux performances menés sans responsable se transforment en fil de discussion sur Slack. Réexécutez les tests sur les données de terrain une semaine après la mise en production, et pas uniquement en environnement de préproduction. L'environnement de préproduction ne reflète pas fidèlement les tiers, la température du cache et les appareils réels.
Une fois que tout est terminé, arrêtez-vous là. Toute optimisation supplémentaire relève uniquement d'une amélioration de l'image de marque et n'est pas obligatoire, sauf si un test de conversion spécifique en décide autrement.
Point clé : utilisez la liste de contrôle comme filtre pour les modèles importants, puis passez à autre chose une fois que les données de terrain sont claires.
Les raisons pour lesquelles je rejette des équipes
Considérer que le « lab green » est validé alors que Search Console affiche toujours un groupe d’URL défaillant. Mettre en ligne une nouvelle page marketing qui ne figurait pas sur la liste de contrôle. Laisser des widgets de chat sur le chemin critique parce que le service commercial l’a demandé. Corriger le CLS en environnement de test avec des emplacements publicitaires vides qui posent problème en production.
Autre point : considérer la liste de contrôle comme un outil ponctuel. Les modèles évoluent. Une révision trimestrielle des pages consacrées aux finances permet d'éviter la « mort à petit feu » causée par « juste une balise de plus ».
Si plus de trois lignes présentent des erreurs, ne parallélisez pas les douze micro-tâches. Corrigez d'abord les problèmes liés à LCP et aux tiers, puis relancez l'opération. La plupart des cartes s'effacent plus rapidement de cette manière qu'avec une approche « à l'aveuglette ».
Point clé à retenir : il faut renoncer au lancement lorsque les données de terrain ou la couverture des modèles font défaut, et non lorsque le score d'un test de laboratoire « de prestige » est de 89.
Où se situe cette liste de contrôle au sein du groupe ?
Utilisez « why-is-my-website-slow » lorsque vous avez encore besoin d'une analyse comparative entre le serveur et le front-end. Utilisez le guide LCP, INP, CLS lorsqu'un indicateur est dans le rouge et que vous avez besoin de leviers d'action. Utilisez le pilier « performances » lorsque la question porte sur la feuille de route et les investissements, et non sur les conditions de lancement.
Cette liste de contrôle représente la partie intermédiaire, un peu rébarbative : binaire, reproductible, suffisamment courte pour que les gens la suivent réellement.
Point clé : Gate est lancé avec la liste de contrôle. Effectuez votre diagnostic à l'aide des autres guides de performance.