Google Lighthouse: guía práctica para desarrolladores
Qué es Lighthouse, cómo ejecutarlo en Chrome DevTools, CLI o CI, en qué fijarte en el informe, y por qué un 100 en la puntuación no cuenta toda la historia del rendimiento real.
Lighthouse es una herramienta de código abierto de Google que audita páginas web y devuelve un informe con puntuaciones y recomendaciones. Cubre rendimiento, accesibilidad, buenas prácticas, SEO y, cuando aplica, PWA (aplicación web progresiva).
Este artículo explica cómo usarla en el día a día, qué mirar en el informe y algunos trucos que marcan la diferencia — sin confundir el análisis de laboratorio con la experiencia real de tus usuarios.
Por qué deberías usar Lighthouse
- Feedback rápido: en segundos tienes una lista priorizada de problemas y sugerencias, sin montar un ambiente de pruebas complejo.
- Cubre varias dimensiones: no se reduce a “la página va lenta”; también revisa contraste, etiquetas accesibles (formularios, botones), HTTPS, metaetiquetas y recursos que bloquean el renderizado.
- Encaja en el flujo de desarrollo: puedes usarla desde Chrome DevTools, la línea de comandos o integrarla en CI para detectar regresiones antes de que lleguen a producción.
- Complementa otras herramientas: PageSpeed Insights combina resultados de laboratorio (Lighthouse) con métricas de campo cuando existen—muchas veces procedentes de CrUX. Cruzar ambas suele ser mejor que fiarse solo de una (más abajo, definiciones).
Datos de laboratorio, de campo, CrUX y RUM
Se usan como sinónimos y no lo son; aquí va un mapa breve.
- Datos de laboratorio (lab): lo que mide Lighthouse — una corrida sintética con dispositivo y red simulados en una sesión controlada. Sirve para depurar y CI porque es repetible.
- Datos de campo (field / experiencia real): mediciones de cargas reales — muchos dispositivos, redes, estados de caché y regiones, agregadas en el tiempo (p. ej. percentiles de LCP).
- CrUX (Chrome User Experience Report / informe de experiencia de Chrome): un conjunto público de datos de campo que Google elabora a partir de usuarios de Chrome que optan por compartir estadísticas de uso. PageSpeed Insights puede mostrar CrUX para una URL u origen cuando hay volumen suficiente; no despliegas código de medición en tu web, pero páginas con poco tráfico a veces no tienen sección de campo.
- RUM (Real User Monitoring / monitorización de usuarios reales): tu instrumentación en producción — envías Web Vitals (u otras métricas) desde el navegador a tu analítica o APM para segmentar por release, ruta, mercado o dispositivo. Complementa a CrUX cuando necesitas detalle que el conjunto público no da (poco tráfico, flujos autenticados, atribución propia).
Cosas a tener en cuenta
Un error que me ha pasado más de una vez: pasar Lighthouse sobre localhost en modo desarrollo (npm run dev) como si fuera lo que verá el usuario en producción, sin haber generado un build de producción. Los resultados pueden ser alarmantemente malos porque en dev los bundles suelen ir sin minificar, con más JavaScript (recarga en caliente, runtime de desarrollo), mapas de fuente y comprobaciones que no existen en el artefacto que despliegas. Para acercarte a números creíbles, ejecuta npm run build y luego npm run start (o audita la URL ya desplegada) y mide sobre eso.
Qué audita Lighthouse
| Categoría | Qué revisa |
|---|---|
| Rendimiento | Tiempos de carga, interactividad, estabilidad visual, peso de recursos |
| Accesibilidad | Subconjunto automático de problemas — muchas cosas aún requieren revisión manual |
| Buenas prácticas | Seguridad básica, APIs obsoletas, errores en consola |
| SEO | Metadatos, enlaces, indexabilidad en móvil |
| PWA (aplicación web progresiva) | Service worker, manifest, soporte offline |
Las puntuaciones van de 0 a 100. En general: menos de 50 es rojo, 50–89 es ámbar, 90 o más es verde. Úsalas como orientación, no como certificado absoluto.
Cómo ejecutar Lighthouse
Chrome DevTools (ideal para iterar en local)
- Abre la página en Chrome.
- Abre DevTools → pestaña Lighthouse.
- Elige categorías y dispositivo (móvil es el estándar).
- Haz clic en Analizar.
Es la opción más práctica para páginas locales o con autenticación, ya que corre en tu sesión de Chrome.
CLI (automatización y CI)
npm install -g lighthouse
lighthouse https://tu-sitio.com --output html --output-path informe.html
Para auditar solo categorías específicas:
lighthouse https://tu-sitio.com --only-categories=performance,accessibility
Exporta el resultado en JSON para guardarlo o abrirlo en el visor de informes.
PageSpeed Insights
Introduces una URL pública y obtienes Lighthouse (laboratorio) más, si Google dispone de muestras suficientes, métricas de campo de CrUX para esa URL u origen — sin instrumentar tu sitio. Qué es CrUX y en qué se diferencia del RUM que tú controlas está en Datos de laboratorio, de campo, CrUX y RUM más arriba.
Qué mirar en el informe
Métricas principales
- FCP (First Contentful Paint): cuándo aparece el primer texto o imagen.
- LCP (Largest Contentful Paint): cuándo carga el elemento principal visible.
- TBT (Total Blocking Time): cuánto tiempo el hilo principal estuvo bloqueado por JavaScript.
- CLS (Cumulative Layout Shift): cuánto se mueven los elementos durante la carga.
Oportunidades vs diagnósticos
- Oportunidades: cambios concretos con estimado de ahorro en tiempo de carga. Prioriza los de mayor impacto.
- Diagnósticos: contexto adicional sobre el DOM, scripts de terceros, fuentes, etc. Útil para entender el problema de raíz.
Algunas auditorías que vale la pena revisar siempre:
- JavaScript no usado
- Caché en recursos estáticos
- Texto visible mientras cargan las fuentes (
font-display) preconnecta orígenes críticos- Redireccionamientos innecesarios
- GIFs animados grandes: sustituirlos por vídeo (p. ej. MP4/WebM con
<video>o embed corto); un GIF guarda cada fotograma como imagen y suele pesar órdenes de magnitud más que el mismo movimiento en vídeo comprimido
Accesibilidad: no confíes solo en el 100
Lighthouse cubre solo una parte de los problemas de accesibilidad — los que se pueden detectar automáticamente. El resto requiere pruebas manuales: navegación por teclado, orden de foco, anuncios de estado, etc. Un 100 en accesibilidad no significa que tu sitio sea accesible para todos.
Trucos útiles
- Audita en modo incógnito: evita que extensiones de Chrome afecten los resultados.
- Emulación consistente: usa siempre el mismo dispositivo y resolución para poder comparar auditorías entre sí.
- Guarda el JSON: puedes abrir informes anteriores en el visor oficial y comparar evolución.
- Cuidado con
preload: agregarel=preloadsolo después de medir — precargar mal puede retrasar el primer render. - Revisa terceros: filtra por "third party" en la pestaña de red y cruza con el tiempo de evaluación de scripts. Muchas regresiones vienen de analytics, widgets o publicidad.
- Intégralo en CI: define umbrales mínimos en tu pipeline para detectar regresiones antes de que lleguen a producción. Lighthouse CI facilita esta integración.
La advertencia honesta: un 100 no es la web perfecta
Lighthouse trabaja con datos simulados en condiciones de laboratorio. Eso es útil para detectar problemas técnicos, pero no refleja lo que viven tus usuarios en dispositivos y redes reales.
Lo que Lighthouse te dice → problemas técnicos concretos y regresiones.
Lo que los usuarios reales experimentan → datos de campo. Agregados públicos como CrUX (cuando tu URL u origen tiene tráfico suficiente en el conjunto de Chrome) más RUM si tú instrumentas la web y te quedas con el desglose.
La combinación sigue siendo Lighthouse en desarrollo, PageSpeed (CrUX cuando aparezca) y, al crecer, RUM u otra herramienta de campo para preguntas propias de producción.
Conclusión
Usa Lighthouse temprano y con frecuencia. Es barata de ejecutar, enseña a tu equipo un vocabulario común — LCP, CLS, TBT — y alinea mejoras de rendimiento, accesibilidad y SEO. Combínala con pruebas manuales de accesibilidad y métricas reales cuando el tráfico lo justifique.