Performance budget: definición y ejemplos

¿Qué es un performance budget?

Un performance budget (presupuesto de rendimiento) es un conjunto de límites sobre métricas que afectan a la velocidad de un sitio, como el tamaño de los scripts, el número de peticiones, el peso de la página o los tiempos de carga. El equipo acuerda los límites de antemano y los trata como cualquier otro requisito: un cambio que lleve la página por encima de un límite se corrige, o el límite se modifica a propósito. Convierte "hazlo más rápido" en una cifra que puedes comprobar en cada versión.

Tipos de performance budget

• Basado en cantidad. Recuentos y tamaños: JavaScript en kilobytes, número de peticiones, fuentes web, recursos de terceros.
• Hitos de tiempo. Momentos de la carga como First Contentful Paint o Time to Interactive, y métricas centradas en el usuario: Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift.
• Basado en reglas. Una puntuación mínima de Lighthouse o una regla como no tener scripts que bloqueen el renderizado.

web.dev recomienda combinar límites de cantidad con métricas centradas en el usuario.

Ejemplo

Lighthouse lee un archivo de presupuesto y informa frente a él:

# 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

El ejemplo limita Time to Interactive a 3000 ms, JavaScript a 125 KB, el peso total a 300 KB y las peticiones de terceros a 10. Las unidades son milisegundos para tiempos y kilobytes para tamaños. Elige las cifras a partir de tus propias mediciones, no de un ejemplo.

Elegir las cifras

1. Mide tres a cinco páginas representativas con un perfil móvil limitado.
2. Fija cada límite en el valor actual o algo por debajo, para que la primera ejecución pase y cualquier retroceso falle.
3. Usa los umbrales "buenos" de Core Web Vitals como objetivos: LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos, CLS de 0,1 o menos, evaluados en el percentil 75 de las cargas de página (web.dev). Mira las Core Web Vitals.
4. Define presupuestos distintos por tipo de página.

Las imágenes suelen ser lo más pesado, así que empieza por el tamaño de imagen.

Cómo hacer cumplir un presupuesto

• En la compilación. Lighthouse con un archivo de presupuesto, una comprobación del tamaño del bundle o una herramienta como Lighthouse CI, para que un pull request falle al superar un límite.
• En producción. La comprobación de compilación solo ve el código. Las auditorías programadas del sitio real detectan regresiones por etiquetas de terceros, contenido e infraestructura. La monitorización de velocidad de LoadFocus ejecuta auditorías Lighthouse programadas desde 25 regiones cloud, permite fijar presupuestos de Core Web Vitals y avisa por email, Slack o Microsoft Teams cuando un valor cruza el umbral. Para una revisión puntual, usa el verificador de Core Web Vitals.

La guía cómo fijar performance budgets en apps web (en inglés) profundiza en la puesta en marcha.

Errores habituales

• Presupuestos tan ajustados que todo cambio falla y el equipo desactiva la comprobación.
• Avisos que nadie atiende.
• Juzgar una sola ejecución con ruido en lugar de varias o de tendencias.
• Usar solo datos de laboratorio, cuando los usuarios reales pueden ir más lentos.
• Olvidar los scripts de terceros, que a menudo consumen la mayor parte del presupuesto.

Preguntas frecuentes: performance budget

¿Cómo debe ser un primer presupuesto?

Parte de tus valores medidos en unas pocas páginas clave, fija los límites en ese valor o algo por debajo y añade los umbrales de Core Web Vitals como objetivos de tiempo. Aprieta más adelante.

¿En qué se diferencia de las Core Web Vitals?

Las Core Web Vitals son las métricas. Un performance budget es el límite que acuerda tu equipo sobre esas métricas y sobre cosas como el tamaño de los scripts y el número de peticiones.

¿Debe basarse en datos de laboratorio o de campo?

En ambos. Las herramientas de laboratorio como Lighthouse sirven para las comprobaciones de compilación porque son repetibles. Los datos de campo muestran lo que viven los usuarios reales.