Lighthouse: cómo medir la velocidad de un sitio y encontrar mejoras
Lighthouse es una herramienta de auditoría automatizada que identifica problemas y posibles mejoras en el rendimiento de una página web, accesibilidad, mejores prácticas y optimización para motores de búsqueda (SEO). Analiza la carga de una página en Chrome DevTools, rastrea una métrica lenta hasta las solicitudes, archivos o tareas de ejecución involucradas, cambia una cosa y mide de nuevo bajo las mismas condiciones. Una puntuación única no representa la experiencia de todos los visitantes ni determina la clasificación de búsqueda de una página.
Lighthouse y PageSpeed Insights: ¿cuál es la diferencia?
La descripción oficial de Lighthouse explica cómo ejecutar auditorías mediante Chrome DevTools, la línea de comandos o un módulo de Node. Los principiantes pueden empezar con el panel incluido en Chrome para escritorio, sin instalar una extensión. Esta opción también resulta útil para páginas con sesión iniciada o páginas de desarrollo local.
La documentación de PageSpeed Insights distingue los datos de laboratorio de los datos de campo. Los primeros son un diagnóstico de Lighthouse generado en condiciones específicas. Los datos de experiencia de usuarios reales proceden de Chrome User Experience Report (CrUX) y abarcan los últimos 28 días de recopilación. Si una página tiene muy pocas muestras, el servicio puede mostrar datos del origen (mismo esquema de URL, host y puerto) o no disponer de datos de usuarios reales. Tener un resultado de laboratorio no implica que existan estadísticas de visitantes reales para esa página concreta.
Para una revisión rápida de una URL pública, introdúcela en PageSpeed Insights, analízala, y selecciona los resultados de móvil y escritorio por separado. Para páginas visibles solo después de iniciar sesión, o URLs locales que no puedan ser alcanzadas externamente, utiliza DevTools local en lugar del servicio externo. No envíes URLs privadas ni tokens de acceso a un servicio de análisis externo.
Las mediciones de un informe describen su URL objetivo y las condiciones de ejecución. Una demostración utilizando una URL de ejemplo pública no mide el sitio web que publica la guía ni tu propio sitio web. Mantén la sección de experiencia del usuario real separada de la sección de diagnóstico de Lighthouse al leer un informe.
Elige primero la página y las condiciones de medición
- Objetivo: especificar la URL a probar, incluyendo artículos representativos, listados o páginas de productos en lugar de solo la página de inicio. No combines diferentes plantillas como si fueran resultados de antes y después para la misma página.
- Estado: registra si esta es una visita inicial o repetida, el estado de inicio de sesión y cómo se manejan los banners de consentimiento. Para una página pública que no requiere inicio de sesión, un perfil separado o una ventana de incógnito puede ayudar a reducir los efectos de las extensiones.
- Entorno: registra las versiones de Chrome y Lighthouse, la selección de móvil o escritorio, el método de limitación de red y CPU, y el tiempo de medición. Evita ejecutar descargas grandes u otros trabajos pesados al mismo tiempo.
- Almacenamiento: Borrar el almacenamiento elimina el almacenamiento del sitio para aproximar una visita inicial. Puede afectar el estado de inicio de sesión y de consentimiento, así que no lo habilites a la ligera en una sesión que contenga trabajo importante. Al auditar una página con sesión iniciada, elige configuraciones que preserven el estado requerido y úsalas de manera consistente en comparaciones posteriores.
Auditar mientras se está conectado como administrador puede cargar scripts, barras de herramientas y políticas de caché diferentes a los que usa un visitante anónimo. Mide la página pública por separado cuando la pregunta concierna a lectores comunes. Si el objetivo es una función para usuarios conectados, registra explícitamente ese estado en su lugar.
Analiza la carga de una página en Chrome DevTools
- Abre la página en Chrome de escritorio. Verifica que la dirección pública sea correcta, por ejemplo, y que la página no se haya redirigido a una pantalla de error.
- Abre DevTools, por ejemplo con F12 o Ctrl+Shift+I en Windows. Si la pestaña Lighthouse está oculta, encuéntrala a través del menú de desbordamiento de pestañas o Más herramientas en el menú de DevTools. Los nombres de los menús pueden diferir según el idioma y la versión del navegador.
- Para una auditoría de carga inicial de la página, selecciona Navegación bajo Modo. Elige Móvil o Escritorio bajo Dispositivo. El modo Móvil es una prueba de laboratorio con restricciones seleccionadas, en lugar de una reproducción del rendimiento de todos los teléfonos reales.
- Selecciona Rendimiento en Categorías, agregando Accesibilidad, Mejores Prácticas o SEO cuando sea necesario. Verifica la configuración de borrado de almacenamiento y limitación y mantén sus valores iguales durante las comparaciones.
- Selecciona Analizar carga de página, o el botón de inicio equivalente en su versión. La página se recarga, así que guarda formularios no terminados u otro trabajo no guardado previamente. Evita interactuar con la página durante el análisis y espera el informe.
- Verifica la URL solicitada, la URL final, la configuración y las versiones. Guarde el informe como HTML o JSON, seleccionando el formato necesario si el menú de exportación ofrece esa opción. Los informes pueden contener direcciones internas o información de diagnóstico, así que considera su contenido antes de compartir.
Elige un modo diferente para escenarios distintos a una auditoría de carga básica. La documentación de flujo de usuario Lighthouse distingue entre Navegación para una navegación, Timespan para un período que puede incluir interacciones, y Snapshot para el estado actual de la página. No compares los resultados de Timespan o Snapshot como si fueran la puntuación de rendimiento completa de Navegación. Considera la Snapshot cuando la pregunta se refiere a un estado específico, como la accesibilidad mientras un menú está abierto.
Lee las métricas y las pistas de diagnóstico antes de la puntuación
La explicación del cálculo de la puntuación de rendimiento describe un promedio ponderado de valores transformados de las métricas. Reducir el número de advertencias de diagnóstico no aumenta la puntuación en una cantidad equivalente. Las puntuaciones de 90 a 100 se muestran como buenas, de 50 a 89 como necesitadas de mejora y de 0 a 49 como bajas. Estos intervalos interpretan una ejecución; no definen todos los retrasos aceptables para los usuarios reales.
| Métrica | Lo que mide | Pistas para examinar primero |
|---|---|---|
| FCP: First Contentful Paint (Primer renderizado de contenido) | Tiempo hasta que se muestra el primer contenido. | Respuesta inicial del servidor y estilos o scripts que bloquean el renderizado. |
| LCP: Largest Contentful Paint | Cuando se muestra el contenido principal grande en la ventana. | El elemento identificado en el informe, y retrasos en iniciar, transferir o mostrar la solicitud de su imagen. |
| TBT: Total Blocking Time (tiempo total de bloqueo) | La suma de las partes bloqueantes de las tareas largas del hilo principal durante la carga. | Ejecución larga de JavaScript, scripts de inicio innecesarios y código de terceros. |
| CLS: Cumulative Layout Shift (cambios acumulados de diseño) | La cantidad de movimiento inesperado del diseño. | Imágenes o anuncios sin espacio reservado, y elementos insertados tarde. |
| Speed Index (índice de velocidad) | Qué tan rápido se llena el contenido visible. | Periodos de retraso en la visualización inicial, considerados junto con la grabación visual. |
La documentación de TBT define una tarea larga como aquella que excede los 50 milisegundos, contando el exceso sobre 50 milisegundos como tiempo de bloqueo. TBT no es la misma métrica que Interaction to Next Paint (INP), que se refiere a la capacidad de respuesta a las interacciones del usuario. Verifica las métricas de Core Web Vitals de usuarios reales—LCP, INP y CLS—por separado en datos de campo.
Expande los Insights y diagnósticos del informe para encontrar los elementos y recursos afectados. Si el elemento LCP es una imagen en la ventana inicial, comienza con su tamaño de transferencia y el tiempo de solicitud. Para grandes desplazamientos de diseño, verifica si se ha reservado espacio para imágenes y anuncios. Simplemente cargar de manera diferida una imagen importante de la primera pantalla o retrasar todos los scripts de la misma manera puede dañar la visualización o funcionalidad necesarias, así que primero identifica la causa y el uso.
Para una investigación más profunda, continúa con grabaciones y Perspectivas en el panel de Rendimiento, como se explica en la guía de Lighthouse y del panel de Rendimiento de Chrome. Altas puntuaciones de Accesibilidad o SEO no certifican el cumplimiento completo de accesibilidad ni altos rankings de búsqueda. El uso del teclado y la calidad real del contenido, entre otros aspectos fuera de las comprobaciones automáticas, todavía deben revisarse.
Cambia una cosa y mide de nuevo bajo las mismas condiciones
- Elige un problema con un impacto sustancial en el usuario y una causa específica. Para una imagen sobredimensionada en la ventana de visualización inicial, por ejemplo, primero experimenta con una imagen apropiada para su tamaño mostrado.
- Conserva los archivos originales, la configuración y el informe. Realiza los cambios localmente o en un entorno de prueba, y verifica que las cachés sirvan los nuevos archivos después del despliegue. No ocultes funcionalidades necesarias ni muestres una página diferente solo durante la auditoría en busca de una puntuación más alta.
- Repite las mediciones con la misma URL, estado de inicio de sesión, modo de dispositivo y configuración de limitación de red y CPU. Compara las métricas en bruto y el rango y la mediana de las ejecuciones repetidas en lugar de un solo mejor resultado. Si eliges cinco ejecuciones por condición, por ejemplo, usa ese mismo número tanto antes como después del cambio.
- Verifica que la métrica objetivo mejore y que el diseño, los botones, los formularios y las interacciones con el teclado sigan funcionando. Si el cambio no ayuda o rompe la funcionalidad, restaura los archivos y la configuración guardados e investiga otra causa.
La guía sobre variabilidad de las mediciones explica que los cambios de red, dispositivo, servidor o página pueden alterar las puntuaciones sin modificar el código. El estado de los anuncios y de los avisos de consentimiento también forma parte de las condiciones de comparación. Registra la fecha, URL, versiones de herramientas, ajustes, métricas y cambio realizado en el informe. Evalúa las métricas de usuarios reales tras disponer de un período de recopilación y unas muestras suficientes.
Cuando el análisis falla o los resultados difieren sustancialmente
Si una página no se carga, el acceso está bloqueado o los redireccionamientos fallan, verifique la URL final y una respuesta HTTP normal antes de interpretar un puntaje. No elimines la autenticación para exponer una página privada a una prueba externa. Para mediciones locales, verifique la configuración de inicio de sesión y de borrado de almacenamiento. Si pueden estar involucradas extensiones, repite el mismo objetivo en un entorno con menos influencia de extensiones.
Una diferencia entre PageSpeed Insights y el puntaje de su PC no es automáticamente un fallo. Primero compara las versiones de Lighthouse, las rutas de acceso al servidor, la configuración del dispositivo y de limitación de red y CPU, y el estado de las cookies. No intentes hacer que los puntajes de móvil y escritorio coincidan; compara los cambios antes y después dentro de cada condición y considera las métricas de los visitantes reales.




