Cómo medir Core Web Vitals: herramientas de Google, extensiones y alternativas

Medir Core Web Vitals es gratis y no requiere instalar nada, pero es también donde se comete el error más caro del rendimiento web: mirar el número de laboratorio de PageSpeed Insights, verlo en verde y concluir que el sitio va bien para los usuarios reales. Casi nunca es así. El score de laboratorio y lo que viven las personas frente a la pantalla son dos cosas distintas, y confundirlas lleva a celebrar mejoras que Google nunca vio.

Cuando audito Core Web Vitals sigo siempre el mismo orden: parto por los datos de campo de todo el sitio, bajo al grupo de URLs que peor está en cada métrica, elijo unas pocas URLs concretas por tipo de página y recién ahí abro las herramientas de laboratorio para encontrar la causa. Ese recorrido termina en dos cosas que los equipos de marketing y desarrollo pueden usar: evidencia gráfica de lo que pasa en la carga y un plan de acciones priorizado.

Qué son los Core Web Vitals y qué miden de verdad

Los Core Web Vitals son tres métricas con las que Google intenta cuantificar la experiencia real de una página: qué tan rápido aparece el contenido principal, qué tan bien responde a la interacción y qué tan estable se mantiene mientras carga. Más que un puntaje de velocidad, son una forma de medir frustraciones concretas: la espera, el clic que no responde, el botón que se corre justo cuando se va a tocar.

LCP: carga

Largest Contentful Paint mide cuándo aparece el elemento principal de la página, casi siempre la imagen del hero o el titular. Bueno: hasta 2,5 segundos.

INP: respuesta

Interaction to Next Paint mide cuánto tarda la página en responder visualmente a un clic o un toque, durante toda la visita. Bueno: hasta 200 milisegundos.

CLS: estabilidad

Cumulative Layout Shift mide cuánto se mueve el contenido mientras la página carga, sin que el usuario lo provoque. Bueno: hasta 0,1.

Una URL aprueba la evaluación de Core Web Vitals cuando las tres están en verde en el percentil 75 de las cargas, medido por separado en móvil y escritorio. INP reemplazó a FID como métrica oficial de interactividad el 12 de marzo de 2024 (web.dev, 2024). Son señal de ranking, sí, pero antes que eso son un termómetro de experiencia: mejorarlos suele mejorar conversión y permanencia, lo tome Google en cuenta o no.

Laboratorio vs campo: la distinción que explica casi todos los diagnósticos equivocados

Hay dos maneras de obtener los números de Core Web Vitals, y no son intercambiables. Confundirlas es el origen de casi todos los diagnósticos equivocados que veo en auditorías.

Los datos de laboratorio salen de un entorno simulado y repetible: una sola carga de la página, en un dispositivo y una red que la herramienta finge. Lighthouse es el motor que produce estos datos. Sirven para diagnosticar, porque son reproducibles y aíslan variables, pero describen una carga artificial y no a una persona de verdad.

Los datos de campo salen de usuarios reales de Chrome que optaron por compartir su experiencia: lo que efectivamente vivieron miles de personas en sus dispositivos y sus redes. Esa fuente se llama CrUX (Chrome UX Report) y es la que Google usa para evaluar Core Web Vitals como señal de ranking.

• Laboratorio (Lighthouse): una carga simulada, con dispositivo y red fingidos y resultado repetible. Bueno para encontrar la causa, malo para saber cómo le va al sitio de verdad.
• Campo (CrUX): usuarios reales de Chrome, muchos dispositivos y redes, ventana móvil de 28 días. Es lo que Google mira para ranking.
• El laboratorio da un número único y limpio; el campo da una distribución de miles de cargas resumida en el percentil 75.
• En una carga normal, Lighthouse no mide INP porque nadie interactúa: usa TBT (Total Blocking Time) como aproximación. El modo timespan de Lighthouse sí registra INP mientras se hace clic en la página.
• El laboratorio no carga con el peso de las extensiones, los teléfonos de gama baja ni las redes malas que sí aparecen en el campo.

Las herramientas oficiales de Google para medir Core Web Vitals

Google tiene cinco herramientas gratuitas que cubren casi todo el trabajo de medición, y cada una responde una pregunta distinta. En noviembre de 2025 apagó el dashboard de CrUX que vivía en Looker Studio (hoy de nuevo Data Studio) y lo reemplazó por CrUX Vis (Chrome for Developers, 2025), así que cualquier procedimiento que todavía dependa de ese dashboard necesita actualizarse.

