Core Web Vitals en 2026: lo que de verdad mueve el ranking

Qué miden hoy las Core Web Vitals

Las Core Web Vitals son tres métricas que describen cómo perciben una página los visitantes reales. Largest Contentful Paint (LCP) mide la carga: cuánto tarda en verse la imagen o el bloque de texto principal. Interaction to Next Paint (INP) mide la respuesta: cuánto tarda la página en reaccionar visiblemente tras un toque, clic o pulsación de tecla. Cumulative Layout Shift (CLS) mide la estabilidad: cuánto se mueve el contenido mientras carga.

Una página aprueba cuando al menos el 75 % de las visitas están en el rango “bueno”: LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0,1 o menos. Móvil y escritorio se evalúan por separado, y el móvil casi siempre es el más difícil.

INP sustituyó a First Input Delay (FID) como Core Web Vital en marzo de 2024. FID solo medía el retraso de la primera interacción; INP tiene en cuenta las interacciones más lentas de toda la visita. Muchos sitios que estaban holgadamente en verde con FID pasaron a ámbar o rojo con INP.

¿Cuánto influyen en el posicionamiento?

Las Core Web Vitals forman parte de las señales de experiencia de página de Google. No pesan más que la relevancia: una página lenta con la mejor respuesta seguirá ganando a una rápida con una respuesta pobre. Importan entre páginas de calidad similar y, sobre todo, en la conversión: los visitantes abandonan las páginas lentas e inestables sea cual sea su posición.

Por eso tratamos las métricas primero como un indicador de negocio y después como un indicador SEO. Las páginas rápidas venden más, reciben más consultas y abaratan el tráfico de pago.

Datos de campo frente a datos de laboratorio

Lighthouse y las puntuaciones de laboratorio de PageSpeed Insights simulan una única visita en un dispositivo limitado. Son útiles para depurar, pero Google posiciona con datos de campo del Chrome User Experience Report (CrUX), recogidos de usuarios reales de Chrome durante 28 días.

Empieza por el informe de Core Web Vitals de Search Console para ver qué grupos de URL fallan y en qué métrica. Después usa PageSpeed Insights para ver los datos de campo de una URL concreta y el panel Performance de Chrome DevTools para encontrar la causa.

Cómo mejorar el LCP

La mayoría de los problemas de LCP vienen de cuatro sitios: una respuesta del servidor lenta, una imagen principal que el navegador descubre tarde, CSS y fuentes que bloquean el renderizado, o una imagen sencillamente demasiado pesada.

• Baja el Time to First Byte por debajo de unos 800 ms: caché de página completa para visitantes anónimos, CDN y consultas de base de datos rápidas.
• No apliques nunca lazy-load a la imagen del LCP. Dale fetchpriority="high" y precárgala si se define en el CSS.
• Sirve AVIF o WebP al tamaño adecuado con srcset y sizes, en lugar de un JPEG enorme.
• Incrusta el CSS crítico y carga el resto sin bloquear; aloja tú las fuentes y usa font-display: swap.

Cómo mejorar el INP

El INP es casi siempre un problema de JavaScript. Cuando el hilo principal está ocupado con una tarea larga —cualquier cosa por encima de 50 ms— el navegador no puede responder al toque del usuario hasta que termina.

Revisa primero los scripts de terceros: chats, mapas de calor, herramientas de test A/B y varios contenedores de etiquetas suelen añadir cientos de milisegundos. Cárgalos tras la interacción o solo en páginas concretas. En tu propio código, mantén pequeños los manejadores de eventos, aplica debounce a los de entrada y divide el trabajo largo en partes para que el navegador pueda pintar entre medias. Un DOM muy grande (varios miles de elementos) también ralentiza cada interacción, algo habitual con los maquetadores visuales.

// Let the browser paint between chunks of heavy work
async function processInChunks(items, handle) {
  for (const item of items) {
    handle(item);
    await new Promise((resolve) => setTimeout(resolve, 0));
  }
}

Cómo mejorar el CLS

• Define siempre width y height (o aspect-ratio) en imágenes, vídeos e iframes.
• Reserva espacio para anuncios, embeds y avisos de cookies en lugar de empujar el contenido cuando cargan.
• Evita insertar banners o avisos encima del contenido una vez renderizada la página.
• Usa fuentes de respaldo con métricas equivalentes (size-adjust) para que el texto no se recoloque cuando llega la fuente web.

Particularidades de Laravel y WordPress

En Laravel, las mejoras rápidas son las cachés de producción (php artisan config:cache, route:cache, view:cache), OPcache, Redis para caché y sesiones, y eager loading para eliminar las consultas N+1 que retrasan el primer byte. Compila los recursos con Vite para minificar y versionar CSS y JavaScript, y lleva a colas el trabajo lento como emails y llamadas a APIs.

En WordPress, la mayoría de los problemas vienen de los plugins. Elimina los que no necesitas, usa una buena caché de página (LiteSpeed Cache funciona muy bien en servidores LiteSpeed), optimiza las imágenes al subirlas, mantén PHP en una versión 8.x con soporte y ten cuidado con los maquetadores pesados.

Mide y después espera

Añade la librería de código abierto web-vitals para enviar valores reales de LCP, INP y CLS a GA4 o a tu propio endpoint, y verás los cambios en días sin esperar a CrUX. El informe de Search Console usa una ventana móvil de 28 días, así que tras una corrección tardarás unas cuatro semanas en ver el estado en verde. Valida allí la corrección cuando lleguen los datos nuevos.

Si quieres una primera visión rápida de tu propio sitio, nuestro comprobador web gratuito detecta respuestas lentas, falta de compresión y otras causas habituales.