Cómo leer un informe de Lighthouse sin entrar en pánico

La primera regla: tu puntuación no es tu sitio

Abres un informe de Lighthouse por primera vez y te encuentras con un muro de números, recuadros codificados por colores y advertencias sobre cosas de las que nunca has oído hablar. La reacción natural es el pánico. La puntuación está en rojo. Hay diecisiete auditorías fallidas. ¿Seguro que el sitio está roto?

Probablemente no lo esté. Lighthouse es una herramienta de diagnóstico, no una libreta de calificaciones. La puntuación es una referencia sintética ejecutada en condiciones de laboratorio, a menudo con una conexión limitada, simulando un teléfono de gama media de 2017. Te dice cómo rinde tu sitio en ese escenario concreto, no cómo lo experimentan los usuarios reales en condiciones reales.

Esto importa porque la mayoría de los equipos se obsesionan con la puntuación y pierden el contexto. Una puntuación de 65 puede estar bien para una aplicación web compleja con datos en tiempo real. Una puntuación de 95 aún puede ofrecer una mala experiencia si se optimizan las cosas equivocadas. La puntuación es un punto de partida para investigar, no una métrica de éxito.

Qué leer primero: Core Web Vitals

Omite la puntuación general de rendimiento. Baja hasta la sección Métricas y mira tres números: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) e Interaction to Next Paint (INP). Estos son los Core Web Vitals, y son las únicas métricas de rendimiento que Google usa como señal de posicionamiento.

• LCP mide cuánto tarda en renderizarse el elemento visible más grande. Objetivo: menos de 2,5 segundos. Si superas los 4 segundos, los usuarios esperan demasiado para ver contenido significativo.
• CLS mide la estabilidad visual: cuánto salta la página mientras carga. Objetivo: menos de 0,1. Si superas 0,25, los usuarios hacen clic accidentalmente en lo que no querían porque los botones se movieron.
• INP mide la capacidad de respuesta: con qué rapidez reacciona la página a clics, toques y pulsaciones de teclas. Objetivo: menos de 200 ms. Si superas 500 ms, el sitio se siente lento.

Estas tres métricas se correlacionan con la frustración real de los usuarios. Corrígelas antes de preocuparte por cualquier otra cosa.

Oportunidades frente a diagnósticos: conoce la diferencia

Lighthouse divide sus hallazgos en dos categorías: Oportunidades y Diagnósticos. Las oportunidades se ordenan por ahorro de tiempo estimado. Los diagnósticos son contexto adicional: cosas que podrían ser problemas, o podrían no serlo.

Empieza por las Oportunidades. Si Lighthouse dice que "Eliminar recursos que bloquean el renderizado" podría ahorrar 1,2 segundos, eso es una mejora concreta. Si dice que "Reducir JavaScript no utilizado" podría ahorrar 0,1 segundos, probablemente no merezca la refactorización.

Los diagnósticos son más delicados. "Evitar un tamaño excesivo del DOM" suena mal, pero si tu CLS está bien y tu INP es rápido, un DOM grande quizá no esté perjudicando a nadie. Los diagnósticos son pistas, no mandatos. Investiga los que encajen con tus métricas reales.

Las auditorías que normalmente puedes ignorar

Algunas advertencias de Lighthouse son vestigiales o demasiado agresivas. Estas son las que causan más pánico innecesario:

• "No usa listeners pasivos para mejorar el rendimiento del desplazamiento" — Es una microoptimización que rara vez cambia mucho las cosas. A menos que tengas indicios de desplazamiento entrecortado, sáltala.
• "Los elementos de imagen no tienen ancho y alto explícitos" — Esto importa para CLS, pero solo si las imágenes están causando desplazamientos de diseño. Si tu CLS ya es bueno, no refactorices solo por satisfacer la auditoría.
• "Servir imágenes en formatos de nueva generación" — Sí, WebP y AVIF son más pequeños. Pero si tus imágenes ya están optimizadas y tu LCP es rápido, esto es algo deseable, no una crisis.
• "Evitar cargas de red enormes" — Lighthouse marca cualquier cosa por encima de 1,6 MB. Pero una página de 2 MB que carga rápido es mejor que una página de 500 KB que bloquea el renderizado. Concéntrate en cómo se entregan los bytes, no solo en el total.

Qué hacer cuando todo está en rojo

Si tu puntuación de Lighthouse está por debajo de 50 y la mayoría de las auditorías fallan, probablemente te enfrentes a una de estas tres causas raíz:

1. Fuentes sin optimizar. Las fuentes web siguen siendo la mejora de rendimiento más sencilla en la mayoría de los sitios. Comprueba si estás cargando seis pesos de fuente cuando solo usas dos, o si estás enviando archivos WOFF en lugar de WOFF2.
2. CSS y JavaScript que bloquean el renderizado. Si tu First Contentful Paint (FCP) supera los 3 segundos, algo está impidiendo que el navegador pinte. Busca archivos CSS grandes o scripts síncronos en el <head>.
3. Imágenes sobredimensionadas. Si tu elemento LCP es una imagen y pesa 4 MB, ese es tu problema. Comprímela, aplica lazy loading a las imágenes por debajo del primer pliegue y usa sintaxis de imágenes responsivas.

Corrige una de estas cosas y vuelve a ejecutar Lighthouse. A menudo verás un salto de 20 a 30 puntos. Luego aborda la siguiente.

Datos de laboratorio frente a datos de campo: la comprobación de realidad

Lighthouse se ejecuta en un laboratorio. Simula una conexión lenta y un dispositivo lento, pero no puede simular el comportamiento real de los usuarios: cómo se desplazan, en qué hacen clic, si están usando un Wi-Fi inestable.