CrUX Vis: el diagnóstico inicial de los datos de campo

CrUX Vis es la vista más rápida para saber cómo está un sitio con los datos que Google usa. Se escribe el dominio o una URL y muestra la evolución semanal de LCP, INP y CLS de las últimas 40 semanas, por separado en móvil y escritorio, con la proporción de cargas buenas, a mejorar y malas. Cada punto agrega los 28 días previos y la serie se actualiza cada lunes, de modo que también es la herramienta para confirmar, semanas después, si un arreglo movió el campo.

Desde octubre de 2026 muestra además variantes experimentales de las tres métricas que cuentan las soft navigations de las aplicaciones de una sola página (SPA), las navegaciones que cambian la URL sin recargar la página. Google apunta a hacerlas oficiales en mayo de 2027 (web.dev, 2026). En un sitio hecho con React, Vue o Angular conviene mirarlas desde ya, porque pueden cambiar bastante el resultado.

Search Console: el informe de Core Web Vitals por grupos de URLs

El informe de Core Web Vitals de Search Console usa los mismos datos de CrUX, pero los ordena de otra forma: agrupa las URLs indexadas que se parecen entre sí y marca cada grupo como bueno, a mejorar o malo, por métrica y por dispositivo. Guarda tres meses de historia y permite validar un arreglo sobre una ventana de 28 días. Es donde encuentro qué grupo de URLs está peor en cada métrica.

Cómo leer ese informe y el resto de la herramienta está en la guía sobre cómo usar Google Search Console.

PageSpeed Insights: campo y laboratorio de una URL

PageSpeed Insights junta las dos fuentes para una URL. Arriba muestra los datos de campo de CrUX, con la evaluación de Core Web Vitals aprobada o reprobada cuando hay tráfico suficiente; abajo, la auditoría de laboratorio de Lighthouse con el score de 0 a 100 y los diagnósticos. La trampa es ese score grande y de color: la lectura correcta es al revés, primero el campo, que es el veredicto, y después el laboratorio, que es la pista de por qué.

Lighthouse: el motor de auditoría de laboratorio

Lighthouse produce todos los datos de laboratorio. Corre dentro de Chrome DevTools, como parte de PageSpeed Insights y por línea de comandos para automatizarlo. Desde la versión 13 (octubre de 2025) sus diagnósticos de rendimiento se presentan como insights, los mismos que aparecen en el panel Performance de DevTools (Chrome for Developers, 2025). Lo uso para reproducir un problema y aislarlo, teniendo presente que es la foto de una carga simulada: si el dispositivo y la red que simula no se parecen a los de la audiencia, el número engaña.

El panel Performance de Chrome DevTools: métricas en vivo y datos de campo

Al abrir el panel Performance de DevTools (clic derecho, Inspeccionar, pestaña Performance) aparecen LCP y CLS de la carga actual, e INP en cuanto se interactúa con la página, con el detalle de cada interacción y de cada desplazamiento del layout. En Field data se conectan los datos de CrUX de la misma URL, de modo que la medición local queda al lado de la de los usuarios reales. Este panel absorbió las funciones de la extensión Web Vitals, que Google dejó de mantener en enero de 2025 (Chrome for Developers, 2025).

Cómo audito Core Web Vitals paso a paso

El orden importa tanto como las herramientas. Esta es la secuencia que sigo en las auditorías, desde el primer vistazo hasta el plan que se entrega a los equipos.

1. Diagnóstico inicial del sitio en CrUX Vis

Parto por CrUX Vis con el dominio completo. En un par de minutos se ve si el sitio aprueba o no en cada métrica, en qué dispositivo está el problema y si la tendencia viene mejorando o empeorando. Casi siempre el problema está en móvil, y ese dato ya ordena el resto de la auditoría.

2. Rastreo con Screaming Frog y la API de PageSpeed conectada

Con el panorama de CrUX Vis, lanzo un rastreo del sitio en Screaming Frog con la API de PageSpeed Insights conectada (se configura con una clave gratuita de Google en el acceso a APIs). Así cada URL rastreada trae sus datos de campo de CrUX, cuando los tiene, y su auditoría de Lighthouse, al lado de la plantilla, el código de respuesta y el resto de los datos SEO. En un sitio grande no hace falta rastrear todo: una lista de URLs representativas por plantilla alcanza. Cómo configurar la integración y leer sus columnas está en la guía de Screaming Frog.

