Performance budget : définition et exemples

Qu'est-ce qu'un performance budget ?

Un performance budget (budget de performance) est un ensemble de limites sur les métriques qui influencent la vitesse d'un site, comme la taille des scripts, le nombre de requêtes, le poids de la page ou les temps de chargement. L'équipe fixe les limites à l'avance et les traite comme n'importe quelle autre exigence : un changement qui fait dépasser une limite est corrigé, ou la limite est modifiée volontairement. Cela transforme "rends-le plus rapide" en un chiffre vérifiable à chaque version.

Pourquoi un budget est utile

Une page devient rarement lente d'un coup. Chaque changement ajoute un peu de script, une image ou une balise, et aucun n'a l'air coupable. Un budget rend le coût visible au moment du changement, quand il est le moins cher à corriger.

Types de performance budgets

• Basé sur la quantité. Nombres et tailles : JavaScript en kilo-octets, nombre de requêtes, polices web, ressources tierces.
• Jalons de temps. Moments du chargement comme le First Contentful Paint ou le Time to Interactive, et métriques centrées sur l'utilisateur : Largest Contentful Paint, Interaction to Next Paint et Cumulative Layout Shift.
• Basé sur des règles. Un score Lighthouse minimal ou une règle comme aucun script bloquant le rendu.

web.dev recommande de combiner des limites de quantité et des métriques centrées sur l'utilisateur. Les limites de taille sont faciles à appliquer à chaque build, tandis que les temps décrivent ce que ressentent les utilisateurs.

Exemple

Lighthouse lit un fichier de budget et rapporte les écarts :

# budget.json
[
  {
    "path": "/*",
    "timings": [{ "metric": "interactive", "budget": 3000 }],
    "resourceSizes": [
      { "resourceType": "script", "budget": 125 },
      { "resourceType": "total", "budget": 300 }
    ],
    "resourceCounts": [{ "resourceType": "third-party", "budget": 10 }]
  }
]

lighthouse https://example.com --budget-path=./budget.json

Cet exemple limite le Time to Interactive à 3000 ms, le JavaScript à 125 Ko, le poids total à 300 Ko et les requêtes tierces à 10. Les unités sont les millisecondes pour les temps et les kilo-octets pour les tailles. Choisissez les chiffres d'après vos propres mesures, pas d'après un exemple.

Choisir les chiffres

1. Mesurez trois à cinq pages représentatives avec un profil mobile bridé.
2. Fixez chaque limite à la valeur actuelle ou légèrement en dessous, pour que le premier passage réussisse et que toute dérive échoue.
3. Utilisez les seuils "bons" des Core Web Vitals comme cibles : LCP de 2,5 secondes ou moins, INP de 200 millisecondes ou moins, CLS de 0,1 ou moins, évalués au 75e centile des chargements de page (web.dev). Voir les Core Web Vitals.
4. Définissez des budgets distincts par type de page. Une page marketing et un tableau de bord n'ont pas les mêmes besoins.
5. Réexaminez les limites régulièrement et resserrez-les quand le site progresse.

Les images sont souvent l'élément le plus lourd, commencez donc par la taille des images.

Comment appliquer un budget

• Dans le build. Lighthouse avec un fichier de budget, un contrôle de taille du bundle ou un outil comme Lighthouse CI, pour qu'une pull request échoue dès qu'elle dépasse une limite.
• En production. Le contrôle du build ne voit que le code. Des audits planifiés du site en ligne détectent les régressions dues aux balises tierces, au contenu et à l'infrastructure. La supervision de vitesse LoadFocus exécute des audits Lighthouse planifiés depuis 25 régions cloud, permet de fixer des budgets Core Web Vitals et alerte par email, Slack ou Microsoft Teams quand une valeur franchit le seuil. Pour un coup d'œil ponctuel, utilisez le vérificateur de Core Web Vitals.

Le guide définir des performance budgets pour des applications web (en anglais) détaille la mise en place.

Erreurs courantes

• Des budgets si serrés que tout changement échoue. L'équipe finit par désactiver le contrôle.
• Des avertissements que personne ne traite. Un budget qui ne bloque rien reste une suggestion.
• Juger sur une seule mesure bruitée. Les résultats de laboratoire varient, comparez plusieurs passages ou suivez la tendance.
• Du laboratoire uniquement. Une page peut réussir en laboratoire et rester lente pour de vrais utilisateurs.
• Oublier les scripts tiers. Les balises ajoutées par le marketing consomment souvent l'essentiel du budget.
• Un seul budget pour tout le site. Les parcours critiques comme le paiement ont leurs propres limites.

Questions fréquentes : performance budget

À quoi ressemble un premier budget ?

Partez de vos valeurs mesurées sur quelques pages clés, fixez les limites à ce niveau ou juste en dessous, et ajoutez les seuils Core Web Vitals comme cibles de temps. Resserrez ensuite.

En quoi est-ce différent des Core Web Vitals ?

Les Core Web Vitals sont les métriques. Un performance budget est la limite que votre équipe se fixe sur ces métriques et sur des éléments comme la taille des scripts et le nombre de requêtes.

Faut-il s'appuyer sur des données de laboratoire ou de terrain ?

Sur les deux. Les outils de laboratoire comme Lighthouse conviennent aux contrôles de build car ils sont reproductibles. Les données de terrain montrent ce que vivent les vrais utilisateurs.

Que faire si un changement dépasse le budget pour une bonne raison ?

Soit optimiser jusqu'à rentrer dans la limite, soit relever la limite volontairement, avec l'accord de l'équipe et une note expliquant pourquoi. Ne contournez pas le contrôle en silence.