Lighthouse 100s como objetivo de build

La mayoría de equipos tratan Lighthouse como un chequeo de salud trimestral. astro-ignite parte de la idea opuesta: el rendimiento es un test, no una métrica — tu build falla antes de que la regresión llegue a producción. La mecánica no es novedosa; la disciplina sí.

Este post explica el contrato de presupuesto, lo que aprendimos migrando cuatro proyectos, y por qué los agentes manejan especialmente bien este tipo de restricción.

El contrato de presupuesto

Cada ruta puede declarar su presupuesto de rendimiento junto a la ruta misma, no en un config global. CI ejecuta Lighthouse contra el build de producción y rechaza el merge si algún score baja de 95 o el bundle de JS crece más de un 5%.

export const budget = {
  lcp: 2500,    // ms
  cls: 0.1,
  inp: 200,     // ms — antes FID pre-2024
  js:  18000,   // bytes, gzipped
};

Mantener el presupuesto en la ruta hace que cambiarlo sea una revisión de código, no una conversación de ops. El reviewer ve el delta del presupuesto en el mismo diff que la funcionalidad que lo necesitó. Eso solo ya atrapa la mayoría de las regresiones antes que CI.

Lo que aprendimos

Llegar a 100 una vez no es lo difícil. Mantener el 100 mientras se agregan funcionalidades sí. Trata el rendimiento como tratas a los tipos: una invariante que el build impone. El primer mes de cualquier proyecto es ruidoso; la gente romperá el presupuesto sin querer. Después de eso, el equipo se auto-edita. Las descripciones de PR empiezan a incluir deltas de presupuesto sin que nadie lo pida.

Modos de fallo

El falso positivo más común es una medición de LCP inestable en caché frío. Ejecuta Lighthouse tres veces por ruta y toma la mediana. El positivo real más común es una imagen nueva sin width × height explícitos. Una regla de lint lo atrapa barato.

El rendimiento es una feature. En el momento en que lo haces falible, dejas de discutir sobre él.

Por qué encaja con agentes

Los agentes son buenos en optimizaciones pequeñas y locales y malos recordando restricciones globales. Los presupuestos como código les dan un feedback loop sobre el que pueden actuar — fallar, leer el diff, arreglar, reintentar. En la práctica los agentes convergen a un presupuesto que pasa en dos o tres iteraciones sin intervención humana.

Cuidado con esto: si dejas que un agente ajuste dinámicamente el presupuesto para que un build falle pase, tendrás un sitio lento con el tiempo. Los presupuestos deben editarse a mano. El build impone el contrato; el contrato mismo queda fuera del alcance del agente.

Cierre

Los Lighthouse 100 no son un número de marketing. Son el artefacto de tratar el rendimiento como una invariante. astro-ignite trae estos presupuestos pre-cableados — modifícalos, ajústalos, cambia las métricas, pero no borres el chequeo.