Un budget de performance est une liste de plafonds par modèle de page, pas un slogan. Pour chaque famille (accueil, liste, fiche, paiement, article), vous fixez un LCP, un INP, un CLS, un poids transféré et un nombre de requêtes. Tant qu’une modification reste sous ces plafonds, elle peut partir. Au-dessus, elle attend une coupe.
Choisir des seuils que vous savez mesurer
Les seuils de terrain publiés par Google pour les Core Web Vitals sont un socle : LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1, lus au 75e centile. Ils décrivent une visite réelle, pas un test local sur fibre. Le détail de la collecte est dans Surveiller les Core Web Vitals.
Ajoutez des plafonds que Lighthouse sait casser dans une revue de code : poids compressé de la page, poids d’image au-dessus de la ligne de flottaison, nombre de fichiers JavaScript tiers. Lighthouse signale aussi un temps de réponse du document au-delà de 600 ms. Ce n’est pas un Core Web Vital, c’est un garde-fou de laboratoire utile dans le budget.
Ne copiez pas le même plafond partout. Une fiche produit chargée d’images n’a pas le même LCP qu’une page de contenu. Le paiement supporte moins de scripts tiers qu’un article.
| Modèle | LCP | INP | CLS | Repère de poids |
|---|---|---|---|---|
| Accueil | ≤ 2,5 s | ≤ 200 ms | ≤ 0,1 | HTML et CSS critiques légers, une image hero dimensionnée |
| Liste / catégorie | ≤ 2,5 s | ≤ 200 ms | ≤ 0,1 | Vignettes avec largeur et hauteur |
| Fiche | ≤ 2,5 s | ≤ 200 ms | ≤ 0,1 | Galerie qui ne pousse pas le texte |
| Paiement | plus strict si vous le pouvez | ≤ 200 ms | ≤ 0,1 | Aucun tag publicitaire |
| Article | ≤ 2,5 s | ≤ 200 ms | ≤ 0,1 | Polices limitées, peu de lecteurs embarqués |
Le LCP se travaille élément par élément. La méthode est dans Améliorer le LCP.
Où lire le chiffre
Au déploiement, une mesure de laboratoire (Lighthouse, WebPageTest) sur l’URL du modèle, mobile, réseau bridé. Elle voit la régression du jour : une librairie ajoutée, une image hero en PNG de plusieurs mégaoctets, un bandeau qui décale le titre.
Sur les visiteurs, PageSpeed Insights (bloc terrain quand le CrUX a assez de visites) et Search Console, rapport Signaux Web essentiels, sur 28 jours. Une page peut être verte en laboratoire et mauvaise sur mobile milieu de gamme. L’écart entre les deux méthodes est expliqué dans RUM et mesures de laboratoire.
Notez la date, l’URL exacte, le profil (mobile), et le nom de la ressource la plus lourde. Un budget sans URL de référence se discute, il ne se tient pas.
Tenir le budget au fil des changements
- Écrivez les plafonds à côté du modèle de page, dans le dépôt ou la fiche de recette, pas dans un slide.
- Avant une mise en production, mesurez l’URL de préproduction avec le même profil que la dernière campagne verte.
- Si le LCP, l’INP, le CLS ou le poids dépasse, nommez la ressource (script tiers, police, image, iframe) et retirez-la ou différez-la. Ne corrigez pas au hasard.
- Après la mise en ligne, gardez la mesure de laboratoire du jour et attendez le terrain pour confirmer. Le 75e centile ne bouge pas dans l’heure.
- Quand un tiers (tag, chat, A/B test) demande à être ajouté, il entre dans le budget du modèle concerné ou il n’entre pas.
Un dépassement accepté pour cette fois devient le nouveau plafond de fait. Écrivez l’exception, sa date de fin, et la page qu’elle couvre. Le paiement et la fiche restent les modèles où l’exception se justifie le moins.