Performance Budget: Definición, Ejemplos, Integración CI

Q: ¿Buen budget starter?

LCP < 2.5s, JS < 200KB gzipped, Lighthouse Perf ≥ 90.

Q: ¿Diferencia con Core Web Vitals?

CWV son las métricas. Performance budget = compromiso del equipo.

Q: ¿Si PR excede budget por buena razón?

Subir budget conscientemente o optimizar.

Q: ¿SPAs necesitan budgets diferentes?

Sí — bundles JS más grandes permitidos, pero TTI/INP críticos.

Performance budget es un set de límites en métricas como tamaño bundle JS, LCP, INP, CLS — enforced en CI para prevenir regresiones.

¿Qué es un performance budget?

Un performance budget es un set de límites explícitos en métricas web performance — tamaños bundle, peso página, Core Web Vitals (LCP, INP, CLS), conteos requests, peso scripts third-party — al que el equipo se compromete. Enforced en CI, el budget falla builds que exceden límites, previniendo regresiones performance de shippearse.

Sin un budget, el perf rot es invisible. Un budget hace el costo visible.

Categorías performance budget

Tipo	Qué limita	Ejemplo
Quantity-based	Número recursos	≤ 50 HTTP requests
Size-based	Bytes transferidos	JS < 200KB gzipped
Time-based	Métricas performance	LCP < 2.5s en 4G
Score-based	Scores Lighthouse	Lighthouse Perf ≥ 90
Rule-based	Anti-patterns específicos	Sin JS render-blocking

Ejemplo performance budget

[
  {
    "path": "/*",
    "timings": [{ "metric": "interactive", "budget": 3000 }],
    "resourceSizes": [
      { "resourceType": "script", "budget": 200 },
      { "resourceType": "image", "budget": 500 },
      { "resourceType": "total", "budget": 1500 }
    ]
  }
]

Baselines recomendadas

Métrica	Buen budget	Stretch goal
LCP	< 2.5s	< 1.8s
INP	< 200ms	< 100ms
CLS	< 0.1	< 0.05
Bundle JS (gzipped)	< 200KB	< 100KB
Peso total página	< 1.5MB	< 1MB
HTTP requests	< 50	< 30
Score Lighthouse Perf	≥ 90	≥ 95
Requests third-party	< 10	< 5

Tools para enforcing

Tool	Cómo enforce
Lighthouse CI	Corre Lighthouse en cada PR
SpeedCurve	Trackea budget over time
Bundle Analyzer	Visualiza composición bundle
size-limit	NPM package; CI falla if exceed
WebPageTest CI	Testing field-grade
Calibre	Performance monitoring + budgeting
Lighthouse (manual)	Dev local
Cloudflare Observatory	Tests sintéticos

Dónde empezar

Auditar performance actual
Setear budget en baseline actual
Añadir Lighthouse CI
Fallar PRs que excedan budget
Iterar: tightnear budget

Mejores prácticas performance budget

Empezar con performance actual.
Budget por tipo página.
Fallar loud en CI.
Trackear trends.
Testear en devices lentos.
Trackear impacto third-party separado.
Owner por métrica.
Visible en dashboard.

Pitfalls comunes

Budgets aspiracionales.
Sin follow-up en regresiones.
Varianza per-PR.
Testing lab-only.
Olvidar third-party.
Solo page-level.
Sin budget para páginas nuevas.

Performance budget vs SLI/SLO

Aspecto	Performance budget	SLI/SLO
Cuándo medido	Build time (lab)	Producción (field)
Enforced vía	CI fallando PRs	Alertas + error budgets
Owner	Equipo frontend	SRE / platform
Mejor previniendo	Regresiones code-side	Incidentes infra

FAQ: performance budget

¿Buen budget starter?

LCP < 2.5s, JS < 200KB gzipped, Lighthouse Perf ≥ 90.

¿Diferencia con Core Web Vitals?

CWV son las métricas. Performance budget = compromiso del equipo.

¿Puedo budgetar por página?

Sí.

¿Lab o field data para budget?

Ambos.

¿Si PR excede budget por buena razón?

Subir budget conscientemente o optimizar.

¿Con qué frecuencia revisar budgets?

Trimestralmente.

¿SPAs necesitan budgets diferentes?