Core Web Vitals: qué son y cómo optimizarlas en 2027

Las Core Web Vitals son tres métricas con las que Google mide cómo vive una persona la carga de tu web: LCP (cuánto tarda en salir lo principal), INP (cuánto tarda la página en reaccionar cuando tocas algo) y CLS (cuánto se mueve el contenido mientras carga). Apruebas si el 75 % de las visitas reales se queda en LCP de 2,5 s o menos, INP de 200 ms o menos y CLS de 0,1 o menos. Para optimizarlas hay que saber cuál falla, en qué tipo de página y por qué; abajo tienes las causas típicas de cada una con su arreglo.

Qué son las Core Web Vitals y sus umbrales

Los umbrales los publica Google en web.dev y no han cambiado desde que el INP sustituyó al FID en marzo de 2024. Son los mismos para móvil y escritorio, pero se evalúan por separado.

Métrica	Qué mide	Bueno	A mejorar	Malo
LCP (Largest Contentful Paint)	Cuándo se pinta el elemento más grande de la pantalla inicial, como la foto de portada o un titular	≤ 2,5 s	2,5 a 4 s	> 4 s
INP (Interaction to Next Paint)	Lo que tarda la página en responder visualmente a clics, toques y teclas, durante toda la visita	≤ 200 ms	200 a 500 ms	> 500 ms
CLS (Cumulative Layout Shift)	Los saltos de contenido que nadie ha pedido: el botón que se mueve justo cuando vas a pulsarlo	≤ 0,1	0,1 a 0,25	> 0,25

Dos detalles que mucha gente pasa por alto. Primero, se mira el percentil 75: no la media, sino el valor que cumplen tres de cada cuatro visitas. Si tus usuarios con móviles flojos van mal, arrastran el resultado aunque en tu portátil todo vuele. Segundo, para aprobar hacen falta las tres en verde.

¿Cuentan para posicionar? Google dice en su documentación de Search Central que recomienda tenerlas bien porque encaja con lo que premian sus sistemas de clasificación. Hombre, no esperes subir diez puestos solo por pasar de naranja a verde: si el contenido no responde a lo que se busca, una web rápida no lo arregla.

Datos de campo y de laboratorio: por qué no coinciden

Este es el lío más habitual. Pasas la web por PageSpeed Insights, sale un 92 en verde, y luego Search Console te dice que tienes 300 URL «lentas». Las dos cosas pueden ser verdad a la vez, porque miden cosas distintas.

• Datos de campo: los de personas reales con Chrome, recogidos en el informe CrUX (Chrome User Experience Report). Son los últimos 28 días y son los que cuentan para Google. Salen en el bloque de arriba de PageSpeed Insights, el de los usuarios reales, y en el informe de Core Web Vitals de Search Console.
• Datos de laboratorio: una sola carga simulada con Lighthouse, con un móvil de gama media y una red lenta emulados. Es la nota de 0 a 100. Sirve para encontrar el problema; si apruebas o no, lo deciden los datos de campo.

Ojo con el INP: en laboratorio no existe, porque nadie hace clic durante la prueba. Lo más parecido que da Lighthouse es el TBT (Total Blocking Time), que mide cuánto rato está bloqueado el navegador ejecutando JavaScript. Si el TBT sale alto, lo normal es que el INP de campo también vaya mal.

Y si tu web tiene pocas visitas, es normal que PageSpeed diga que no hay datos suficientes de usuarios reales. Google no publica datos de campo de URL o sitios con poco tráfico de Chrome. En ese caso trabajas con el laboratorio y con lo que midas tú (lo vemos más abajo).

Cómo hacer el test de Core Web Vitals

1. Search Console, menú «Experiencia» → «Métricas web principales» (así se llaman las Core Web Vitals en la versión en español). Te agrupa las URL por problema y por dispositivo, y con eso ya sabes qué plantilla falla, por ejemplo las fichas de producto o las entradas del blog.
2. PageSpeed Insights con una URL de cada grupo. Arriba, campo; abajo, laboratorio con el diagnóstico. Mira la pestaña Móvil primero: es donde casi siempre se suspende.
3. Chrome DevTools, panel «Performance». Al abrirlo te enseña en directo el LCP, el CLS y el INP de lo que vas haciendo en la página, y señala qué elemento es el LCP. Para el INP es lo mejor que hay: haces clic en el menú, en el filtro, en «Añadir al carrito», y ves cuál se pasa de 200 ms.
4. Medirlo con tus visitas, si tienes acceso al código, con la librería web-vitals de Google:

<script type="module">
  import {onLCP, onINP, onCLS} from 'https://unpkg.com/web-vitals@4?module';
  onLCP(console.log);
  onINP(console.log);
  onCLS(console.log);
