¿Qué es la monitorización del rendimiento con Lighthouse?
Google Lighthouse es una herramienta de código abierto que audita una página web en rendimiento, accesibilidad, buenas prácticas y SEO. Una auditoría aislada muestra cómo funciona una página hoy; la monitorización del rendimiento con Lighthouse repite esas auditorías con regularidad para que veas tendencias, detectes regresiones tras un lanzamiento y compruebes que las optimizaciones han funcionado. Esta guía explica qué mide Lighthouse, cómo se calcula la puntuación de rendimiento, qué umbrales de Core Web Vitals se aplican hoy (incluido INP, que sustituyó a FID en 2024) y cómo actuar con los resultados.
Qué mide Lighthouse
Cada informe de Lighthouse puntúa una página de 0 a 100 en cuatro categorías:
Rendimiento
Lo rápido que se carga la página, se vuelve utilizable y se mantiene visualmente estable, según métricas de laboratorio como Largest Contentful Paint, Total Blocking Time y Cumulative Layout Shift.
Accesibilidad
Si las personas que usan tecnologías de apoyo pueden utilizar la página: contraste de color, texto alternativo, etiquetas de formularios, orden de encabezados y navegación por teclado.
Buenas prácticas
Estándares web actuales como HTTPS, sin errores del navegador en la consola, código de terceros seguro e imágenes con el tamaño adecuado.
SEO
Requisitos básicos de los buscadores: título y meta descripción, enlaces rastreables, hreflang válido y una página que no esté bloqueada para la indexación.
Cómo se calcula la puntuación de rendimiento de Lighthouse
Desde Lighthouse 10, la puntuación de rendimiento es una media ponderada de cinco métricas de laboratorio. Total Blocking Time y los dos Core Web Vitals que Lighthouse puede medir tienen el mayor peso:
- Total Blocking Time (TBT)
- 30 %
- Largest Contentful Paint (LCP)
- 25 %
- Cumulative Layout Shift (CLS)
- 25 %
- First Contentful Paint (FCP)
- 10 %
- Speed Index
- 10 %
Las puntuaciones de 90 a 100 se consideran buenas, de 50 a 89 necesitan mejorar y de 0 a 49 son deficientes. Time to Interactive (TTI) ya no forma parte de la puntuación.
Las puntuaciones varían entre ejecuciones por las condiciones de red, la carga del servidor y las extensiones del navegador. Por eso las tendencias de muchas ejecuciones son más fiables que una sola auditoría.
Core Web Vitals: LCP, INP y CLS
Los Core Web Vitals son las tres métricas de experiencia de usuario de Google para carga, capacidad de respuesta y estabilidad visual. Interaction to Next Paint (INP) sustituyó oficialmente a First Input Delay (FID) como métrica de capacidad de respuesta el 12 de marzo de 2024. Google recomienda medir cada métrica en el percentil 75 de las cargas de página, por separado para móvil y escritorio.
Largest Contentful Paint (LCP)
Bueno: 2,5 s o menos · Deficiente: más de 4 s
LCP mide cuánto tarda en mostrarse la imagen o el bloque de texto más grande del área visible. Es el mejor indicador de cuándo ven los usuarios el contenido principal.
Por qué importa: Un LCP lento hace que los visitantes miren una página incompleta. Las causas habituales son respuestas lentas del servidor, recursos que bloquean el renderizado e imágenes principales pesadas.
Cómo mejorarlo:
- Reduce el tiempo de respuesta del servidor (TTFB) con caché y una CDN
- Sirve la imagen LCP en un formato moderno (WebP o AVIF) y con el tamaño adecuado
- No apliques lazy loading a la imagen LCP y dale fetchpriority="high"
- Elimina o aplaza el CSS y el JavaScript que bloquean el renderizado
Interaction to Next Paint (INP)
Bueno: 200 ms o menos · Deficiente: más de 500 ms
INP mide lo rápido que responde la página a clics, toques y pulsaciones de teclas durante toda la visita, e informa de una de las interacciones más lentas. FID solo medía el retraso antes de procesar la primera interacción.
Por qué importa: Un INP deficiente hace que una página parezca lenta o rota, aunque haya cargado rápido. La causa más habitual son tareas largas de JavaScript que bloquean el hilo principal.
Cómo mejorarlo:
- Divide las tareas largas y cede el control al hilo principal
- Reduce y aplaza los scripts de terceros
- Mantén los controladores de eventos ligeros y saca el trabajo pesado del hilo principal
- Evita actualizaciones grandes y complejas del DOM tras cada interacción
Cumulative Layout Shift (CLS)
Bueno: 0,1 o menos · Deficiente: más de 0,25
CLS mide cuánto se desplaza de forma inesperada el contenido visible mientras la página está abierta. Un desplazamiento ocurre cuando un elemento cambia de posición entre fotogramas sin que el usuario haga nada.
Por qué importa: Los desplazamientos de diseño hacen que los usuarios pierdan el hilo o pulsen el botón equivocado. Suelen deberse a imágenes sin dimensiones, anuncios o elementos incrustados que cargan tarde y fuentes web.
Cómo mejorarlo:
- Indica ancho y alto (o aspect-ratio) en imágenes, vídeos e iframes
- Reserva espacio para anuncios, elementos incrustados y contenido dinámico
- No insertes contenido encima del existente salvo que el usuario lo pida
- Usa font-display y precarga las fuentes clave para limitar los desplazamientos del texto
Medir INP con Lighthouse
Una auditoría estándar de Lighthouse carga la página sin interactuar con ella, así que no puede medir INP. Usa Total Blocking Time como sustituto de laboratorio: un TBT alto suele significar un INP deficiente para los usuarios reales. Para ver valores reales de INP, consulta los datos de campo del Chrome UX Report en PageSpeed Insights o el informe de Core Web Vitals de Google Search Console.
Datos de laboratorio frente a datos de campo
Lighthouse genera datos de laboratorio: una prueba controlada en un dispositivo y una red simulados. Los datos de campo proceden de usuarios reales de Chrome. Necesitas ambos.
Datos de laboratorio (Lighthouse)
Reproducibles y disponibles al instante, incluso para páginas con poco tráfico. Ideales para detectar regresiones antes y después de un lanzamiento y para depurar problemas concretos.
Datos de campo (Chrome UX Report)
Reflejan dispositivos, redes e interacciones reales, y son lo que Google utiliza para los Core Web Vitals en la Búsqueda. Se agregan sobre los últimos 28 días, por lo que los cambios tardan en notarse.
Rendimiento en móvil frente a escritorio
Los resultados en móvil y escritorio suelen diferir mucho, y Google evalúa los Core Web Vitals de cada uno por separado. Prueba ambos.
Móvil
La auditoría móvil de Lighthouse simula un teléfono de gama media con la CPU limitada y una red más lenta. Las puntuaciones móviles suelen ser más bajas y más cercanas a lo que viven muchos visitantes reales.
Escritorio
La auditoría de escritorio usa una conexión simulada más rápida y sin limitación de CPU móvil. Una buena puntuación en escritorio no significa que la experiencia móvil también lo sea.
Cómo mejorar tu puntuación de rendimiento en Lighthouse
La mayoría de las mejoras proceden de unas pocas técnicas. Empieza por el área que tu informe señala con más fuerza:
Ruta de renderizado crítica
Muestra antes el primer contenido y el más grande (FCP, LCP).
Técnicas:- Incluye en línea el CSS crítico y aplaza el resto
- Precarga la imagen LCP y las fuentes clave
- Elimina el JavaScript que bloquea el renderizado
- Mejora el tiempo de respuesta del servidor (TTFB)
Imágenes y multimedia
Las imágenes suelen ser los recursos más pesados de una página (LCP, CLS).
Técnicas:- Usa WebP o AVIF con alternativas
- Sirve imágenes responsive con srcset y sizes
- Aplica lazy loading solo a las imágenes fuera del área visible
- Indica siempre las dimensiones de las imágenes
JavaScript
Menos trabajo en el hilo principal significa mejor capacidad de respuesta (TBT, INP).
Técnicas:- Divide los bundles y carga el código bajo demanda
- Elimina el código no utilizado con tree shaking
- Divide las tareas largas
- Limita y aplaza los scripts de terceros
Red y caché
Entrega cada recurso más rápido (todas las métricas).
Técnicas:- Usa una CDN cercana a tus usuarios
- Sirve el contenido mediante HTTP/2 o HTTP/3
- Define tiempos de caché largos para los recursos estáticos
- Reduce las consultas DNS y reutiliza las conexiones
Problemas de rendimiento habituales y sus soluciones
Los problemas de rendimiento suelen seguir patrones conocidos. Aquí tienes tres que reconocerás, con las métricas afectadas y por dónde empezar.
La tienda online se ralentiza durante las rebajas
Las páginas de producto pesan más y el servidor va más lento justo cuando el tráfico está en su pico.
- LCP lento por imágenes de producto grandes y sin optimizar
- Desplazamientos de diseño por banners y reseñas que cargan tarde
- TBT alto por scripts de marketing y seguimiento
Los compradores esperan más y más de ellos abandonan antes del pago
- Redimensiona y comprime las imágenes de producto y sírvelas en WebP o AVIF
- Reserva espacio para banners y widgets dinámicos
- Revisa los gestores de etiquetas y aplaza los scripts no esenciales
- Almacena las páginas en caché en el edge con una CDN
Web de noticias ante un pico de tráfico
Una noticia de última hora dispara el tráfico muy por encima de lo normal.
- FCP y LCP lentos porque el servidor de origen no da abasto
- Desplazamientos de diseño por anuncios y contenido multimedia incrustado
- Mala capacidad de respuesta por scripts publicitarios pesados
Los lectores se van antes de que aparezca el artículo
- Sirve versiones en caché o estáticas de las páginas de artículos
- Reserva espacios fijos para anuncios y elementos incrustados
- Carga los scripts de terceros después del contenido principal
- Aumenta la capacidad del servidor antes de los picos previstos
La aplicación web se vuelve más lenta con cada versión
Las nuevas funciones añaden JavaScript poco a poco hasta que la aplicación resulta lenta.
- Bundles de JavaScript cada vez más grandes
- Tareas largas que elevan el TBT y empeoran el INP
- Más dependencias de terceros
Los usuarios notan retrasos en las tareas cotidianas
- Divide el código por rutas y carga las funciones bajo demanda
- Define un presupuesto de rendimiento y compruébalo en cada versión
- Elimina las dependencias que no uses
- Sigue las puntuaciones de Lighthouse de forma continua para detectar regresiones a tiempo
Monitorización del rendimiento con Lighthouse en nanokoi.io
nanokoi.io incluye en todos los planes la monitorización del rendimiento con Google Lighthouse y el seguimiento de Core Web Vitals, junto con la monitorización de sitios web para uptime, certificados SSL y DNS.
Auditorías de Lighthouse automatizadas
En lugar de ejecutar Lighthouse a mano, nanokoi.io audita por ti las URL que monitorizas, para que siempre tengas puntuaciones actualizadas de rendimiento, accesibilidad, buenas prácticas y SEO.
Seguimiento de Core Web Vitals
Sigue la evolución de las puntuaciones y los Core Web Vitals para ver si un lanzamiento ha mejorado o empeorado las cosas. Los datos de monitorización se pueden exportar en CSV, JSON o XML para tus propios análisis.
Informes de optimización generados por IA
Los informes de optimización generados por IA convierten los resultados de Lighthouse en una lista priorizada de mejoras. El plan Professional añade insights de rendimiento con IA; consulta los precios para ver qué incluye cada plan.
Primeros pasos
Puedes configurar la monitorización del rendimiento con Lighthouse en pocos minutos. ¿Es tu primera vez con la monitorización? Nuestra guía de monitorización de sitios web explica los conceptos básicos.
- 1Añade tu sitio web: Crea una cuenta gratuita y añade las URL que quieres monitorizar: el plan Free incluye hasta 5.
- 2Revisa tu punto de partida: Consulta las primeras puntuaciones de Lighthouse y los Core Web Vitals de cada página y anota la métrica más débil.
- 3Corrige primero el problema principal: Sigue el informe de optimización generado por IA, empezando por la métrica más alejada de «bueno».
- 4Sigue la tendencia: Compara las puntuaciones tras cada lanzamiento para confirmar las mejoras y detectar regresiones a tiempo.
Preguntas frecuentes sobre la monitorización con Lighthouse
¿Qué es una buena puntuación de rendimiento en Lighthouse?
90 o más se considera buena, de 50 a 89 necesita mejorar y por debajo de 50 es deficiente. Toma la puntuación como orientación: las métricas individuales, sobre todo LCP, TBT y CLS, te dicen qué corregir.
¿Lighthouse sigue midiendo FID?
No. FID dejó de ser un Core Web Vital en marzo de 2024 y fue sustituido por INP. Lighthouse no puede medir INP en una auditoría estándar de carga, así que muestra Total Blocking Time como sustituto de laboratorio.
¿Por qué cambian mis puntuaciones de Lighthouse entre ejecuciones?
Las condiciones de red, la carga del servidor, la CPU disponible y las extensiones del navegador afectan a los resultados de laboratorio. Monitorizar a lo largo del tiempo suaviza ese ruido y muestra la tendencia real.
¿Afectan las puntuaciones de Lighthouse al posicionamiento en Google?
No directamente. Los sistemas de clasificación de Google usan los Core Web Vitals de datos de campo de usuarios reales como parte de la experiencia de página, no la puntuación de Lighthouse. Lighthouse te ayuda a encontrar y corregir los problemas que afectan a esas métricas.
Empieza a monitorizar tu rendimiento con Lighthouse
Sigue las puntuaciones de Lighthouse y los Core Web Vitals de tus páginas clave y recibe informes de optimización generados por IA. El plan Free incluye hasta 5 URL.
Empieza a monitorizar gratisNo se requiere tarjeta de crédito