Cómo leer un reporte de Lighthouse sin perder la cabeza

Qué es Lighthouse exactamente#

Lighthouse es la herramienta oficial de Google para auditar la calidad técnica de un sitio web. Es open source, viene integrada en Chrome DevTools y se puede correr desde línea de comandos o vía API (PageSpeed Insights usa Lighthouse por debajo).

Es la base de casi todas las auditorías técnicas modernas, pero su interfaz puede ser abrumadora la primera vez. Esta guía es para que sepas qué leer y en qué orden.

Las 4 categorías y qué peso tienen#

Anatomía del reporte#

Un reporte Lighthouse tiene estas secciones, en este orden:

1. Scores (donut charts). Los 4 números 0-100. Foto general.
2. Metrics. Las 6 métricas técnicas (FCP, LCP, TBT, CLS, SI, TTI).
3. Opportunities. Sugerencias de optimización con ahorros estimados.
4. Diagnostics. Información técnica detallada de problemas detectados.
5. Passed audits. Lo que ya tienes bien (skip esta en primera lectura).

Performance: qué leer primero#

El orden de lectura óptimo dentro de Performance:

1. Mira el score general.> 90: estás bien. 50-90: hay trabajo. < 50: emergencia.
2. Identifica el LCP element.“Largest Contentful Paint element” en Diagnostics. Sabiendo qué elemento es, sabes qué optimizar.
3. Revisa “Total Blocking Time” (TBT).Si está alto (> 300ms), tu JS está bloqueando el render. Atacar code splitting.
4. Mira “Eliminate render-blocking resources”. Suele dar el mayor ahorro de tiempo. Diferir CSS no crítico y JS.
5. Revisa “Properly size images”. Si tu mobile sirve imágenes desktop, pierdes 1-3 segundos fáciles.

Opportunities vs Diagnostics#

Confusión típica: la gente empieza por Opportunities porque está arriba. Pero Diagnostics suele tener insights más valiosos.

• Opportunities: cosas que puedes “optimizar” con un ahorro estimado en segundos. Ejemplo: “Properly size images: ahorra 2.3s”.
• Diagnostics: información sobre problemas detectados. Ejemplo: “Avoid an excessive DOM size: 2800 elementos”.

Diagnostics tiene contexto. Opportunities tiene métricas. Lee Diagnostics primero para entender qué está pasando, después Opportunities para planificar el ataque.

Qué puedes ignorar#

• Sugerencias sobre librerías deprecated que vienen de scripts third-party (analytics, chat). No las controlas.
• Warnings sobre cookies sin SameSite en third-party. Mismo caso.
• Console errors no críticos de ads o scripts embebidos.
• “Reduce unused JavaScript” en menos de 50KB. Es retorno decreciente.
• Accessibility audits sobre contraste de marca si tu marca usa colores intencionales (revisar con un especialista UX, no ignorar a ciegas).

Errores de interpretación más comunes#

1. Creer que score = ranking en Google. No. Lighthouse es lab. Google usa CrUX (datos reales). Pueden no coincidir.
2. Obsesionarse con llegar a 100. Pasar de 90 a 100 cuesta el mismo tiempo que pasar de 50 a 90. No vale la pena salvo industrias hipercompetitivas.
3. Ignorar mobile y solo optimizar desktop. Google indexa mobile-first. Mobile pesa más.
4. Atacar todo a la vez. Prioriza por impacto en segundos, no por peso visual del issue.
5. Correr Lighthouse una sola vez y sacar conclusiones. La variabilidad puede ser ±10 puntos. Correr 3-5 veces y promediar.