3. El grupo de URLs más malo por métrica en Search Console

Mientras el rastreo corre, voy al informe de Core Web Vitals de Search Console y abro, métrica por métrica, el grupo de URLs que peor está. Es Google diciendo con sus propios datos qué hay que arreglar primero, y no conviene desaprovechar esa pista. Ahí también aparece la diferencia entre un problema general del sitio y uno concentrado en una sección: un CLS malo que solo afecta a las fichas de producto no se resuelve igual que un LCP lento en todo el sitio.

4. Tres URLs con las peores métricas, por tipo de página

Cruzo esos grupos con el rastreo y elijo, de cada uno, las tres URLs con las peores métricas, separadas por tipo de página: home, listados de categoría (PLP), fichas de producto (PDP), páginas institucionales, fichas de tienda local y artículos del blog. Separar por tipo sirve porque cada tipo comparte plantilla, componentes y estilos, y los errores se repiten dentro de la plantilla. Un carrusel sin dimensiones en la PLP o un banner de cookies que empuja el contenido en la PDP se arregla una vez y mejora miles de URLs.

5. Evidencia gráfica con WebPageTest

Esas URLs pasan por WebPageTest, que tiene un plan gratis de 150 pruebas al mes. De ahí saco la tira de fotogramas de la carga, el video, la cascada de recursos y la vista de Web Vitals, que marca el elemento LCP y cada desplazamiento del layout sobre la captura. Esa evidencia es la que mejor funciona para explicar el problema: al equipo de marketing le muestra en qué segundo aparece el banner que empuja todo hacia abajo, y al de desarrollo le muestra qué recurso, en qué orden, retrasó el render.

6. Pruebas en el inspector de Chrome sin tocar producción

El inspector de Chrome, y el de cualquier navegador basado en Chromium como Edge o Brave, permite probar hipótesis antes de pedirle un cambio a nadie. Estas son las funciones que más uso:

• Network, bloqueo de solicitudes: se bloquea un script (el contenedor de GTM, Clarity, un widget de chat) y se vuelve a medir. La diferencia es el costo real de ese script en LCP o INP.
• Network y Performance, limitación de red y CPU: simular un teléfono de gama media en 4G muestra lo que un notebook con fibra esconde.
• Performance, insights: la barra lateral señala el elemento LCP con sus fases, los responsables del CLS y las interacciones lentas con el script que las retrasó.
• Coverage: mide cuánto del JavaScript y el CSS que se descarga no se usa al cargar la página.
• Rendering, Layout Shift Regions: pinta en pantalla las zonas que se mueven mientras carga, útil para encontrar al culpable del CLS a simple vista.
• Sources, Overrides: reemplaza un archivo del sitio por una versión local modificada, de modo que se puede probar un arreglo (un atributo de alto y ancho, un script diferido) y medirlo antes de pedirlo al equipo de desarrollo.

7. Un plan de acciones priorizado y aterrizado

El cierre de la auditoría es un plan ordenado por impacto y esfuerzo, escrito para que el equipo de desarrollo sepa exactamente qué tocar. Los arreglos que más veces aparecen arriba en ese plan, porque cuestan poco y mueven mucho, son estos:

• Ancho y alto explícitos en imágenes, videos e iframes, para que el navegador reserve el espacio antes de que carguen. Es de los arreglos con más efecto en CLS.
• Imágenes en WebP o AVIF y dimensionadas para el tamaño en que se muestran, no la foto original de 3.000 píxeles reducida por CSS.
• Prioridad alta (fetchpriority) para la imagen que es el elemento LCP, y nunca carga diferida en ella. La carga diferida queda para las imágenes bajo el pliegue.
• Espacio reservado para banners, avisos de cookies y bloques que se insertan después de cargar, que son la causa más común de CLS en ecommerce.

Scripts de terceros: retrasarlos sin perder la medición

Proponer que se saque Google Tag Manager, la etiqueta de GA4 o el píxel de Clarity no es una recomendación realista: el negocio los necesita. Lo que sí se puede auditar es cómo cargan dentro del flujo y qué se puede retrasar sin afectar la medición ni la funcionalidad. La configuración de GA4 tiene que seguir cargando temprano para no perder sesiones, pero los mapas de calor, las grabaciones de sesión, los píxeles publicitarios y los widgets de chat casi siempre pueden pasar a un disparador de ventana cargada en GTM, o a cargarse con la primera interacción. Ese tipo de recomendación es la que más sirve a un equipo de desarrollo, porque mueve LCP e INP sin quitarle nada a marketing.