</script>

En consola verás algo como {name: 'INP', value: 312, rating: 'needs-improvement', …}. En producción, en lugar de console.log mandas el dato a tu analítica.

Cómo mejorar el LCP

Google parte el LCP en cuatro trozos (guía de optimización del LCP): el tiempo hasta el primer byte, el retraso hasta que el navegador empieza a pedir el recurso, lo que tarda en descargarse y lo que tarda en pintarse. Saber cuál pesa más te ahorra probar cosas a ciegas. Estas son las causas que más se ven:

1. La imagen principal lleva lazy loading

Es la chapuza número uno, y la meten muchos temas y plugins sin preguntar. El loading="lazy" hace que el navegador espere a saber dónde cae la imagen antes de pedirla. Para la foto de portada es justo lo contrario de lo que quieres. Quítalo de esa imagen y súbele la prioridad:

<img src="/img/portada-1200.avif"
     srcset="/img/portada-800.avif 800w, /img/portada-1200.avif 1200w"
     sizes="100vw"
     width="1200" height="630"
     fetchpriority="high"
     alt="Taller con el equipo trabajando">

fetchpriority="high" solo en una o dos imágenes por página. Si se lo pones a todas, deja de servir.

2. El navegador encuentra la imagen tarde

Pasa con las imágenes de fondo puestas en CSS (background-image) y con los sliders que montan las fotos con JavaScript. El navegador no las ve al leer el HTML. Arreglo: usa un <img> normal, o avísale pronto con un preload en el <head>:

<link rel="preload" as="image" href="/img/portada-1200.avif" fetchpriority="high">

¿El slider de cinco fotos en la portada te hace falta? Vaya, en móvil acostumbra a ser lo que más LCP cuesta, y casi nadie pasa de la primera foto.

3. La imagen pesa demasiado

Una foto de 2,5 MB sacada del móvil y subida tal cual. Sírvela en AVIF o WebP, al tamaño al que se ve (con srcset para móvil) y comprimida. Si el elemento LCP es un texto, lo que hay que mirar son las fuentes: carga solo los pesos que usas y precárgalas.

4. El servidor tarda en contestar

Si el HTML llega a los 1,5 s, el LCP de 2,5 s es casi imposible. Aquí no hay truco de front que valga: caché de página, mejor hosting o un CDN. Lo tienes explicado a fondo en la guía del TTFB y el tiempo de respuesta del servidor, y si usas WordPress, en la de plugins de caché.

5. CSS y JavaScript que bloquean el pintado

Hojas de estilo enormes en el <head> y scripts sin defer. Mira en la cascada de DevTools qué se descarga antes de que se pinte nada. Los scripts que no hacen falta para lo primero que se ve, con defer; el CSS que no se usa en esa página, fuera.

Cómo mejorar el INP

El INP mide lo peor (casi) de todas las interacciones de la visita. Cuando va mal, el culpable suele ser JavaScript que tiene el hilo principal ocupado justo cuando el usuario toca algo. La documentación del INP lo explica con detalle; en la práctica, mira esto:

• Scripts de terceros: chat en vivo, mapas de calor, píxeles de publicidad, el gestor de etiquetas con veinte etiquetas dentro. Cada uno va a la suya y todos compiten por el mismo hilo. Quita los que nadie consulta y carga los demás después de la interacción o con retraso.
• Manejadores de eventos pesados: el clic en «Filtrar» que recalcula y repinta 400 productos de golpe. Pinta primero la respuesta visible (el botón pulsado, un indicador) y deja el trabajo gordo para después.
• Tareas largas: cualquier bloque de JavaScript de más de 50 ms. Pártelas y cede el turno al navegador entre trozo y trozo.
• Un DOM enorme: menús de mega-navegación con miles de nodos, constructores visuales que anidan div dentro de div. Cada cambio cuesta más de pintar.

Un patrón sencillo para ceder el turno, que funciona en todos los navegadores:

function cederTurno() {
  return new Promise(resolve => setTimeout(resolve, 0));
}

boton.addEventListener('click', async () => {
  boton.classList.add('cargando');   // respuesta visible inmediata
  await cederTurno();                // el navegador pinta aquí
  filtrarProductos();                // el trabajo pesado, después
});

Donde el navegador lo admite, scheduler.yield() hace lo mismo y respeta mejor la prioridad de la tarea.

Cómo mejorar el CLS

El CLS es el más agradecido: suele arreglarse con HTML y CSS, sin tocar el servidor. Las causas típicas (más detalle en web.dev):

Imágenes, vídeos e iframes sin tamaño

Si el navegador no sabe cuánto ocupa una imagen, no le reserva sitio y empuja el texto cuando llega. Pon siempre width y height (el navegador calcula la proporción aunque luego la escales con CSS) o usa aspect-ratio:

