Core Web Vitals en 2026: guía práctica para aprobar las métricas de Google

Los Core Web Vitals son las tres métricas con las que Google resume la experiencia de usuario de una web: velocidad de carga, capacidad de respuesta y estabilidad visual. Desde que forman parte de las señales de ranking, aprobar estas métricas dejó de ser un detalle técnico para convertirse en una cuestión de visibilidad. Esta es nuestra guía práctica para 2026, la misma que aplicamos en cada proyecto.

Por qué importan más de lo que parece

Conviene poner las Core Web Vitals en su sitio. No son el factor más importante del posicionamiento —el contenido relevante y la autoridad del dominio mandan—, pero sí una línea base obligatoria para competir arriba. Se estima que pesan en torno a un 10-15% del conjunto del algoritmo, y su papel real es el de desempate: cuando dos resultados tienen relevancia parecida, Google premia al que ofrece mejor experiencia.

El efecto más grande, sin embargo, ocurre después del clic. Una web que se ve rápido, responde al instante y no baila mientras carga retiene a quien la visita; una lenta, espasmódica o inestable lo expulsa hacia la competencia. Por eso los Core Web Vitals son a la vez una palanca de SEO y una palanca de conversión: mejoran tanto cómo te encuentra Google como qué hace el usuario una vez dentro.

Un matiz importante para 2026: las correcciones no son inmediatas. Google evalúa los datos de campo en una ventana móvil de 28 días, así que un arreglo desplegado hoy tarda aproximadamente un mes en reflejarse del todo en Search Console. Esto hace que prevenir las regresiones antes de publicar valga más que apagar fuegos después.

Las tres métricas, explicadas

Google clasifica cada métrica en tres niveles —"bueno", "necesita mejora" y "pobre"— y para aprobar hay que quedar en "bueno" en el percentil 75 de los usuarios reales. Es decir: no basta con que vaya rápido para ti; tiene que ir rápido para el 75% de quien te visita, incluido el que entra con un móvil modesto y una conexión regular.

Métrica	Qué mide	Bueno	Necesita mejora	Pobre	Webs que aprueban
LCP	Velocidad de carga percibida	≤ 2,5 s	2,5 – 4 s	> 4 s	~68%
INP	Capacidad de respuesta	≤ 200 ms	200 – 500 ms	> 500 ms	~57%
CLS	Estabilidad visual	≤ 0,1	0,1 – 0,25	> 0,25	~78%

Esa última columna cuenta una historia: el CLS es el más fácil de aprobar porque se arregla con CSS predecible, mientras que el INP es el gran reto de la década —más del 40% de la web lo suspende— porque depende de la cantidad de JavaScript que carga cada página.

LCP — Largest Contentful Paint

Mide cuánto tarda en pintarse el elemento más grande visible sin hacer scroll, que en la mayoría de los casos (un 72% de las veces) es una imagen, y el resto, un titular destacado o un fondo. Es la métrica de "cuándo veo algo útil".

INP — Interaction to Next Paint

Sustituyó a FID como métrica de interactividad en marzo de 2024, y el cambio fue a mejor: FID solo medía la primera interacción y se quedaba ciego a partir de ahí. El INP, en cambio, vigila cada clic, toque y pulsación durante toda la visita, y se queda con la respuesta más lenta. Un INP alto se percibe como una web "que se atasca" al filtrar productos, abrir menús o enviar formularios.

CLS — Cumulative Layout Shift

Mide los saltos de diseño durante la carga: ese banner que aparece de pronto y te hace pulsar donde no querías. Se calcula acumulando cuánto se desplaza el contenido visible mientras la página termina de montarse.

Las optimizaciones con más impacto

Para mejorar el LCP

El LCP rara vez falla por un solo motivo: es una cadena de pequeñas demoras que se suman. Se ataca por capas, de la red al navegador:

