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.
← Guides All guides in this topic
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
| # | Check | Pass looks like |
|---|---|---|
| 1 | Field data pulled | CrUX or RUM for the key templates, mobile 75th percentile |
| 2 | LCP element identified | You can name the element and its URL on the money page |
| 3 | LCP media budget | Hero under a sensible weight, modern format, sized, preloaded if needed |
| 4 | TTFB sane | Cached or static HTML keeps TTFB out of the danger zone |
| 5 | JS on critical path | No chat, A/B, or heavy hydration before first interaction need |
| 6 | INP spot-check | Primary taps stay responsive on a mid-tier phone |
| 7 | Fonts | Subset, self-host or controlled CDN, no multi-second invisible text |
| 8 | CLS reserved space | Images, embeds, and ads have dimensions or aspect-ratio boxes |
| 9 | Third parties listed | Every tag has an owner and a reason to live |
| 10 | Cache headers | HTML and assets have intentional cache policy, not accidents |
| 11 | Template parity | Homepage, hub, and article templates each checked, not only home |
| 12 | Stop rule | You stop when field CWV passes, not when Lighthouse hits 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.