La corrección técnica en detalle de LCP, INP y CLS está en la guía de SEO técnico y Core Web Vitals.

Extensiones de Chrome para revisar Core Web Vitals

La extensión Web Vitals de Google, la que recomendaban casi todos los tutoriales, dejó de recibir soporte en enero de 2025 y ya no se puede instalar: sus funciones están ahora en el panel Performance de DevTools. Para tener las métricas a la vista mientras se navega un sitio, estas son las extensiones que siguen mantenidas:

• Core Web Vitals Visualizer (corewebvitals.io): muestra LCP, INP, CLS, FCP y TTFB de la sesión en vivo, desglosados por fases, junto a 25 semanas de historia de CrUX de la URL. Es la más completa de las que revisé.
• Lighthouse (Google): genera el informe de laboratorio desde los servidores de PageSpeed Insights, así que solo audita URLs públicas. Para un sitio en localhost hay que usar el panel Lighthouse de DevTools.
• Site Speed by DebugBear: métricas en vivo de la carga y una comparación con lo que mide PageSpeed sin la simulación de red lenta. Útil, aunque lleva más de un año sin actualizarse.

Las extensiones que mostraban datos de CrUX directamente en los resultados de Google quedaron sin mantenimiento y todavía muestran FID, una métrica que se retiró en 2024, así que no conviene usarlas.

Límites de estas herramientas y errores comunes al medir

• El laboratorio no es el campo: un buen score de Lighthouse no garantiza buena experiencia real, y el ranking se juega en el campo.
• CrUX necesita tráfico suficiente: los sitios chicos o las URLs con pocas visitas no tienen datos de campo. Ahí PageSpeed muestra solo laboratorio y hace falta un RUM propio (medición de usuarios reales instalada en el sitio).
• La ventana de 28 días introduce desfase: correr PageSpeed dos horas después de un arreglo y ver el campo igual no significa que el arreglo falló.
• El laboratorio depende del dispositivo y la red simulados: un teléfono de gama baja en 4G da otra foto que un escritorio con fibra.
• El percentil 75 resume miles de cargas: un buen resultado puede tapar una cola de usuarios con experiencias pésimas.
• En las SPA, las métricas oficiales solo cuentan la primera carga. Las navegaciones internas aparecen en las variantes experimentales con soft navigations de CrUX.

Alternativas a las herramientas de Google según el caso

Las herramientas de Google tienen techo: sitios sin datos de campo, necesidad de monitoreo continuo o de auditar miles de URLs. Estas son las alternativas que valen la pena, ordenadas por el problema que resuelven.

SpeedCurve, Calibre y RUMvision son excelentes pero apuntan a equipos grandes; Sentry y Datadog tienen paneles de Web Vitals que se justifican si ya están en el stack, y Vercel Speed Insights sirve solo para sitios publicados en Vercel. Ninguna reemplaza la lógica de fondo: campo para el veredicto, laboratorio para la causa.

El resto de las herramientas que uso en el día a día, gratuitas y de pago, está en la guía de las mejores herramientas SEO.

Preguntas frecuentes sobre cómo medir Core Web Vitals

En resumen: cómo medir bien los Core Web Vitals

Medir Core Web Vitals gratis es fácil; medirlos bien es seguir un orden. CrUX Vis da el diagnóstico de campo del sitio, Screaming Frog con la API de PageSpeed pone los datos de cada URL junto a su plantilla, Search Console muestra qué grupo de URLs está peor, PageSpeed y Lighthouse explican la causa en un puñado de URLs por tipo de página, WebPageTest y el inspector de Chrome dejan la evidencia y prueban los arreglos, y CrUX Vis confirma semanas después si el campo se movió.

Y cuando medir bien deja de alcanzar y hay que llevar la performance a terreno, en Milimetrix somos una agencia experta en SEO técnico que trabaja esto todos los días: del diagnóstico de campo al arreglo verificado.

Al final, la auditoría vale por lo que el equipo de desarrollo puede ejecutar con ella. Un score de laboratorio en verde no le mejora la carga a nadie; un plan que dice qué plantilla tocar, qué script retrasar y qué imagen dimensionar, sí.