Presupuestos de rendimiento web: cómo definirlos y aplicarlos en CI

La mayoría de los equipos arregla un sitio lento una vez, celebra la puntuación de Lighthouse y sigue adelante. Unos meses después, el sitio vuelve a ser lento. Nadie lanzó una sola regresión grande. Una fuente aquí, un script de seguimiento allá, una librería de gráficos que parecía inofensiva en la revisión: cada cambio fue pequeño, y nada los detuvo.

Un presupuesto de rendimiento es la forma de frenar esa deriva. Es un conjunto de números que un equipo acuerda no superar, integrado en las mismas verificaciones de pull request que ya bloquean fusiones. Para quien dirige el proceso de lanzamiento de un producto, esa diferencia importa más que qué métrica específica se elija primero.

Esto es lo que cubre el artículo: qué es un presupuesto de rendimiento, cómo definir el primero sin adivinar, umbrales concretos para empezar, y cómo lograr que la integración continua lo haga cumplir en vez de solo reportarlo.

Qué es realmente un presupuesto de rendimiento

Un presupuesto de rendimiento no es un solo número. Un presupuesto útil combina tres tipos de métricas a la vez: hitos de tiempo, cantidad de recursos y una puntuación basada en reglas.

Los hitos de tiempo miden lo que experimenta el usuario: First Contentful Paint, el momento en que aparece algo en pantalla, y Time to Interactive, el momento en que la página responde a la interacción. La cantidad de recursos mide lo que el navegador tiene que descargar y ejecutar antes de poder alcanzar esos objetivos de tiempo, casi siempre el tamaño del JavaScript y el CSS de la ruta crítica. Una métrica basada en reglas establece un piso sobre una puntuación compuesta, típicamente la categoría de rendimiento de Lighthouse, de modo que un solo número pueda bloquear una compilación incluso cuando nadie quiere analizar cinco umbrales distintos.

Tratar estas tres cosas como un solo contrato combinado importa porque fallan de forma independiente. Un equipo puede lograr un Time to Interactive rápido en la máquina de un desarrollador mientras envía 400KB de JavaScript que se atasca en un teléfono de gama media con 4G. Esto se superpone directamente con el tipo de verificaciones estructurales que cubre una auditoría técnica de SEO: los Core Web Vitals son un factor de posicionamiento, así que un presupuesto de rendimiento y una auditoría de SEO están aplicando buena parte del mismo contrato subyacente desde dos ángulos distintos.

Cómo definir tu primer presupuesto

Adivinar un número y esperar que se mantenga es la forma más común en que un presupuesto de rendimiento termina ignorado en menos de un mes. Defínelo a partir de mediciones reales.

Empieza por identificar las páginas con más tráfico o más peso para el negocio, y mide First Contentful Paint y Time to Interactive en cada una con Lighthouse, en un perfil de navegador limpio, sin extensiones, tanto en escritorio como en móvil. Esos números son tu línea base, no tu objetivo.

Después, compara contra la competencia. Elige entre 8 y 10 sitios comparables y repite la misma medición en ellos. La investigación detrás de este enfoque encontró que los usuarios notan una diferencia a partir de aproximadamente un 20 por ciento, lo que da un objetivo concreto en lugar de uno arbitrario: apuntar a ser al menos un 20 por ciento más rápido que el competidor más veloz.

Para un sitio que ya existe y ya tiene tráfico, no conviene fijar ese número competitivo desde el primer día. Define el primer presupuesto un 20 por ciento más rápido que el rendimiento actual propio, y luego ajústalo por etapas a medida que el equipo cierra la brecha. Un presupuesto que nadie puede cumplir en el primer sprint termina desactivado silenciosamente en el segundo.

Cómo elegir los umbrales iniciales

Los números concretos ayudan a que un equipo deje de debatir y empiece a actuar. Un presupuesto inicial razonable se ve así: Time to Interactive por debajo de 5 segundos en 3G lento, First Contentful Paint por debajo de 2 segundos, una puntuación de rendimiento de Lighthouse de 80 a 85, y recursos de la ruta crítica alrededor de 170KB en una conexión 3G lenta.

Estos números cambian según el contexto. Un sitio con mucho contenido, donde los lectores sobre todo se desplazan y leen, debería dar más peso a First Contentful Paint. Una herramienta o panel, donde se espera poder hacer clic de inmediato, debería dar más peso a Time to Interactive. La estrategia de renderizado también cambia la ecuación: una página construida con regeneración estática incremental puede lograr un Time to Interactive rápido a bajo costo porque el HTML ya está construido, lo que suele desplazar el cuello de botella del presupuesto desde el tiempo de respuesta del servidor hacia la ejecución de JavaScript en el cliente.

Trata cada número aquí como un punto de partida, no como un techo que defender para siempre. Medir tu propia línea base primero te da una razón defendible para ajustar el número cada trimestre en lugar de discutir sobre una suposición.

Cómo aplicar los presupuestos en CI con Lighthouse CI

