Core Web Vitals

¿Qué son las métricas web básicas?

Core Web Vitals reúne un puñado de indicadores pensados para medir tres cosas muy concretas en una web: rapidez, respuesta a la interacción y estabilidad visual.

Estas métricas forman parte del paquete de señales de “experiencia de página” que utiliza Google para valorar la UX (es decir, cómo se siente usar tu sitio).

Si las optimizas, no solo puedes ganar en comodidad para el usuario: también es posible que tu sitio compita mejor en los resultados de búsqueda.

Los tres pilares de Core Web Vitals son:

• Largest Contentful Paint (LCP): calcula cuánto tarda en mostrarse el elemento de contenido más grande de la pantalla. Para una experiencia sólida, el LCP debería quedar por debajo de 2,5 segundos.
• Interaction to Next Paint (INP): refleja lo rápido que responde la web cuando el usuario interactúa. Para que se sienta ágil, el INP debería ser de 200 milisegundos o menos.
• Cumulative Layout Shift (CLS): mide cuánto “salta” el diseño mientras la página termina de cargar. Un CLS por debajo de 0,1 se considera una buena experiencia.

Métricas web esenciales

Puedes ver un resumen de cómo va tu sitio en Core Web Vitals desde la sección “Experiencia” de tu cuenta de Google Search Console.

Si entras en cualquiera de los informes, encontrarás el desglose detallado de cada métrica.

Otra opción es validarlo con herramientas como Google PageSpeed Insights o Semrush Site Audit.

Nota: Con una cuenta gratuita de Semrush puedes analizar hasta 100 URL con Auditoría del Sitio. Sirve para detectar problemas en Core Web Vitals y en otros puntos de SEO técnico. También puedes usar este enlace para acceder a una prueba de 14 días de Semrush Pro.

¿Por qué son importantes los Core Web Vitals?

El desempeño de tu sitio en Core Web Vitals influye tanto en la experiencia del usuario como en tu margen de posicionamiento. La expectativa es clara: una web debe sentirse rápida, estable y agradable de usar.

Y, en general, Google intenta premiar el contenido que ofrece ese tipo de experiencia.

Las señales de experiencia de página de Google se basan en varios factores que consideran relevantes para la UX, por ejemplo:

• HTTPS
• Adaptación a móviles
• Sin intersticiales intrusivos (ventanas emergentes)
• “Navegación segura” (en la práctica: que tu sitio no distribuya malware)

Dentro de ese conjunto, Core Web Vitals ocupa un lugar central.

Eso sí: tener una experiencia de página excelente no te coloca automáticamente en el primer puesto. En una publicación donde se analizaba cómo encajaban Core Web Vitals con otras señales ya existentes, Google recalcó que la experiencia de página no lo es todo. Ten en cuenta que trabajan con cientos de factores para ordenar los resultados.

Buena experiencia de página

Dicho esto, vamos a bajar al terreno práctico: te explico cada una de las tres métricas y qué puedes hacer para mejorarlas.

Largest Contentful Paint (LCP)

LCP captura la velocidad de carga desde la perspectiva de quien visita la página.

En términos más concretos: mide el tiempo que tarda en aparecer el elemento más grande visible en pantalla (por ejemplo, una imagen principal o un bloque amplio de texto).

Puedes consultar tu LCP con PageSpeed Insights.

Es útil, especialmente para detectar cuellos de botella y oportunidades claras de mejora.

Aun así, mi recomendación es que revises el LCP desde tu propiedad de Google Search Console.

¿La razón?

Tanto Search Console como PageSpeed Insights se alimentan del Informe de experiencia del usuario de Chrome. La diferencia es que Search Console te permite ver el LCP a escala de sitio: no vas página por página al azar, sino que obtienes un listado de URLs clasificadas como buenas, regulares o problemáticas.

Sobre ese punto, Google publica guías específicas para LCP. Divide el rendimiento en tres grupos: Buena, Necesita mejorar y Mala. (Esa misma lógica se aplica a las tres Core Web Vitals, aunque los umbrales cambian según la métrica).

Las pautas de pintura con contenido más grandes de Google

La idea práctica es simple: que cada URL cargue el LCP en 2,5 segundos.

En páginas con muchas funciones o con imágenes pesadas en la parte superior esto puede volverse complicado. Y si además colocas una imagen destacada de alta resolución al inicio, el reto se multiplica.

Nota: No conviertas Core Web Vitals en una obsesión numérica. Antes que una puntuación, prioriza la calidad del contenido y una experiencia realmente buena.

Acciones que suelen ayudar a recortar el LCP:

