Cómo medir el rendimiento web con Lighthouse y Window Performance

Si has buscado "cómo medir la velocidad de una web", seguro ya viste dos extremos. Por un lado, gente obsesionada con sacar 100/100 en Lighthouse. Por otro, equipos que leen cuatro números de window.performance y dan por hecho que ya entienden lo que siente el usuario. Ninguno de los dos enfoques basta por sí solo.

Lighthouse te da una foto de laboratorio. Sirve para comparar versiones, detectar JavaScript sobrante, imágenes mal optimizadas o cadenas de bloqueo antes de publicar. El Window Performance API te baja a tierra: te deja revisar timings reales del navegador, recursos lentos y puntos concretos del flujo donde la experiencia se rompe.

Cuando unes ambos, dejas de "optimizar por intuición". Y eso importa por dos motivos: mejora la experiencia de carga y también protege tus señales SEO. Un LCP lento, una interfaz que tarda en responder o un CLS molesto no solo frustran. También bajan conversiones.

Por qué conviene mirar la misma página desde dos ángulos

Lighthouse es perfecto para auditar rápido una URL, pero no reproduce todos los dispositivos, redes, extensiones, scripts de terceros ni hábitos de navegación de tus visitantes. Si tu equipo solo prueba en un portátil potente conectado al Wi-Fi de la oficina, está viendo una versión demasiado amable de la realidad.

window.performance, en cambio, te permite medir lo que ocurre en el navegador paso a paso. Ahí aparecen preguntas útiles de verdad:

• ¿El cuello de botella está en el HTML inicial o en un script de terceros?
• ¿El hero tarda en pintar por la imagen, por la fuente o por el render bloqueado?
• ¿La página "parece cargada" pero el hilo principal sigue ocupado?

Ese contraste entre prueba de laboratorio y señal granular suele ser donde están las respuestas.

Cómo usar Lighthouse sin quedarte atrapado en la puntuación

La forma más directa sigue siendo Chrome DevTools. Abre la página, entra en F12, busca la pestaña Lighthouse, elige Mobile o Desktop y ejecuta el análisis. También puedes tirar del CLI si quieres comparar builds o meter la revisión en CI.

Antes de abrir DevTools, no es mala idea pasar la URL por el SEO Analyzer para detectar de un vistazo problemas de rendimiento, peso y experiencia móvil. No sustituye a Lighthouse, pero te ayuda a llegar con una hipótesis más clara.

Lo importante: no uses Lighthouse como un examen de autoestima. Úsalo como un mapa. El score general sirve para priorizar, pero los apartados que más suelen mover negocio están debajo:

• Oportunidades para reducir JS no utilizado.
• Recursos que bloquean el render.
• Imágenes demasiado pesadas para móvil.
• Scripts de terceros que disparan TBT.

Las métricas que sí conviene leer primero

No hace falta memorizar todo el informe. Para SEO, UX y conversión, yo empezaría por estas:

1. LCP: te dice cuándo aparece el contenido principal. Si el hero o el bloque más visible tarda demasiado, el usuario siente que la página no arranca.
2. INP: refleja si la página responde con soltura cuando alguien toca, hace clic o interactúa. Aquí se nota mucho el exceso de JavaScript.
3. CLS: mide si el layout se mueve cuando no debería. Es la típica sensación de "iba a tocar un botón y el contenido saltó".
4. FCP: sigue siendo útil para saber cuándo desaparece la pantalla en blanco.
5. TBT: no es una métrica de campo como INP, pero en laboratorio sigue siendo una señal muy buena para detectar bloqueos del hilo principal.

En muchas guías antiguas todavía verás TTI o FID como protagonistas. Conviene conocerlos por contexto histórico, sí, pero si tienes que priorizar hoy, LCP, INP, CLS y TBT te van a dar más claridad.

Qué te aporta Window Performance API que Lighthouse no te cuenta tan fino

Aquí es donde dejas de mirar el problema desde arriba y te metes en el detalle.

Con performance.getEntriesByType('navigation') puedes revisar tiempos de navegación. Con resource, localizar archivos lentos. Con paint, entender cuándo aparece por primera vez algo útil en pantalla. Y si quieres medir eventos modernos como LCP, CLS o long tasks, lo razonable es usar PerformanceObserver.

1const nav = performance.getEntriesByType('navigation')[0];
2const resources = performance.getEntriesByType('resource');
3
4console.log('DOMContentLoaded:', nav.domContentLoadedEventEnd);
5console.log('Load event:', nav.loadEventEnd);
6console.log(
7  'Top 5 slowest resources:',
8  resources.sort((a, b) => b.duration - a.duration).slice(0, 5)
9);

1const observer = new PerformanceObserver((list) => {
2  for (const entry of list.getEntries()) {
3    console.log(entry.entryType, entry.startTime, entry.duration || entry.value);
4  }
5});
6
7observer.observe({ type: 'largest-contentful-paint', buffered: true });
8observer.observe({ type: 'layout-shift', buffered: true });
9observer.observe({ type: 'longtask', buffered: true });

Si quieres una lectura fiable de INP en producción, lo más sensato es conectarlo a tu capa de RUM o a una implementación tipo web-vitals, en lugar de improvisarlo a ciegas.

La ventaja real aparece cuando comparas distintos perfiles de red. Ahí descubres algo bastante incómodo: la web que "va bien" en Wi-Fi a veces se cae en cuanto la pasas por Fast 3G o un móvil medio.

Un flujo de trabajo que sí sirve en equipos reales

Lo que mejor funciona no es elegir una herramienta y casarte con ella. Es secuenciar bien el trabajo:

1. Usa Lighthouse para encontrar las páginas problemáticas y priorizar.
2. Baja al detalle con window.performance para localizar recursos lentos, saltos de layout y tareas largas.
3. Contrasta después con datos de campo o Search Console para ver si el problema también afecta a usuarios reales.
4. Corrige y vuelve a medir en el mismo dispositivo, la misma red simulada y la misma plantilla.

Si el informe apunta a archivos pesados, puedes recortar antes de desplegar con el JavaScript Compressor, el CSS Compressor o el HTML Compressor. No arreglan una arquitectura pobre por sí solos, pero ayudan a bajar ruido cuando ya sabes dónde está el exceso.

Cerrar la brecha entre "se siente lenta" y "sé por qué va lenta"

Eso es, al final, lo que buscas cuando haces pruebas de rendimiento web en serio. No una nota bonita. No una captura para Slack. Lo que necesitas es una explicación defendible de por qué la página tarda, qué parte del stack está fallando y qué arreglo tiene más impacto.

Lighthouse te da la primera alarma. Window Performance te enseña la escena completa. Juntos te permiten decidir mejor y corregir más rápido. Si quieres empezar por una revisión amplia antes de meterte con el navegador, lanza la URL en SeoSpeedup y usa esa auditoría como punto de partida.