Los Core Web Vitals son tres métricas definidas por Google que miden la experiencia real de carga e interacción de una página: LCP (Largest Contentful Paint) mide cuánto tarda en verse el contenido principal, INP (Interaction to Next Paint) mide cuánto tarda la página en responder a las interacciones del usuario y CLS (Cumulative Layout Shift) mide cuánto se mueve el contenido de forma inesperada. Una página supera la evaluación cuando el 75 % de sus visitas reales están dentro de los umbrales “buenos”: LCP ≤ 2,5 s, INP ≤ 200 ms y CLS ≤ 0,1.
Este artículo explica qué mide cada una, de dónde salen los datos y qué suele estropearlas, sin entrar en promesas sobre posicionamiento que Google no hace.
Las tres métricas y sus umbrales
| Métrica | Qué mide | Bueno | Necesita mejorar | Malo |
|---|---|---|---|---|
| LCP | Tiempo hasta que se pinta el elemento de contenido más grande visible | ≤ 2,5 s | 2,5 – 4 s | > 4 s |
| INP | Latencia de las interacciones (clics, toques, teclas) a lo largo de toda la visita | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS | Suma de los desplazamientos inesperados de la maquetación | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Los umbrales se aplican al percentil 75 de las visitas: la página aprueba una métrica si al menos tres de cada cuatro experiencias de usuario están en el rango bueno. Es una medida deliberadamente exigente para que no baste con que la página vaya rápido en un ordenador potente con buena conexión.
LCP: cuándo se ve lo importante
El LCP marca el momento en que el navegador pinta el elemento más grande dentro del viewport: normalmente una imagen destacada, un vídeo con póster o un bloque de texto grande. Lo que más lo retrasa:
- Imágenes principales pesadas o sin prioridad (ver lazy loading y fetchpriority).
- Respuesta lenta del servidor (TTFB alto).
- CSS o JavaScript que bloquean el renderizado.
- Fuentes web que retrasan la aparición del texto.
INP: cómo responde la página
INP sustituyó a FID (First Input Delay) como Core Web Vital en marzo de 2024. A diferencia de FID, que solo medía la primera interacción, INP observa todas las interacciones de la visita y reporta una de las peores (en la práctica, la más lenta, ignorando algún valor atípico en páginas con muchas interacciones). Mide desde que el usuario interactúa hasta que el navegador pinta el siguiente frame.
Lo que lo estropea es, casi siempre, JavaScript: tareas largas en el hilo principal, manejadores de eventos pesados, frameworks que hidratan toda la página antes de responder, scripts de terceros (publicidad, analítica, chats) compitiendo por la CPU.
CLS: que nada salte
CLS suma los desplazamientos de elementos visibles que ocurren sin que el usuario los haya provocado. Las causas clásicas:
- Imágenes, vídeos o iframes sin
widthyheight. - Anuncios o incrustaciones que se insertan sin espacio reservado.
- Fuentes web que cambian el tamaño del texto al cargarse.
- Contenido insertado dinámicamente por encima de lo que ya se ve (avisos, banners).
Si una web va a mostrar publicidad, reservar la altura de cada bloque de anuncios antes de que cargue es la medida más eficaz contra el CLS.
De dónde salen los datos: campo y laboratorio
Hay dos tipos de medición y conviene no confundirlos:
- Datos de campo (reales). Proceden de usuarios reales de Chrome que han aceptado compartir estadísticas, recogidos en el Chrome UX Report (CrUX). Son los que usa Google Search Console en su informe de Core Web Vitals y los que cuentan para la evaluación. Solo existen si la página tiene tráfico suficiente.
- Datos de laboratorio (simulados). Los produce una herramienta como Lighthouse o PageSpeed Insights en un entorno controlado. Sirven para diagnosticar y reproducir problemas, pero no reflejan la variedad de dispositivos y conexiones reales. INP, además, no puede medirse en laboratorio porque depende de las interacciones del usuario (Lighthouse ofrece TBT, Total Blocking Time, como aproximación).
PageSpeed Insights muestra ambos: arriba los datos de campo de CrUX (si los hay) y abajo el análisis de laboratorio.
Cómo medirlos en tu web
- PageSpeed Insights (pagespeed.web.dev): introduce la URL y revisa primero la sección de datos reales.
- Google Search Console, informe “Core Web Vitals”: agrupa las URLs del sitio por estado (buenas, necesitan mejorar, malas) a partir de CrUX.
- Chrome DevTools, panel Performance: muestra LCP, INP y CLS en vivo mientras navegas y señala el elemento responsable de cada uno.
- Librería web-vitals (
npm install web-vitals): permite recoger las métricas de tus propios usuarios y enviarlas a tu analítica.
Qué relación tienen con el posicionamiento
Google indica en su documentación para Search que los Core Web Vitals forman parte de las señales de experiencia de página y recomienda a los propietarios obtener buenos resultados, pero también deja claro que un buen contenido relevante sigue siendo lo principal y que unos Vitals excelentes no compensan un contenido pobre. Es razonable tratarlos como lo que son: una medida de calidad para los usuarios, que además evita una desventaja frente a competidores con páginas igual de relevantes pero más rápidas.
Errores habituales al optimizar
- Optimizar solo para Lighthouse. Una puntuación de 100 en laboratorio no garantiza datos de campo buenos si tus usuarios reales usan móviles modestos.
- Diferir la imagen del LCP. Aplicar
loading="lazy"a la imagen principal empeora el LCP. - Cargar scripts de terceros sin control. Son la causa más frecuente de INP alto. Carga solo lo imprescindible y, cuando dependa del consentimiento del usuario, no lo cargues hasta tenerlo.
- Ignorar el CLS de los anuncios. Reserva espacio con
min-heighten cada bloque publicitario.
Conclusión
LCP, INP y CLS resumen en tres números si una página se ve pronto, responde rápido y no salta. Se evalúan con datos de usuarios reales en el percentil 75, y se mejoran con decisiones concretas: priorizar la imagen principal, minimizar y aplazar JavaScript, declarar dimensiones y reservar espacio para todo lo que se inserta tarde. Antes de optimizar, mide en campo; después, usa el laboratorio para encontrar la causa.