Solía correr Lighthouse de la forma en que probablemente lo hace la mayoría: abrir DevTools, clickear el botón, mirar el puntaje de reojo, cerrar la pestaña. Atrapaba regresiones eventualmente, en el sentido de que eventualmente notaba que una página se sentía más lenta y me ponía a buscar por qué. “Eventualmente” no es una gran estrategia de detección de regresiones.
Convertirlo en una barrera, no en un hábito
Lighthouse CI corre las mismas auditorías contra la salida real ya construida, en cada pull request, y hace fallar la verificación si un puntaje baja de un umbral que fijé —90, en rendimiento, accesibilidad, buenas prácticas y SEO. Eso convierte un hábito que tenía que acordarme de hacer en una barrera que no puedo saltear sin notarlo.
La primera vez que atrapó algo fue casi inmediata: una imagen de hero que había agregado sin dimensiones, que Lighthouse señaló como riesgo de layout shift antes de que yo hubiera siquiera abierto el despliegue de previsualización. Manualmente, probablemente no habría corrido una auditoría de Lighthouse en ese PR específico —era “solo agregar una imagen”, el tipo de cambio que no se siente como que amerite una revisión manual de rendimiento.
Lo que cambió en cómo escribo cambios
Saber que la barrera existe cambió un poco la forma en que escribo CSS y markup, para bien. Pienso si una imagen tiene dimensiones explícitas antes de publicarla, no después de que Lighthouse me diga que no las tiene, porque sé que la verificación va a llegar de todos modos. La barrera no está ahí realmente para atrapar errores —está ahí para que no tenga que mantener “¿me acordé de verificar el rendimiento?” en la cabeza en cada cambio.