LA CHECKLIST CWV
Les douze vérifications que j'effectue avant de déclarer un site ou un template prêt au lancement. Assez court pour être utilisé, assez strict pour attraper les vrais dysfonctionnements.
← Tous les guides Tous les guides de ce sujet
Pourquoi les checklists courtes fonctionnent
Les longs audits de performance sont ignorés. Une liste de douze éléments qu'un développeur lead peut vérifier en une après-midi se fait utiliser. C'est la liste que je parcours avant le lancement, avant un changement de template majeur, et après chaque surprise « on a juste ajouté un petit script ».
Cela suppose que vous connaissez déjà les métriques. Si vous avez besoin de l'histoire du diagnostic, lisez pourquoi votre site est lent. Si vous avez besoin d'une intervention chirurgicale sur une métrique, lisez le guide LCP, INP, CLS. Cette page est le portail.
L'essentiel : une checklist que vous terminez vaut mieux qu'un audit de 40 pages que personne n'ouvre deux fois.
Les 12 points
| # | Vérification | Voici à quoi ressemble un Pass |
|---|---|---|
| 1 | Données extraites | CrUX ou RUM pour les templates clés, percentile 75 mobile |
| 2 | Élément LCP identifié | Vous pouvez nommer l'élément et son URL sur la page rentable |
| 3 | Budget média LCP | Hero sous un poids raisonnable, format moderne, dimensionné, préchargé si nécessaire |
| 4 | TTFB sain | HTML en cache ou statique maintient TTFB hors de la zone de danger |
| 5 | JS sur le chemin critique | Pas de chat, A/B, ou hydratation lourde avant le premier besoin d'interaction |
| 6 | Vérification ponctuelle INP | Les taps principaux restent réactifs sur un téléphone de milieu de gamme |
| 7 | Polices | Sous-ensemble, auto-hébergées ou CDN contrôlé, pas de texte invisible sur plusieurs secondes |
| 8 | Espace réservé CLS | Les images, embeds et publicités ont des dimensions ou des boîtes aspect-ratio |
| 9 | Tiers tiers répertoriés | Chaque tag a un propriétaire et une raison d'être |
| 10 | En-têtes de cache | HTML et ressources ont une politique de cache intentionnelle, pas accidentelle |
| 11 | Parité des templates | Templates d'accueil, hub et article chacun vérifiés, pas seulement la page d'accueil |
| 12 | Règle d'arrêt | Vous arrêtez quand Core Web Vitals passe, pas quand Lighthouse atteint 100 |
Imprimez-la, collez-la dans le ticket de lancement, ou utilisez-la comme checklist de PR. L'important est un passage ou un échec binaire par ligne, pas des réponses sous forme d'essai.
L'essentiel : si vous ne pouvez pas cocher l'élément 1 et l'élément 2, vous n'êtes pas prêt pour les éléments 3 à 12.
Comment l'utiliser réellement
Lancez la liste sur les templates qui génèrent du revenu ou du classement : homepage, page d'atterrissage principale, catégorie ou hub, et une page d'article ou de produit représentative. Une homepage verte avec un template d'article rouge reste un lancement échoué.
Assignez un propriétaire par défaut. Le travail de performance sans propriétaire devient un fil Slack. Réexécutez les données de terrain une semaine après la publication, pas seulement en staging. Le staging ment sur les tiers externes, la chaleur du cache et les vrais appareils.
Quand tout passe, arrêtez. L'optimisation supplémentaire est un vernis de marque optionnel sauf si un test de conversion spécifique dit le contraire.
Élément clé : utilisez la checklist comme filtre sur les templates qui comptent, puis abandonnez quand les données terrain sont claires.
Ce pour quoi j'invalide les équipes
Qualifier un lab vert de réussite alors que Search Console affiche toujours un groupe d'URL médiocre. Livrer une nouvelle page marketing qui n'a jamais figuré sur la checklist. Laisser les chat widgets sur le chemin critique parce que les ventes l'ont demandé. Corriger le CLS en staging avec des emplacements publicitaires vides qui explosent en production.
Aussi : traiter la checklist comme une opération ponctuelle. Les templates dérivent. Un repassage trimestriel sur les pages importantes détecte la mort lente due à « juste une balise de plus ».
Si plus de trois lignes échouent, ne parallélisez pas douze micro-tâches. Corrigez d'abord le LCP et les tiers, puis relancez. La plupart des tableaux se règlent plus vite de cette façon qu'avec un sprint tous azimuts.
Élément clé : invalider le lancement quand les données terrain ou la couverture des templates manquent, pas quand un score lab de vanité atteint 89.
Où cette checklist s'inscrit dans l'ensemble
Utilisez why-is-my-website-slow quand vous avez toujours besoin du récit serveur versus front end. Utilisez le guide LCP, INP, CLS quand une métrique unique est au rouge et vous avez besoin de leviers. Utilisez le pilier performance quand la question concerne la feuille de route et l'investissement, pas un filtre de lancement.
Cette checklist est le travail fastidieux du milieu : binaire, répétable, assez courte pour que les gens la fassent réellement.
Élément clé : filtrez les lancements avec la checklist. Diagnostiquez avec les autres guides de performance.