Un presupuesto que vive en un documento que nadie revisa no es un presupuesto. Necesita ejecutarse en cada pull request y bloquear la compilación cuando un cambio cruza el límite.

Lighthouse CI es la herramienta estándar actual para esto, configurada mediante un archivo lighthouserc.json con bloques ci.collect y ci.assert. Dentro de ci.assert, cada auditoría recibe una severidad: off la omite, warn imprime un resultado sin bloquear la compilación, y error bloquea la compilación con un código de salida distinto de cero. Las opciones por aserto incluyen minScore para una puntuación entre 0 y 1, maxNumericValue para una métrica de tiempo en milisegundos, y maxLength para un conteo de elementos. Un atajo como categories:performance con error y un minScore permite que una sola línea controle toda la puntuación de la categoría.

Los presupuestos de recursos se pueden definir de dos formas dentro de Lighthouse CI: asertos en línea con la forma resource-summary:<tipo>:size, medidos en bytes, o un archivo budget.json separado, medido en kilobytes, que no se puede combinar con otros asertos personalizados en la misma configuración. Elige un enfoque por proyecto y ten en cuenta ese desajuste de unidades cuando algo falle por lo que parece un factor de mil.

Ejecuta la verificación contra una URL de vista previa o staging ya desplegada, no contra localhost. El tiempo de respuesta del servidor real y las condiciones de red reales cambian los números lo suficiente como para que algo que pasa en localhost aún pueda regresar en producción. Es el mismo tipo de verificación que corre un equipo de desarrollo web antes de cualquier lanzamiento de un sitio de cliente: un control que tiene que pasar antes de que el código llegue a los usuarios, no un número que alguien recuerda revisar después.

Herramientas de tamaño de paquete como alternativa más ligera

Lighthouse CI es completo, pero también requiere más configuración de la que algunos equipos necesitan el primer día. Dos herramientas más ligeras cubren una porción más estrecha pero igualmente útil del mismo problema.

Bundlesize verifica el tamaño del activo comprimido con gzip contra un umbral por archivo y se integra directamente con CI: si la verificación falla, el pull request no se fusiona. Es un control estricto con casi ninguna configuración. Las alertas de rendimiento integradas de webpack comparan el tamaño del paquete sin comprimir contra un límite por defecto de 250KB, pero por defecto solo imprimen una advertencia en lugar de bloquear la compilación, así que un equipo tiene que conectar explícitamente esa advertencia a un código de salida fallido para que sea un control real y no solo una sugerencia.

Una herramienta más ligera como bundlesize suele ser suficiente para un equipo que sobre todo quiere evitar que los paquetes de JavaScript crezcan sin control con el tiempo. Lighthouse CI completo justifica su costo de configuración cuando al equipo también le importa el tiempo de renderizado, las regresiones de accesibilidad, o una puntuación compuesta que tanto producto como ingeniería puedan revisar juntos.

Por qué los presupuestos fallan sin aplicación real

Un estudio interno de Google encontró que aproximadamente el 40 por ciento de los sitios pierde rendimiento dentro de seis meses después de un esfuerzo inicial de optimización. El presupuesto casi siempre estaba bien definido. Lo que faltaba era la segunda mitad del trabajo: un proceso de compilación que realmente falle cuando se cruza el presupuesto, y un lugar fuera del equipo de ingeniería donde el número siga siendo visible, ya sea un panel compartido o un reporte periódico que alguien más lea.

Esa combinación, un número, un control y visibilidad, es todo el punto. Un presupuesto sin un control es un deseo. Un control sin visibilidad es algo que ingeniería termina evadiendo silenciosamente bajo presión de plazos. Conviene empezar con un solo número aplicado en CI antes de construir un budget.json completo, porque un control que funciona vale más que cinco controles a medio terminar. Los equipos que quieren tener esto implementado sin construirlo ellos mismos pueden acudir a nuestro equipo de desarrollo web en lugar de armar la configuración de Lighthouse CI desde cero.

Preguntas frecuentes

¿Qué es un presupuesto de rendimiento web?

Un presupuesto de rendimiento es un conjunto de límites numéricos acordados, que normalmente combina métricas de tiempo como First Contentful Paint y Time to Interactive, métricas de tamaño de recursos como el peso total de JavaScript, y una puntuación mínima de Lighthouse, que un sitio se compromete a respetar a medida que cambia con el tiempo.

¿Cuál es una puntuación de rendimiento de Lighthouse razonable para empezar?

La mayoría de los equipos empieza alrededor de 80 a 85 sobre 100 para la categoría de rendimiento de Lighthouse, y luego ajusta el umbral a medida que el código se estabiliza. El número importa menos que tratarlo como un piso que se aplica en cada pull request en lugar de un objetivo que se revisa de vez en cuando.

¿Un presupuesto de rendimiento tiene que ejecutarse en cada pull request?

Debería. Los presupuestos que solo se revisan en un calendario fijo o de forma manual suelen detectar las regresiones después de que ya se publicaron. Conectar la verificación al mismo pipeline de CI que bloquea las fusiones es lo que realmente evita que un cambio lento llegue a producción.