Para una comprobación de realidad, compara tus resultados de Lighthouse con datos de campo del Chrome User Experience Report (CrUX). CrUX muestra cómo experimentan tu sitio los usuarios reales de Chrome durante los últimos 28 días. Si Lighthouse dice que tu LCP es de 4 segundos pero CrUX muestra 2 segundos, confía en CrUX. Si ambos son malos, tienes un problema real.

Puedes encontrar datos de CrUX en PageSpeed Insights (la versión web de Lighthouse) o en Google Search Console, en "Core Web Vitals". Si hay una discrepancia, investiga por qué. Quizá tus usuarios reales estén en redes más rápidas. Quizá Lighthouse esté probando una compilación de desarrollo sin optimizar.

Cuándo volver a ejecutar Lighthouse

Lighthouse es ruidoso. Ejecútalo tres veces seguidas y obtendrás tres puntuaciones distintas, incluso en la misma página. Esto ocurre porque el rendimiento es variable: los procesos en segundo plano, la fluctuación de la red y las heurísticas del navegador afectan al resultado.

Para obtener una línea base estable, ejecuta Lighthouse en modo de incógnito con todas las extensiones desactivadas, o usa la CLI con la bandera --preset=desktop para obtener resultados más consistentes. Ejecútalo tres veces y promedia las puntuaciones. Si ves oscilaciones bruscas (más de 10 puntos), algo más va mal: quizá el servidor sea lento, o quizá la página cargue recursos distintos cada vez.

Vuelve a ejecutar Lighthouse después de cada cambio importante. ¿Implementaste una nueva estrategia de fuentes? Comprueba LCP. ¿Aplicaste lazy loading a imágenes? Comprueba CLS. ¿Añadiste un script de terceros? Comprueba INP. El rendimiento no es una corrección puntual; es un presupuesto que defiendes.

Las herramientas que te ayudan a actuar sobre los hallazgos de Lighthouse

Lighthouse te dice qué es lento. No siempre te dice cómo corregirlo. Para eso necesitas herramientas adicionales:

• WebPageTest te da una vista de tira de fotogramas de cómo carga la página, fotograma a fotograma. Esencial para diagnosticar problemas de LCP y CLS.
• Panel Performance de Chrome DevTools te muestra exactamente qué JavaScript está bloqueando el hilo principal. Úsalo para encontrar el origen de una mala puntuación de INP.
• Herramientas de compresión de imágenes te permiten optimizar imágenes directamente en el navegador, lo que es más rápido y más privado que subirlas a un servicio de terceros. El procesamiento de imágenes del lado del cliente es una ventaja para la privacidad porque tus imágenes nunca salen de tu máquina.

Lighthouse es el punto de partida. Estas herramientas te ayudan a terminar el trabajo.

Puntos clave

• Tu puntuación de Lighthouse es una referencia de laboratorio, no una medida de la experiencia de usuario en el mundo real. Compárala con datos de campo de CrUX antes de entrar en pánico.
• Concéntrate primero en Core Web Vitals (LCP, CLS, INP). Estas son las métricas que se correlacionan con la frustración de los usuarios y el impacto en SEO.
• Prioriza las Oportunidades por ahorro de tiempo estimado. Ignora los Diagnósticos que no encajen con tus problemas reales de rendimiento.
• Algunas auditorías, como los listeners pasivos o los formatos de imagen de nueva generación, son microoptimizaciones. Corrige primero lo importante.
• Ejecuta Lighthouse tres veces y promedia los resultados. El rendimiento es variable, y una sola ejecución puede ser engañosa.

FAQ

P: ¿Por qué cambia mi puntuación de Lighthouse cada vez que lo ejecuto?
R: Lighthouse mide el rendimiento en condiciones variables: la velocidad de red, la carga de CPU y las heurísticas del navegador afectan al resultado. Ejecútalo tres veces en modo de incógnito y promedia las puntuaciones para obtener una línea base más estable.

P: ¿Debería optimizar primero para móvil o para escritorio?
R: Móvil. Lighthouse usa por defecto una simulación móvil porque la mayor parte del tráfico web es móvil y los dispositivos móviles son más lentos. Si tu puntuación móvil es buena, tu puntuación de escritorio normalmente estará bien.

P: Mi puntuación de Lighthouse es 95, pero mi sitio sigue pareciendo lento. ¿Qué pasa?
R: Lighthouse mide la carga de la página, no la interactividad después de la carga. Comprueba tu puntuación de INP y usa el panel Performance de Chrome DevTools para perfilar qué ocurre cuando los usuarios hacen clic o se desplazan. Podrías tener un problema de JavaScript que Lighthouse no detecta.

P: ¿Necesito una puntuación perfecta de 100?
R: No. Una puntuación de 90+ es excelente. Perseguir el 100 a menudo significa optimizar cosas que no importan a los usuarios. Concéntrate en métricas reales —LCP, CLS, INP— e ignora la puntuación.

P: ¿Puedo confiar en Lighthouse si uso muchos scripts de terceros?
R: Lighthouse marcará los scripts de terceros como un problema, pero no siempre puede distinguir entre los necesarios y los innecesarios. Usa las auditorías "Evitar cargas de red enormes" y "Reducir el tiempo de ejecución de JavaScript" para identificar a los peores responsables y luego decide si merece la pena conservarlos.

Fuentes

• "Lighthouse performance scoring" — Google Developers
• "Core Web Vitals" — web.dev
• "Chrome User Experience Report" — Google Developers
• "WebPageTest Documentation" — WebPageTest.org