.video-embebido { aspect-ratio: 16 / 9; width: 100%; }

Anuncios, avisos de cookies y banners que se insertan arriba

Es el problema de las webs de noticias y los periódicos: el hueco del anuncio se rellena cuando ya estás leyendo y todo baja 250 px. Reserva el espacio con un min-height del tamaño de anuncio más habitual para ese hueco. El aviso de cookies y las barras de promoción, mejor superpuestos (fijos abajo, por ejemplo) que empujando el contenido.

Fuentes web que cambian el texto al cargar

La fuente de reserva y la definitiva no ocupan lo mismo y el párrafo «salta». Precarga la fuente principal y ajusta la de reserva para que mida parecido:

@font-face {
  font-family: 'Titular';
  src: url('/fonts/titular.woff2') format('woff2');
  font-display: swap;
}
@font-face {
  font-family: 'Titular-reserva';
  src: local('Arial');
  size-adjust: 105%;
}
h1 { font-family: 'Titular', 'Titular-reserva', sans-serif; }

Animaciones con propiedades que mueven la maqueta

Animar top, left, height o margin desplaza lo de alrededor. Anima con transform y opacity, que no cuentan para el CLS.

Cómo comprobar que la mejora funciona

Has subido los cambios y en PageSpeed la parte de laboratorio ya sale verde. ¿Ya está? Todavía no. Los datos de campo son una ventana de 28 días, así que la mejora se va notando poco a poco y no se ve entera hasta pasadas unas cuatro semanas.

1. En Search Console, entra en el problema y pulsa «Validar corrección». Google abre un periodo de seguimiento de unos 28 días (así lo explica su ayuda).
2. Mientras, repite la prueba de laboratorio siempre igual: misma URL, mismo dispositivo, a ser posible a la misma hora. Una sola medición varía mogollón; fíate de la tendencia, no de un número suelto.
3. Apunta qué cambiaste y cuándo. Si dentro de dos meses vuelve a empeorar, sabrás desde qué fecha mirar.

Lo que más tumba unas Core Web Vitals ya arregladas son los cambios del día a día: un plugin nuevo, un banner de campaña, el script de una herramienta que alguien de marketing añadió un viernes. Por eso conviene medir cada día y no solo cuando te acuerdas.

Con la monitorización de PageSpeed de WatcherWolf la prueba se lanza sola cada día (móvil en el plan Solo, móvil y escritorio desde Studio, y dos o cuatro veces al día en Agency y Business) y guarda la nota y el desglose de métricas en una gráfica. No te manda un aviso cuando baja la nota: la evolución la ves en el panel y en el informe semanal, y desde el plan Studio el Guardián marca las bajadas que se mantienen frente a lo normal de esa web. Si vas a hacer un despliegue gordo, el Monitor en Directo lanza mediciones seguidas mientras dura para que veas el efecto en el momento.

Mide tus Core Web Vitals cada día: 14 días gratis, sin tarjeta

Si lo que quieres es revisar la velocidad de toda la web de arriba abajo y decidir por dónde empezar, sigue con la guía de auditoría de velocidad web. Y si el LCP se te va por imágenes servidas desde lejos, mira cómo ayuda un CDN.

Preguntas frecuentes

¿Por qué PageSpeed me da buena nota y Search Console dice que mis URL son lentas?

Porque la nota de PageSpeed es una prueba de laboratorio de una sola carga, y Search Console usa datos de usuarios reales de los últimos 28 días. Para Google cuentan los reales: si tus visitas van con móviles lentos o redes flojas, pueden suspender aunque la prueba salga verde.

¿Qué pasó con el FID?

Google lo retiró en marzo de 2024 y lo sustituyó por el INP. El FID solo medía el retraso de la primera interacción; el INP mira todas las de la visita, y por eso muchas webs que aprobaban con FID suspenden con INP.

¿Hace falta sacar un 100 en PageSpeed?

No. La nota de 0 a 100 no es lo que evalúa Google; lo que cuenta es que las tres métricas de campo estén en verde en el percentil 75. Perseguir el 100 cuesta mucho esfuerzo para muy poca diferencia real.

¿Cuánto tarda Google en ver que he mejorado las Core Web Vitals?

Unas cuatro semanas. Los datos de campo son una media móvil de 28 días, así que la mejora entra poco a poco, y la validación de Search Console también dura unos 28 días.

Mi web no tiene datos de campo en PageSpeed, ¿qué hago?

Es normal en webs con poco tráfico de Chrome. Trabaja con la parte de laboratorio, mide el INP a mano en el panel Performance de DevTools y, si puedes, recoge tus propios datos con la librería web-vitals.