Core Web Vitals en 2026: umbrales y qué ha cambiado

Tres métricas, y las mismas tres desde 2024. Largest Contentful Paint debería quedarse en 2,5 segundos o menos, Interaction to Next Paint en 200 milisegundos o menos y Cumulative Layout Shift en 0,1 o menos. Cada una se juzga en el percentil 75 de las cargas reales de página, con móvil y escritorio por separado.

¿Cuáles son los umbrales de Core Web Vitals en 2026?

Salen directamente de las páginas de cada métrica en web.dev, que es donde Google publica las definiciones. Todo se puntúa en el percentil 75 de las cargas de página, así que apruebas cuando tres cuartas partes de tus visitantes reales obtienen un buen resultado, no cuando lo consigue tu portátil.

¿Cambiaron de verdad las Core Web Vitals en 2026?

No. Ni el conjunto de métricas ni un solo umbral. El último cambio estructural fue el 12 de marzo de 2024, cuando Interaction to Next Paint se convirtió en una Core Web Vital estable y First Input Delay quedó retirada, algo que web.dev anunció en su artículo INP becomes a Core Web Vital. Desde entonces el conjunto son tres métricas estables, sin ninguna experimental ni sustituta pendiente anunciada. La propia norma de Google es que las Core Web Vitals estables no cambiarán más de una vez al año, y tanto 2025 como 2026 pasaron sin ninguno.

Lo que sí se movió es la capa de medición. Las notas de versión del Chrome UX Report en Chrome for Developers recogen que las subpartes de imagen de LCP y los tipos de recurso de LCP llegaron a la API de CrUX en enero de 2025, que la dimensión ECT se retiró de BigQuery en esa misma entrega y que el antiguo CrUX Dashboard quedó obsoleto a finales de noviembre de 2025. Por otro lado, el trabajo sobre navegaciones suaves llegó a Chrome 151, lo que permite a las aplicaciones de página única atribuir LCP, INP y CLS a cada cambio de ruta en lugar de a una única vista de página interminable. Esa documentación dice explícitamente que aún está por decidir cómo se reportarán las navegaciones suaves en CrUX, así que todavía no afecta a tus cifras de Search Console.

Si te han dicho que este año ha aterrizado una métrica nueva, pregunta cuál. No la hay.

Cómo arreglar un LCP lento

Casi todo LCP malo es un problema de descubribilidad. La guía de arreglos prioritarios de web.dev pone tres cosas por delante: asegurarte de que el recurso LCP está visible en el HTML de origen en lugar de inyectarlo por script, marcarlo con fetchpriority="high" y recortar el Time to First Byte con una CDN que cachee el propio documento. Más allá de eso, apunta a navegaciones instantáneas con la caché de avance y retroceso o con las reglas de especulación, para que la página siguiente ya esté ahí cuando llegue el clic.

Cómo arreglar un INP alto

INP se descompone en tres partes: el retardo de entrada antes de que se ejecute tu manejador, la duración del procesamiento de ese manejador y el retardo de presentación hasta que se pinta el siguiente fotograma. La puntuación que se reporta es, a grandes rasgos, la peor interacción de la página, ignorando un valor atípico por cada cincuenta interacciones. Los arreglos recomendados son ceder el control a menudo para que las tareas largas dejen de bloquear el hilo principal, enviar menos JavaScript de partida y mantener pequeñas las actualizaciones de renderizado con un DOM modesto y contención CSS. Audita tu gestor de etiquetas. Suele estar ahí.

Cómo arreglar los desplazamientos de diseño

CLS mira la peor ráfaga de desplazamientos, definida como los que ocurren con menos de un segundo entre sí dentro de una ventana de cinco segundos como máximo. Fija un ancho y un alto explícitos o una relación de aspecto en cada imagen e inserción, reserva espacio para todo lo que se inyecte tarde, como banners y barras de consentimiento, mantén la página apta para la caché de avance y retroceso y anima con transform en lugar de con propiedades que fuerzan el cálculo del diseño.

¿Dónde deberías medir las Core Web Vitals?

Datos de campo primero, siempre. Las herramientas de laboratorio sirven para cazar regresiones antes de publicar, y web.dev es tajante: no sustituyen a usuarios reales en dispositivos reales. El Chrome User Experience Report es el conjunto de datos de campo. Tanto PageSpeed Insights como el informe de Core Web Vitals de Search Console beben de él, y la biblioteca de JavaScript web-vitals te da tus propias cifras con mucho menos retraso que una ventana móvil de 28 días. Chrome DevTools y Lighthouse cubren el lado del laboratorio. Usa ambos, pero solo los datos de campo deciden si apruebas.

¿Siguen afectando las Core Web Vitals al posicionamiento en Google?

Google Search Central sigue documentando las Core Web Vitals como parte de la experiencia en la página, describiéndolas como métricas que miden la experiencia real del usuario y diciendo que se alinean con lo que sus sistemas de ranking principales buscan recompensar. Eso es deliberadamente más suave que un factor de posicionamiento. Tómalo como un desempate entre páginas por lo demás comparables, y como algo que afecta claramente a las conversiones haga lo que haga la búsqueda. La misma lógica se aplica al resto de tus cimientos técnicos, que es lo que revisa nuestro verificador de preparación para la IA.

Una cosa que conviene decirle a quien persigue la puntuación perfecta: aprobar los tres umbrales en el percentil 75 es la línea de meta. No hay un nivel extra por encima. Cuando ya estés en verde, la siguiente hora se aprovecha mejor comprobando si los rastreadores pueden llegar siquiera a la página, algo que se resuelve en cinco minutos en tu robots.txt.