Core Web Vitals explicados: LCP, INP y CLS

Los Core Web Vitals son tres métricas definidas por Google para evaluar la experiencia real de un visitante en una página web: el LCP mide la rapidez con la que se muestra el contenido principal, el INP mide la capacidad de respuesta ante las interacciones, y el CLS mide la estabilidad visual durante la carga. Se miden de forma gratuita con PageSpeed Insights o Search Console.

El verdadero problema: puntuaciones técnicas que nadie sabe interpretar

Muchos propietarios de sitios web ya han visto estas siglas, LCP, INP, CLS, aparecer en un informe de PageSpeed Insights o en Google Search Console, sin saber realmente qué miden ni por qué importan. El reflejo habitual es tratar estas métricas como un examen técnico abstracto que hay que aprobar, una puntuación que hay que subir sin entender su significado.

Sin embargo, los Core Web Vitals no miden una proeza técnica en sí misma: miden, de forma indirecta pero bastante fiel, lo que realmente siente un visitante al usar el sitio. Una mala puntuación corresponde casi siempre a una experiencia concreta y desagradable: una página que tarda en mostrar su contenido, un botón que no responde de inmediato al clic, o un diseño que salta justo cuando el usuario iba a hacer clic en otra cosa. Entender esto cambia la forma de abordar estas métricas: no son una casilla que marcar para Google, reflejan una experiencia de usuario.

LCP: la rapidez con la que se muestra el contenido principal

El LCP (Largest Contentful Paint) mide el tiempo necesario para que el elemento más grande visible en la zona de pantalla inicial (a menudo una imagen, un título o un bloque de texto importante) se muestre por completo en pantalla. No es el tiempo total de carga de la página, sino el momento en que el usuario ve aparecer lo que constituye, visualmente, el núcleo del contenido.

Un LCP lento da la impresión de un sitio que tarda en "arrancar": la página parece vacía o incompleta durante varios segundos antes de que aparezca el elemento principal. Suele ser la primera impresión que se lleva un visitante sobre el rendimiento de un sitio.

Causas técnicas frecuentes de un mal LCP:

• Imágenes no optimizadas o demasiado pesadas usadas como elemento principal (banner, foto de producto).
• Tiempo de respuesta del servidor demasiado largo antes de que el navegador reciba el primer contenido.
• Recursos bloqueantes (CSS o JavaScript voluminosos) cargados antes de mostrar el contenido principal.
• Ausencia de precarga para los recursos críticos (como una imagen en la parte superior de la página).

INP: la capacidad de respuesta ante las interacciones

El INP (Interaction to Next Paint) mide la capacidad de respuesta de una página ante las acciones del usuario: un clic, un tap en móvil, una pulsación de teclado. En concreto, evalúa el retraso entre el momento en que el usuario interactúa y el momento en que la página responde visualmente a esa acción, observando el conjunto de interacciones realizadas durante la visita, no solo la primera.

El INP sustituyó a una métrica más antigua, el FID (First Input Delay), que solo medía el retraso antes de la primerísima interacción del usuario con la página. Esa limitación planteaba un problema: un sitio podía responder bien a la primera interacción y luego volverse lento en las siguientes, sin que el FID lo detectara. El INP, al observar todo el recorrido de interacción, ofrece una imagen más fiel de la experiencia real.

Causas técnicas frecuentes de un mal INP:

• JavaScript demasiado pesado o mal optimizado que bloquea el hilo principal del navegador.
• Demasiados scripts de terceros ejecutándose a la vez (chat, publicidad, herramientas de seguimiento).
• Procesos complejos que se disparan directamente al hacer clic, sin dividirse en tareas más ligeras.
• Componentes de la interfaz que recalculan innecesariamente toda la página en cada interacción.

CLS: la estabilidad visual durante la carga

El CLS (Cumulative Layout Shift) mide los desplazamientos inesperados de elementos visibles durante la carga de una página. Es el fenómeno bien conocido en el que un visitante está a punto de hacer clic en un botón o enlace, y un elemento que acaba de cargarse (a menudo una imagen, un anuncio o una fuente tipográfica) empuja todo el contenido hacia abajo, provocando un clic sobre el elemento equivocado.

Este desplazamiento no es solo molesto, puede tener consecuencias directas: un clic accidental en un anuncio, un formulario rellenado en el campo equivocado, o simplemente la impresión de un sitio mal acabado que incita a abandonar la página.

Causas técnicas frecuentes de un mal CLS:

• Imágenes o vídeos sin dimensiones definidas de antemano en el código, que desplazan el contenido al cargarse.
• Anuncios o widgets de terceros insertados dinámicamente sin espacio reservado.
• Fuentes personalizadas que sustituyen a una fuente por defecto con un tamaño diferente, desplazando el texto.
• Contenido inyectado dinámicamente en la parte superior de la página (banner, notificación) sin espacio previsto de antemano.