1. Reduce el TTFB (tiempo hasta el primer byte). Es el cimiento: si tu servidor tarda 800 ms en responder, el LCP ya nace con casi un segundo de retraso antes de descargar nada. La solución es servir desde un CDN distribuido, con renderizado en servidor (SSR) o, mejor aún, generación estática (SSG).

2. Optimiza la imagen del hero. Formato WebP o AVIF (pesan entre un 30% y un 50% menos que un JPEG), dimensiones ajustadas a cada pantalla con srcset y el elemento <picture>, y precarga prioritaria en el <head>:

   <link rel="preload" as="image" href="/images/hero.webp"
         type="image/webp" fetchpriority="high" />
   

   Esa precarga sola suele ahorrar entre 200 y 800 ms.

3. Nunca apliques loading="lazy" a la imagen del LCP. Diferir la carga del elemento más importante de la pantalla es un error clásico: le estás pidiendo al navegador que retrase justo lo que el usuario espera ver primero.

4. Si el LCP es texto, cuida las fuentes. Precarga la fuente crítica, alójala en tu propio dominio (evita la latencia de Google Fonts) y usa font-display: swap para que el texto aparezca al instante con una tipografía del sistema mientras carga la definitiva.

Para mejorar el INP

El INP se descompone en tres fases, y cada una se optimiza distinto:

• Retraso de entrada: el tiempo que el hilo principal está ocupado y no puede atender tu clic. Lo causan las tareas largas —un chat de terceros inicializándose, scripts de analítica, la hidratación de frameworks pesados.
• Tiempo de procesamiento: lo que cuesta ejecutar el código que responde a la interacción.
• Retraso de presentación: lo que tarda el navegador en pintar el resultado en pantalla.

Las tres se reducen con la misma receta de fondo: menos JavaScript y trabajo troceado.

1. Carga menos JavaScript. Cada kilobyte se descarga, se parsea y se ejecuta. Audita tus librerías y elimina lo que no uses.

2. Trocea las tareas largas. Cualquier operación que bloquee el hilo principal más de 50 ms se nota en cada pulsación. En 2026 la herramienta clave para esto es la API scheduler.yield(), que pausa un cálculo pesado para atender al usuario y luego lo retoma donde lo dejó:

   async function procesarEnFragmentos() {
     ejecutarBloque();          // primera parte del trabajo pesado
     await scheduler.yield();   // cede el hilo: atiende clics pendientes
     ejecutarBloque();          // retoma el resto con prioridad
   }
   

3. Vigila los scripts de terceros. Chats, mapas y píxeles de seguimiento son los sospechosos habituales. Cárgalos en diferido o bajo demanda.

Para mejorar el CLS

1. Reserva espacio para imágenes y vídeos con width y height (o la propiedad CSS aspect-ratio). Sin dimensiones, el navegador asume cero y luego empuja todo hacia abajo al cargar.
2. Reserva hueco para anuncios, embeds y banners de cookies con min-height y contain: layout, o sácalos del flujo con posición fija. Son la causa más infravalorada de saltos.
3. Evita el "salto de fuente". Usar font-display: swap protege el LCP, pero al cambiar de la fuente del sistema a la definitiva el texto puede reacomodarse. Se corrige ajustando los descriptores size-adjust, ascent-override y descent-override en el @font-face para que la fuente de respaldo ocupe casi lo mismo que la final.

Datos de campo vs. datos de laboratorio

Esta distinción es la que más confusión genera, y entenderla te ahorra optimizar lo que no puntúa:

• Datos de laboratorio (Lighthouse, la pestaña de "diagnóstico" de PageSpeed): se generan en un entorno simulado, con una red y un dispositivo fijos. No influyen en el ranking. Sirven para depurar rápido y para poner barreras en cada build que impidan publicar una regresión.
• Datos de campo (CrUX, el Informe de Experiencia de Usuario de Chrome): son las visitas reales de los últimos 28 días, con sus móviles y conexiones de verdad. Estos son los que Google usa para posicionar.

