Core Web Vitals son un subconjunto de tres métricas, dentro de un grupo más amplio de señales de experiencia de página, que Google considera lo bastante decisivas para la experiencia real del usuario como para convertirlas en factor de posicionamiento explícito. Las tres miden aspectos distintos de una misma pregunta: ¿la página responde a la velocidad y con la estabilidad que un usuario espera, sin que tenga que pensarlo? Entender qué mide cada una en detalle técnico es la única forma de arreglar la causa real en vez de aplicar optimizaciones genéricas que no atacan el problema específico de tu web.
LCP (Largest Contentful Paint): qué elemento se mide y por qué
El LCP mide el tiempo que tarda en renderizarse, dentro del viewport visible, el elemento de contenido más grande de la carga inicial: normalmente una imagen destacada, un vídeo de fondo, o un bloque de texto grande si no hay imágenes por encima. El umbral considerado "bueno" es 2.5 segundos o menos; entre 2.5 y 4 segundos se considera "necesita mejora"; por encima de 4 segundos es "deficiente". Un matiz técnico importante: el LCP no mide cuándo la página empieza a cargar contenido, sino cuándo termina de cargar específicamente el elemento más grande, así que optimizar elementos pequeños que no son el candidato a LCP no mueve la métrica en absoluto.
Las causas técnicas más frecuentes de un LCP alto son, en orden de impacto: un servidor lento en responder la petición inicial (Time to First Byte alto, normalmente por hosting compartido saturado o ausencia de caché de servidor); recursos que bloquean el renderizado (CSS o JavaScript grandes cargados de forma síncrona en el <head> antes de que el navegador pueda pintar nada); y la imagen candidata a LCP cargada sin prioridad, un error muy común cuando esa imagen está definida en CSS como background-image en vez de como una etiqueta <img>, porque el navegador descubre los background-image mucho más tarde en el proceso de carga que las imágenes declaradas en el HTML.
<!-- Ayuda al navegador a priorizar la imagen candidata a LCP -->
<img src="hero.webp" fetchpriority="high" width="1200" height="600" alt="...">
<link rel="preload" as="image" href="hero.webp">INP (Interaction to Next Paint): la métrica que sustituyó al FID
INP mide la capacidad de respuesta de la página ante interacciones del usuario (clics, toques, pulsaciones de teclado) durante toda la vida de la página, no solo la primera interacción. Reemplazó a First Input Delay (FID) precisamente porque FID solo medía el retraso antes de que empezara a procesarse la primera interacción, ignorando por completo cuánto tardaba esa interacción en completarse visualmente, y también ignorando el resto de interacciones que ocurren después de la primera. El umbral "bueno" es 200 milisegundos o menos.
La causa técnica dominante de un INP alto es el bloqueo del hilo principal (main thread): si hay JavaScript ejecutándose de forma continuada (por ejemplo, un script analítico pesado, o un componente que recalcula estado en cada scroll), el navegador no puede procesar la siguiente interacción del usuario hasta que ese JavaScript libera el hilo. La solución técnica no es "reducir JavaScript" en abstracto, sino dividir tareas largas en fragmentos más pequeños que cedan el control al navegador entre uno y otro:
// Antes: una tarea larga que bloquea el hilo principal
procesarMilesDeElementos(lista);
// Después: fragmentada, cede el control entre lotes
function procesarPorLotes(lista, i = 0) {
const lote = lista.slice(i, i + 50);
procesar(lote);
if (i + 50 < lista.length) {
setTimeout(() => procesarPorLotes(lista, i + 50), 0);
}
}CLS (Cumulative Layout Shift): el desplazamiento que no siempre se nota conscientemente
CLS mide la suma de todos los desplazamientos inesperados de elementos visibles durante la vida de la página, expresados como una puntuación sin unidad (no segundos, no píxeles) que combina cuánto se desplaza el contenido y qué fracción del viewport afecta. El umbral "bueno" es 0.1 o menos. La causa más común, y la más fácil de arreglar, son las imágenes sin dimensiones declaradas: si una etiqueta <img> no tiene width y height (o su equivalente en CSS aspect-ratio), el navegador no puede reservar el espacio que va a ocupar antes de descargarla, así que el contenido de alrededor "salta" cuando la imagen termina de cargar.
<!-- Mal: sin dimensiones, el navegador no reserva espacio -->
<img src="producto.webp" alt="Silla nórdica">
<!-- Bien: reserva el espacio exacto antes de cargar la imagen -->
<img src="producto.webp" width="400" height="400" alt="Silla nórdica">Otras causas frecuentes de CLS alto: banners, avisos de cookies o widgets de chat que se insertan dinámicamente por encima del contenido existente sin reservar previamente su espacio; fuentes web que sustituyen a una fuente de sistema tras cargar (FOIT/FOUT), cambiando el tamaño del texto y desplazando todo lo que viene después; y anuncios insertados en contenedores sin altura mínima definida.
Por qué los datos de campo (CrUX) y de laboratorio (Lighthouse) no siempre coinciden
Google usa dos fuentes de datos distintas y es habitual que muestren resultados contradictorios sin que eso signifique un error de medición. Los datos de laboratorio (Lighthouse, PageSpeed Insights en su parte de "auditoría") ejecutan una simulación controlada, una sola vez, en condiciones de red y hardware fijas. Los datos de campo (Chrome User Experience Report, CrUX) son la agregación real de las visitas de usuarios reales de Chrome, con toda la variedad de dispositivos y condiciones de red que eso implica, durante los últimos 28 días. Para el posicionamiento, Google usa exclusivamente los datos de campo (CrUX); los datos de laboratorio son una herramienta de diagnóstico previa, no la fuente que determina el factor de ranking.
Cómo priorizar qué arreglar primero en un diagnóstico real
El orden de prioridad más eficiente no es arreglar la métrica peor en abstracto, sino arreglar primero la causa que afecta a más páginas de la plantilla del sitio: si el LCP falla porque el servidor tarda en responder, ese problema afecta a todas las páginas por igual y su arreglo (caché de servidor, mejor hosting) tiene impacto inmediato en todo el dominio; si el CLS falla solo en páginas con un widget de chat concreto, el arreglo es local a ese componente y no requiere tocar el resto del sitio.
Preguntas frecuentes
¿Los Core Web Vitals son el factor de posicionamiento más importante?
No: Google los describe como una señal entre muchas, con menos peso que la relevancia del contenido para la búsqueda. Su efecto es más decisivo como desempate entre páginas de relevancia similar que como palanca capaz de superar contenido de mayor calidad.
¿Puedo mejorar mi puntuación de Lighthouse sin que mejore el ranking real?
Sí, es un caso frecuente: Lighthouse mide en condiciones controladas de laboratorio, mientras que el factor de ranking usa datos de campo reales (CrUX) de los últimos 28 días. Una mejora de laboratorio tarda en reflejarse en el dato de campo y solo lo hace si se traduce en una mejora real para usuarios reales.
¿El CLS se puede eliminar del todo?
En la práctica, sí, en la inmensa mayoría de casos: la causa casi siempre es identificable (imágenes sin dimensiones, contenido insertado dinámicamente, fuentes web) y solucionable con las técnicas descritas en esta guía, sin necesitar compromisos de diseño significativos.
¿INP se mide igual en móvil y en escritorio?
Se mide con la misma metodología, pero los umbrales de referencia de Google están pensados sobre todo para el rendimiento típico de dispositivos móviles de gama media, que son mucho más limitados en CPU que un ordenador de escritorio; un INP aceptable en escritorio puede no serlo en móvil con el mismo código.
¿Sirve de algo optimizar Core Web Vitals si mi web ya carga rápido a simple vista?
Sí, porque "parece rápido" y "es rápido según las métricas" no siempre coinciden: una página puede parecer cargada visualmente (contenido visible) mientras el hilo principal sigue bloqueado y no responde a clics (INP alto), o mientras elementos siguen desplazándose por debajo del scroll inicial (CLS alto en interacciones posteriores).