Por qué existen estas métricas: la experiencia real, no el rendimiento abstracto

Es fácil percibir los Core Web Vitals como un simple criterio técnico de posicionamiento. Su origen es en realidad distinto: Google los introdujo para cuantificar de forma objetiva aspectos de la experiencia de usuario que antes eran difíciles de medir de manera estandarizada a gran escala.

Un sitio podía ser rápido según criterios antiguos (tiempo de carga total) y a la vez ofrecer una experiencia frustrante: contenido que aparece a trompicones, interacciones que no responden, un diseño que salta. Los Core Web Vitals buscan capturar estas frustraciones concretas en lugar de una única medida global de velocidad, que a menudo ocultaba estos problemas.

Cómo medir los Core Web Vitals

Existen dos categorías de datos, y conviene distinguirlas:

PageSpeed Insights combina ambos: muestra los datos de campo si el sitio recibe suficiente tráfico para aparecer en el CrUX, además de un análisis de laboratorio sistemático con recomendaciones técnicas detalladas. Google Search Console ofrece un informe de "Métricas web esenciales" que agrupa las páginas del sitio por estado (bueno, mejorable, deficiente) basándose en datos de campo reales.

En cuanto a los umbrales exactos que hay que alcanzar en cada métrica, Google publica valores de referencia que actualiza con regularidad a medida que evolucionan los usos y los estándares. En lugar de fiarse de una cifra fija encontrada en un artículo, es mejor consultar directamente PageSpeed Insights, que muestra los umbrales vigentes en el momento de la prueba y sitúa su sitio en relación con ellos.

Lo que hay que recordar

• El LCP mide la rapidez con la que se muestra el contenido principal, el INP la capacidad de respuesta ante las interacciones, el CLS la estabilidad visual durante la carga.
• Estas métricas traducen una experiencia de usuario concreta, no solo un rendimiento técnico abstracto.
• El INP sustituyó al FID para reflejar mejor la capacidad de respuesta a lo largo de toda una visita, no solo en el primer clic.
• Las causas técnicas más frecuentes tienen que ver con imágenes no optimizadas, JavaScript pesado y elementos sin dimensiones reservadas.
• Los umbrales exactos cambian con regularidad: consulte PageSpeed Insights en lugar de una cifra desactualizada encontrada en otro sitio.
• Los datos de campo (reales) y de laboratorio (simulados) son complementarios para diagnosticar y hacer seguimiento de un sitio.

Preguntas frecuentes

¿Cuáles son los tres Core Web Vitals? El LCP mide el tiempo que tarda en mostrarse el elemento más grande visible en pantalla, el INP mide la capacidad de respuesta del sitio ante las interacciones del usuario (clics, taps), y el CLS mide la estabilidad visual, es decir, si los elementos de la página se mueven de forma inesperada durante la carga.

¿Cuáles son los umbrales que hay que alcanzar para cada métrica? Google publica umbrales de referencia para cada métrica, pero se actualizan con regularidad y no deben considerarse fijos. La forma más fiable de consultarlos es analizar su sitio con PageSpeed Insights, que muestra los umbrales vigentes en el momento de la prueba.

¿Por qué el INP sustituyó al FID? El FID (First Input Delay) solo medía el retraso antes de la primera interacción. El INP evalúa la capacidad de respuesta a lo largo de toda la visita, lo que refleja mejor la experiencia real de un usuario que interactúa varias veces con una página, no solo a su llegada.

¿Cuál es la diferencia entre los datos de campo y los datos de laboratorio? Los datos de campo (procedentes del CrUX, Chrome User Experience Report) provienen de visitantes reales que usaron Chrome en el sitio. Los datos de laboratorio proceden de una prueba simulada en condiciones controladas. Ambos son complementarios: el campo refleja la realidad, el laboratorio permite diagnosticar antes de publicar.

¿Son los Core Web Vitals un factor de posicionamiento en Google? Sí, Google los integra en sus señales de posicionamiento relacionadas con la experiencia de página, pero son solo un factor entre otros muchos, junto con la relevancia del contenido y numerosos criterios adicionales. Una buena puntuación por sí sola no basta para posicionarse bien.

En resumen

Entender el LCP, el INP y el CLS permite diagnosticar problemas concretos en lugar de sufrir una puntuación incomprendida. Si su sitio acumula señales de "mejorable" o "deficiente" en estas tres métricas, VeryAppi diseña sitios web pensados desde el principio para limitar estos problemas técnicos, en lugar de corregirlos a posteriori.