Performance Budget : Définition, Exemples, Intégration CI
Performance budget est un set de limites sur métriques comme taille bundle JS, LCP, INP, CLS — enforced en CI pour prévenir les regressions.
Qu'est-ce qu'un performance budget ?
Un performance budget est un set de limites explicites sur les métriques web performance — tailles bundle, poids page, Core Web Vitals (LCP, INP, CLS), counts requêtes, poids scripts third-party — auquel l'équipe s'engage. Enforced en CI, le budget fait échouer les builds qui dépassent les limites, prévenant les regressions performance d'être shippées.
Sans budget, le perf rot est invisible. Un budget rend le coût visible.
Catégories performance budget
| Type | Ce qu'il limite | Exemple |
|---|---|---|
| Quantity-based | Nombre ressources | ≤ 50 HTTP requests |
| Size-based | Bytes transférés | JS < 200KB gzipped |
| Time-based | Métriques performance | LCP < 2.5s sur 4G |
| Score-based | Scores Lighthouse | Lighthouse Perf ≥ 90 |
| Rule-based | Anti-patterns spécifiques | Pas de JS render-blocking |
Exemple performance budget
[
{
"path": "/*",
"timings": [{ "metric": "interactive", "budget": 3000 }],
"resourceSizes": [
{ "resourceType": "script", "budget": 200 },
{ "resourceType": "image", "budget": 500 },
{ "resourceType": "total", "budget": 1500 }
]
}
]Baselines recommandées
| Métrique | Bon budget | Stretch goal |
|---|---|---|
| LCP | < 2.5s | < 1.8s |
| INP | < 200ms | < 100ms |
| CLS | < 0.1 | < 0.05 |
| Bundle JS (gzipped) | < 200KB | < 100KB |
| Poids total page | < 1.5MB | < 1MB |
| HTTP requests | < 50 | < 30 |
| Score Lighthouse Perf | ≥ 90 | ≥ 95 |
| Requests third-party | < 10 | < 5 |
Outils pour enforcing
| Outil | Comment ça enforce |
|---|---|
| Lighthouse CI | Exécute Lighthouse sur chaque PR |
| SpeedCurve | Track budget over time |
| Bundle Analyzer | Visualise composition bundle |
| size-limit | NPM package ; CI échoue if exceed |
| WebPageTest CI | Testing field-grade |
| Calibre | Performance monitoring + budgeting |
| Lighthouse (manuel) | Dev local |
| Cloudflare Observatory | Tests synthétiques |
Où commencer
- Auditer la performance actuelle
- Définir budget à la baseline actuelle
- Ajouter Lighthouse CI
- Faire échouer les PRs qui dépassent le budget
- Itérer : tightener budget
Best practices performance budget
- Commencer avec performance actuelle.
- Budget par type de page.
- Échouer loud en CI.
- Tracker trends.
- Tester sur devices lents.
- Tracker impact third-party séparément.
- Owner par métrique.
- Visible en dashboard.
Pièges courants
- Budgets aspirationnels.
- Pas de follow-up sur regressions.
- Variance per-PR.
- Testing lab-only.
- Oublier third-party.
- Seulement page-level.
- Pas de budget pour nouvelles pages.
Performance budget vs SLI/SLO
| Aspect | Performance budget | SLI/SLO |
|---|---|---|
| Quand mesuré | Build time (lab) | Production (field) |
| Enforced via | CI échouant PRs | Alertes + error budgets |
| Owner | Équipe frontend | SRE / platform |
| Meilleur à prévenir | Regressions code-side | Incidents infra |
FAQ : performance budget
Bon budget starter ?
LCP < 2.5s, JS < 200KB gzipped, Lighthouse Perf ≥ 90.
Différence avec Core Web Vitals ?
CWV sont les métriques. Performance budget = engagement de l'équipe.
Puis-je budgeter par page ?
Oui.
Lab ou field data pour budget ?
Les deux.
Si PR dépasse budget pour bonne raison ?
Augmenter budget consciemment ou optimiser.
À quelle fréquence reviewer budgets ?
Trimestriellement.
SPAs ont-ils besoin de budgets différents ?
Oui — bundles JS plus grands permis, mais TTI/INP critiques.
Enforce performance budget avec LoadFocus
LoadFocus exécute des audits Lighthouse depuis 25+ régions on schedule. Inscrivez-vous sur loadfocus.com/signup.
Outils LoadFocus connexes
Mettez ce concept en pratique avec LoadFocus — la plateforme même qui propulse tout ce que vous venez de lire.