• Quita scripts de terceros que no sean imprescindibles: nuestro estudio de velocidad de página encontró que cada script externo ralentizaba una página en 34 ms.
• Mejora tu hosting: un proveedor más sólido tiende a reducir tiempos de carga en general (incluido el LCP).
• No apliques carga diferida a imágenes por encima del pliegue: el lazy loading puede ser útil, pero en la zona visible inicial puede terminar empeorando el LCP.
• Reduce elementos grandes en el “above the fold”: eliminar imágenes innecesarias y componentes pesados en la parte superior suele acelerar el LCP.
• Compacta tu CSS: hojas de estilo infladas pueden retrasar notablemente el LCP.

Interaction to Next Paint (INP)

Pasemos al segundo Core Web Vital: Interaction to Next Paint.

INP registra cuánto tarda el navegador en reaccionar ante la siguiente interacción del usuario con la página (un clic o un toque, por ejemplo) una vez que la página ya terminó de cargar.

Este indicador se parece al First Input Delay (FID), al que INP sustituyó en 2024. La diferencia es importante: INP pone el foco en la respuesta del sitio después de la carga inicial, lo que lo convierte en una señal más fiable de la capacidad de respuesta global.

Ejemplos típicos de interacción:

• Seleccionar una opción en un menú
• Pulsar un botón para enviar el correo en un formulario
• Abrir el menú de navegación en móvil

Y, igual que con LCP, Google define rangos concretos para interpretar INP.

Directrices de interacción de Google con Next Paint

Lo ideal es que INP se mantenga en 200 ms o menos. Si supera ese valor, hace falta optimizar. Y si pasa de 500 ms, se considera un rendimiento deficiente.

En páginas puramente informativas (una entrada de blog o una noticia), INP suele dar menos guerra. La interacción principal es hacer scroll o pellizcar para zoom; y esos gestos no cuentan para medir INP.

Eso sí: menús rápidos, botones que responden y formularios fluidos siguen importando.

Donde INP se vuelve decisivo es en páginas en las que el usuario necesita actuar con rapidez: login, registro o cualquier flujo donde se clickea mucho (por ejemplo, añadir un producto al carrito). En esos casos, INP es ENORME.

Piensa, por ejemplo, en la experiencia de una pantalla como esta:

Pantalla de inicio de sesión de Reddit

En un login así, el tiempo de carga del contenido pesa menos (no hay gran cosa que mostrar). Lo que manda es lo rápido que puedes empezar a escribir y lo inmediato que responde el botón de “Iniciar sesión”.

Con ese contexto, aquí tienes palancas habituales para mejorar el INP:

• Reducir (o diferir) JavaScript: mientras el navegador está ocupado cargando JS, la interacción se resiente. Minimizar o aplazar JS en la página es clave para INP.
• Eliminar scripts externos no esenciales: como en LCP, terceros (Google Analytics, mapas de calor, etc.) pueden empeorar INP. Si vas pasado de tiempo, recorta lo que no sea vital.
• Posponer la ejecución y trocear tareas largas: dividir procesos pesados en partes más pequeñas puede ayudar. Probablemente necesites apoyo de tu desarrollador para aplicarlo bien.

Cumulative Layout Shift (CLS)

El Cambio de diseño acumulativo (CLS) indica cuán estable permanece una página mientras carga (lo que también se conoce como “estabilidad visual”).

Dicho de otra forma: si los elementos se mueven cuando la web está terminando de renderizar, lo normal es que tu CLS salga alto. Y eso no es buena señal.

Ejemplo de cambio de diseño acumulativo

Lo que buscas es que la composición se mantenga firme mientras aparece el contenido.

¿Por qué importa tanto?

Imagina que alguien entra en la página de tu tienda. Ve un botón para ampliar información de un producto. Justo cuando va a pulsarlo, aparece un banner arriba, empuja todo hacia abajo y, sin querer, el usuario acaba tocando “comprar ahora”.

Eso es una mala experiencia.

Google también fija umbrales claros para CLS:

Directrices de cambio de diseño acumulativo de Google

El objetivo es 0,1 o menos. Entre 0,1 y 0,25 entra en “necesita mejorar”, y por encima de eso se considera deficiente.

Como ves, es un punto que tengo que ajustar, sobre todo en móvil.

Tema clave: Elementos esenciales de la web

Medidas sencillas para bajar CLS:

• Define dimensiones (atributo de tamaño) en medios como imágenes y vídeos: así el navegador reserva el espacio exacto desde el inicio y no tiene que recolocar elementos mientras termina de cargar.
• Reserva espacio para anuncios: si no hay hueco asignado, el anuncio puede “aparecer” de golpe y desplazar el contenido hacia arriba, abajo o a los lados.
• No insertes contenido dinámico nuevo en la parte superior: banners que se cargan arriba suelen empujar todo hacia abajo. Si puedes, coloca esos elementos en la parte inferior de la página.