De ahí una trampa habitual: una página puede aprobar en PageSpeed pero suspender en Search Console. PageSpeed mira una URL concreta, mientras que Search Console agrupa páginas con la misma plantilla; si el resto de fichas de tu tienda va lento, esa media arrastra a la página que mirabas. Por eso lo serio es medir usuarios reales (lo que se llama RUM, Real User Monitoring) con la librería oficial web-vitals, que además te dice qué elemento exacto rompió la métrica en cada sesión.

Novedades de 2026

El terreno se mueve rápido. Tres avances que ya usamos o vigilamos de cerca:

• Speculation Rules API. Permite pre-renderizar en segundo plano la página que el usuario probablemente visitará a continuación. Cuando hace clic, la transición es prácticamente instantánea: en datos reales, baja el LCP de los enlaces preparados muy por debajo del umbral. Reemplaza a los antiguos prefetch y prerender.
• Long Animation Frames (LoAF). Disponible desde Chrome 123, esta API señala los fotogramas que tardan más de 50 ms y, a diferencia de la antigua API de tareas largas, te dice por qué: qué script concreto bloqueó el hilo. Es la herramienta que faltaba para diagnosticar INP en producción.
• Chrome DevTools renovado. El panel de rendimiento muestra ahora las métricas en vivo mientras navegas, y un panel de insights traduce los diagramas técnicos en recomendaciones legibles ("un script de terceros está retrasando el LCP").

El caso de WordPress y otros CMS

Buena parte de la web vive sobre WordPress, y ahí los suspensos son frecuentes: plugins que cargan JavaScript en todas las páginas, plantillas recargadas y consultas pesadas a la base de datos. La buena noticia es que casi siempre hay mucho margen sin rehacer la web:

• Caché de página y de objetos con una herramienta como WP Rocket, que minifica, difiere scripts y resuelve buena parte de las patologías comunes sin tocar código.
• Optimización de imágenes por lotes con un plugin como Imagify, que reescala y convierte a WebP/AVIF de forma automática.
• Auto-alojar las fuentes para eliminar la latencia de Google Fonts y los saltos de CLS.
• Un CDN como Cloudflare delante de todo, que distribuye los archivos estáticos cerca del usuario y derriba el TTFB.
• Limpieza de la base de datos (tablas y registros transitorios huérfanos) para acelerar las consultas.

Si después de todo esto la web sigue suspendiendo, es señal de que el problema es estructural y toca plantearse una arquitectura distinta. Lo desarrollamos en nuestra comparativa Next.js vs WordPress.

Cómo lo medimos en yuGraphik

Trabajamos con tres niveles de medición: PageSpeed Insights para el diagnóstico inicial, Lighthouse en cada build para detectar regresiones antes de publicar, y el informe de Core Web Vitals de Search Console para vigilar los datos de usuarios reales mes a mes. En proyectos exigentes añadimos monitorización RUM propia para saber, métrica a métrica, qué elemento concreto conviene tocar.

Nuestra arquitectura por defecto —webs estáticas generadas con Next.js y servidas desde CDN con caché agresiva— aprueba las tres métricas de serie en la inmensa mayoría de los casos: no hay servidor que tarde en responder, ni base de datos que se sature, ni JavaScript que no se necesite. Puedes ver el enfoque funcionando en nuestros proyectos, y si quieres que auditemos el tuyo, está dentro de nuestro servicio de desarrollo web.

Conclusión

Los Core Web Vitals no son una moda de Google: son la traducción a números de algo que tus visitantes sienten en cada visita. Diagnostica tu web (es gratis y tarda un minuto), prioriza las optimizaciones de esta guía —empezando por las imágenes y el JavaScript, que es donde están la mayoría de los suspensos— y recuerda que las mejoras tardan unas semanas en consolidarse en los datos de campo. Si tu plataforma actual no da más de sí, plantéate una arquitectura pensada para el rendimiento desde la primera línea de código.