Core Web Vitals 2026: Guia Completa de LCP, CLS e INP

Un e-commerce que perdía 2.300 euros al día sin saberlo

El director de marketing de una tienda online de moda en Madrid llevaba meses culpando a la competencia de la caída en ventas. El tráfico orgánico se mantenía estable, los anuncios seguían trayendo visitas, el catálogo se actualizaba cada semana. Pero la tasa de conversión en móvil había caído un 22% en seis meses y nadie entendía por qué. No era un problema de producto ni de precio. Era un problema de experiencia: las páginas de producto tardaban 4,7 segundos en mostrar la imagen principal, los banners promocionales empujaban el botón de compra hacia abajo mientras la página cargaba, y cada interacción con los filtros de talla congelaba el navegador durante 380 milisegundos.

Esos tres síntomas tienen nombre técnico: LCP de 4,7 segundos (el umbral de Google es 2,5), CLS de 0,28 (el umbral es 0,1) e INP de 380 ms (el umbral es 200). Son las tres métricas que conforman los Core Web Vitals, y en 2026 siguen siendo uno de los factores que Google evalúa para decidir qué páginas merecen visibilidad en los resultados de búsqueda.

Esta guía desglosa cada métrica con datos actualizados, explica cómo medirlas correctamente, compara benchmarks reales por sector y propone una hoja de ruta de 90 días para llevar tus métricas al rango que Google considera “bueno”. Si tu sitio web genera ingresos, los Core Web Vitals no son un tema técnico opcional: son un factor de negocio cuantificable.

Cómo medir tus Core Web Vitals: herramientas gratuitas y de pago

Antes de optimizar cualquier métrica, necesitas saber exactamente dónde estás. Y aquí existe una distinción que muchos equipos ignoran: los datos de laboratorio y los datos de campo miden cosas fundamentalmente diferentes, y Google solo usa una de las dos fuentes para el ranking.

Datos de campo vs. datos de laboratorio

Los datos de campo (también llamados RUM, Real User Monitoring) provienen de usuarios reales que visitan tu sitio con Chrome. Google recopila estas métricas a través del Chrome User Experience Report (CrUX) y las muestra en PageSpeed Insights, Search Console y BigQuery. Son estos datos —no los de laboratorio— los que determinan si tu sitio supera los umbrales de Core Web Vitals a efectos de ranking.

Los datos de laboratorio simulan una carga en condiciones controladas: un dispositivo emulado, una conexión de red predefinida, sin extensiones ni caché. Lighthouse, WebPageTest y el modo Lab de PageSpeed Insights generan datos de laboratorio. Son herramientas de diagnóstico imprescindibles para identificar causas específicas, pero no representan lo que experimentan tus usuarios reales.

Según Annie Sullivan, ingeniera del equipo de Chrome Performance, “los datos de campo y los datos de laboratorio miden cosas diferentes. Un sitio puede pasar todas las auditorías de Lighthouse y seguir teniendo malas métricas de campo porque sus usuarios reales están en dispositivos Android de gama baja con 3G.”

Herramientas gratuitas

Google Search Console ofrece el informe de Core Web Vitals con datos de campo agrupados por estado (bueno, necesita mejora, deficiente) y por tipo de URL. Es el punto de partida obligatorio porque muestra exactamente cómo ve Google tu rendimiento.

PageSpeed Insights combina datos de campo (CrUX) y datos de laboratorio (Lighthouse) en una sola interfaz. La sección superior muestra los datos de campo con el veredicto real; la sección inferior detalla las oportunidades de mejora con diagnósticos de laboratorio.

Chrome DevTools Performance Panel permite grabar interacciones en tiempo real y analizar el desglose de cada métrica hasta el nivel de trazas individuales. Es la herramienta más potente para diagnosticar problemas de INP.

Web Vitals Extension para Chrome muestra las métricas en tiempo real mientras navegas por cualquier sitio, superpuestas en la esquina de la pantalla.

Herramientas de pago

Calibre, SpeedCurve y DebugBear ofrecen monitorización continua con alertas, tendencias históricas y segmentación por dispositivo, país y tipo de página. Para sitios con miles de URLs, estas herramientas permiten identificar patrones que las herramientas puntuales no detectan.

CrUX Dashboard (gratuito, basado en Google Data Studio y BigQuery) permite crear paneles personalizados con datos de campo históricos, segmentados por origen y tipo de conexión. Es la opción más potente sin coste, aunque requiere conocimientos de SQL básico.

HTTPArchive publica datos globales de Core Web Vitals que permiten contextualizar tus métricas frente al rendimiento general de la web. Según su informe de 2025, solo el 42% de los sitios web superan simultáneamente los umbrales de las tres métricas Core Web Vitals.

Qué son los Core Web Vitals y por qué Google los usa como ranking

Los Core Web Vitals son un conjunto de tres métricas que cuantifican aspectos concretos de la experiencia del usuario en una página web: velocidad de carga visual, estabilidad del diseño durante la carga y capacidad de respuesta ante interacciones. Google las introdujo en mayo de 2020 y las convirtió en señal de ranking en junio de 2021 como parte del “page experience update”.

La documentación oficial de Google en web.dev lo explica con precisión: “Web Vitals es una iniciativa de Google para proporcionar una guía unificada de las señales de calidad que son esenciales para ofrecer una gran experiencia de usuario en la web.” No son métricas arbitrarias, sino indicadores seleccionados porque correlacionan directamente con el comportamiento del usuario: abandono, conversión y satisfacción.

En 2026, las tres métricas Core Web Vitals son:

• LCP (Largest Contentful Paint): mide la velocidad de carga percibida. Umbral bueno: < 2,5 segundos.
• CLS (Cumulative Layout Shift): mide la estabilidad visual. Umbral bueno: < 0,1.
• INP (Interaction to Next Paint): mide la capacidad de respuesta. Umbral bueno: < 200 ms.

Estas tres métricas no operan de forma aislada. Google evalúa la experiencia de página como un conjunto de señales que incluye los Core Web Vitals junto con HTTPS, ausencia de intersticiales intrusivos y compatibilidad móvil. Pero los Core Web Vitals son la única parte de esa ecuación que requiere medición continua con datos de campo reales.

La pregunta que los equipos de marketing deben responder no es “¿los Core Web Vitals son importantes?” sino “¿cuánto dinero estamos dejando de ganar por no optimizarlos?”. Los datos del caso Rakuten lo cuantifican: un 33% más de conversiones y un 53% más de ingresos por visitante. Esas cifras no son excepcionales. Son representativas de lo que ocurre cuando un sitio pasa de “deficiente” a “bueno” en las tres métricas.

Para una visión más amplia de cómo los Core Web Vitals se enmarcan dentro de la estrategia técnica general, consulta nuestra guía sobre velocidad web y SEO.

INP (Interaction to Next Paint): la métrica que sustituyó a FID

En marzo de 2024, Google reemplazó FID (First Input Delay) por INP (Interaction to Next Paint) como la métrica oficial de capacidad de respuesta dentro de los Core Web Vitals. Este cambio no fue cosmético: representó una evolución fundamental en cómo Google evalúa la interactividad de una página.

Por qué Google descartó FID

FID solo medía el retraso de la primera interacción del usuario con la página. Si el usuario hacía clic en un botón durante la carga inicial y el navegador tardaba 300 ms en responder, FID registraba 300 ms. Pero si todas las interacciones posteriores —scroll, clics en menús, envíos de formularios— también eran lentas, FID no las captaba. Un sitio podía tener un FID excelente y una experiencia de interactividad terrible.

INP corrige esa limitación. Mide la latencia de todas las interacciones del usuario durante toda la visita y reporta el percentil 98 (técnicamente, la peor interacción excluyendo outliers extremos). Esto significa que INP refleja la experiencia real de interactividad completa, no solo el primer contacto.

Umbrales y diagnóstico

• Bueno: INP < 200 ms
• Necesita mejora: INP entre 200 y 500 ms
• Deficiente: INP > 500 ms

Según los datos de HTTPArchive, INP es la métrica donde más sitios fallan. Mientras que aproximadamente el 80% de los sitios pasan el umbral de LCP y el 75% pasan CLS, solo el 65% superan el umbral de INP. La razón es estructural: durante años, los equipos de desarrollo priorizaron la velocidad de carga inicial (optimizar LCP) y la estabilidad visual (evitar CLS) sin prestar atención a la latencia de las interacciones posteriores a la carga.

Las causas más frecuentes de un INP deficiente son: event handlers de JavaScript que ejecutan demasiado código en el hilo principal, reflows del DOM provocados por manipulaciones de estilos dentro de event handlers, y scripts de terceros (analytics, A/B testing, widgets de chat) que compiten por el hilo principal durante las interacciones del usuario.

Cómo depurar INP

El Chrome DevTools Performance Panel es la herramienta más eficaz. Graba una sesión de interacción y examina el “Long Animation Frame” (LoAF) API para identificar qué scripts bloquean el hilo principal durante cada interacción. Busca tareas que excedan los 50 ms y descompón cada una para localizar el código responsable.

Una técnica efectiva es el “yielding”: dividir las tareas largas de JavaScript en partes más pequeñas usando scheduler.yield() o setTimeout para devolver el control al navegador entre cada fragmento. Esta práctica permite que el navegador procese las actualizaciones visuales sin esperar a que termine toda la computación.

LCP (Largest Contentful Paint): qué mide y umbrales en 2026

LCP mide el tiempo que tarda en renderizarse el elemento de contenido más grande visible en el viewport. Ese elemento puede ser una imagen, un bloque de texto, un vídeo o un elemento SVG. Es la métrica que mejor captura la percepción del usuario sobre “cuánto tarda en cargar la página”, porque refleja el momento en que el contenido principal se vuelve visible.

Umbrales

• Bueno: LCP < 2,5 segundos
• Necesita mejora: LCP entre 2,5 y 4 segundos
• Deficiente: LCP > 4 segundos

Google mide el LCP en el percentil 75 de los datos de campo: si el 75% de las cargas de una URL tienen un LCP inferior a 2,5 segundos, esa URL pasa el umbral.

Las cuatro fases del LCP

Según la documentación de web.dev, el tiempo de LCP se descompone en cuatro subfases que guían el diagnóstico:

1. Time to First Byte (TTFB): tiempo desde la solicitud HTTP hasta que llega el primer byte de respuesta. Depende del servidor, la CDN y las redirecciones.
2. Resource Load Delay: tiempo entre el TTFB y el inicio de la descarga del recurso LCP. Si la imagen LCP no está en el HTML inicial (sino que se descubre tras parsear CSS o ejecutar JavaScript), este delay se amplía.
3. Resource Load Duration: tiempo de descarga del recurso LCP. Depende del tamaño del archivo y del ancho de banda.
4. Element Render Delay: tiempo entre la descarga completa del recurso y su renderizado en pantalla. CSS bloqueante y JavaScript que modifica el DOM pueden ampliar esta fase.

Causas frecuentes y soluciones

La causa más común de un LCP lento son imágenes hero de gran tamaño sin optimización. Una imagen de 2 MB en formato JPEG que podría ser un WebP de 200 KB añade segundos innecesarios al LCP. Las soluciones directas son: usar formatos modernos (WebP, AVIF), aplicar responsive images con srcset, precargar la imagen LCP con <link rel="preload"> y evitar lazy loading en la imagen above-the-fold.

La segunda causa más frecuente es el CSS render-blocking. Si tu página carga 300 KB de CSS antes de renderizar cualquier contenido, el LCP se retrasa proporcionalmente. La solución es inlinear el CSS crítico (el necesario para renderizar el contenido above-the-fold) y diferir el resto con media="print" o carga asíncrona.

Los datos de web.dev confirman que el TTFB es frecuentemente el componente más grande del LCP en sitios con servidores lentos: “Si su TTFB es lento, es difícil alcanzar los objetivos del resto de métricas.” Usar una CDN con edge caching y optimizar las consultas de base de datos del servidor son los dos pasos más efectivos para reducir el TTFB.

Benchmarks por sector: puntuaciones de los líderes del mercado

Saber que el umbral de LCP es 2,5 segundos es necesario, pero no suficiente. Las empresas necesitan contexto competitivo: ¿qué puntuaciones consiguen realmente los sitios de su sector? Los datos de HTTPArchive y CrUX permiten responder esta pregunta con cifras reales.

E-commerce

El sector del e-commerce es donde los Core Web Vitals tienen el impacto empresarial más directo y documentado. Los datos de 2025 muestran que los e-commerces que superan los tres umbrales tienen una tasa de conversión un 24% superior a los que no los superan.

Los líderes del sector (Amazon, Zalando, ASOS) mantienen un LCP mediano inferior a 1,8 segundos, un CLS por debajo de 0,04 y un INP inferior a 150 ms. Estos sitios invierten en equipos dedicados de performance con monitorización en tiempo real y presupuestos de rendimiento (performance budgets) que bloquean los despliegues cuando una métrica supera un umbral definido.

Para los e-commerces medianos en España, el benchmark realista es: LCP < 2,2 segundos, CLS < 0,08 e INP < 180 ms. Alcanzar estas cifras requiere optimización de imágenes de producto, gestión de scripts de terceros y server-side rendering o pre-rendering para las páginas de categoría.

Medios de comunicación y contenido editorial

Los sitios de contenido enfrentan un desafío particular en CLS: los anuncios dinámicos que se cargan tras el contenido editorial desplazan los elementos de la página, generando puntuaciones de CLS que frecuentemente superan 0,2. Los medios que mejor rendimiento logran (The Guardian, Financial Times) han implementado slots de anuncio con dimensiones reservadas y lazy loading controlado para minimizar los layout shifts.

En LCP, los sitios de contenido suelen tener ventaja porque sus elementos principales son textos, no imágenes pesadas. El benchmark de los líderes es LCP < 1,5 segundos para artículos de texto.

SaaS y B2B

Los sitios SaaS suelen tener buenos Core Web Vitals en las páginas de marketing (landing pages estáticas) pero malos en las aplicaciones web. Dado que Google evalúa las páginas que los usuarios encuentran a través de búsqueda, las landing pages son las que importan para ranking. El benchmark del sector es LCP < 2,0 segundos y CLS < 0,05.

El caso Rakuten, documentado por web.dev, es el referente más citado del sector tecnológico: un 33% más de conversiones y un 53% más de ingresos por visitante tras optimizar Core Web Vitals. Annie Sullivan del equipo de Chrome comentó sobre este caso: “Es un ejemplo perfecto de cómo las métricas centradas en el usuario se traducen directamente en resultados de negocio.”

Servicios profesionales y sitios corporativos

Es el sector con mayor variabilidad. Los sitios corporativos con CMS empresariales (Adobe Experience Manager, Sitecore) frecuentemente tienen LCP > 3 segundos por la complejidad del stack tecnológico. Los que mejor rendimiento logran son los que han adoptado arquitecturas de generación estática (Astro, Next.js) con CDN edge: LCP < 1,2 segundos es alcanzable para sitios institucionales con bajo dinamismo de contenido.

CLS (Cumulative Layout Shift): qué mide y causas frecuentes

CLS mide la suma de todos los desplazamientos inesperados de elementos visibles durante la vida de la página. Cada vez que un elemento del DOM cambia de posición sin que el usuario haya interactuado (por ejemplo, una imagen que se carga y empuja el texto hacia abajo, o un banner que aparece desde arriba), se genera un layout shift que contribuye a la puntuación CLS.

Umbrales

• Bueno: CLS < 0,1
• Necesita mejora: CLS entre 0,1 y 0,25
• Deficiente: CLS > 0,25

Cómo se calcula

El CLS no es una simple suma de todos los shifts. Google utiliza un sistema de “ventanas de sesión” que agrupa los shifts que ocurren en ráfagas rápidas (menos de 1 segundo entre cada uno, con un máximo de 5 segundos por ventana). El CLS final es la puntuación máxima de todas las ventanas de sesión. Este cálculo, actualizado en 2021, corrige una limitación del método original que penalizaba injustamente a las páginas donde el usuario permanecía mucho tiempo (aplicaciones web, feeds infinitos).

Cada shift individual se calcula como: fracción de impacto (porcentaje del viewport afectado) x fracción de distancia (distancia del desplazamiento como porcentaje del viewport). Una imagen que ocupa el 50% del viewport y se desplaza un 20% genera un shift de 0,1.

Las cinco causas más frecuentes de CLS alto

1. Imágenes y vídeos sin dimensiones declaradas. Si una imagen no tiene atributos width y height en el HTML, el navegador no puede reservar espacio antes de descargarla. Cuando la imagen se carga, empuja todo el contenido inferior. La solución es declarar siempre las dimensiones o usar la propiedad CSS aspect-ratio.

2. Anuncios dinámicos y embeds. Los slots de anuncios gestionados por Google AdSense, ad managers o redes programáticas frecuentemente cambian de tamaño tras la carga inicial. Reservar el espacio del slot con un contenedor de altura fija o usar la propiedad min-height reduce el impacto.

3. Fuentes web que provocan FOUT/FOIT. Cuando una fuente web se carga después del texto, el navegador puede cambiar de la fuente fallback a la fuente web, provocando un shift visible. Usar font-display: swap combinado con size-adjust en la fuente fallback minimiza el cambio de tamaño.

4. Contenido inyectado dinámicamente. Banners de cookies, barras de notificación, widgets de chat y elementos de UI que se insertan en el DOM después de la carga inicial pueden desplazar el contenido existente. La solución es reservar espacio o usar posicionamiento fijo/sticky para estos elementos.

5. Imágenes lazy-loaded above the fold. Si se aplica lazy loading a imágenes que están en el viewport inicial, el navegador primero renderiza la página sin ellas y después las inserta, causando un shift. Las imágenes above-the-fold nunca deben tener loading="lazy".

La mejora de CLS es una de las optimizaciones con mayor retorno inmediato. Según datos citados en el caso de estudio de web.dev, una reducción de CLS de 0,25 a 0,05 puede elevar las conversiones en un 15% porque los usuarios dejan de hacer clic accidentalmente en elementos que no eran su objetivo.

Hoja de ruta para mejorar tus Core Web Vitals en 90 días

Mejorar los Core Web Vitals no es un proyecto de un día. Requiere un enfoque secuencial que priorice las métricas según su impacto en negocio y su complejidad de resolución. Esta hoja de ruta está diseñada para equipos con recursos limitados que necesitan resultados medibles en un trimestre.

Fase 1: Diagnóstico y Quick Wins (Semanas 1-2)

Objetivo: establecer la línea base y resolver los problemas que se solucionan sin cambios arquitectónicos.

1. Ejecuta PageSpeed Insights en las 20 URLs con más tráfico orgánico. Documenta LCP, CLS e INP de campo para cada una.
2. Cruza con Google Search Console > Core Web Vitals para identificar grupos de URLs con patrones comunes.
3. Implementa las optimizaciones de imagen inmediatas: conversión a WebP/AVIF, dimensiones explícitas en HTML, preload de la imagen LCP, eliminación de lazy loading above-the-fold.
4. Añade font-display: swap y size-adjust a todas las fuentes web.
5. Reserva espacio para slots de anuncios y embeds con min-height.

Resultado esperado: mejora de LCP en un 20-30% y de CLS en un 40-60% solo con estos cambios.

Fase 2: Optimización de LCP y CLS (Semanas 3-6)

Objetivo: llevar LCP y CLS al rango “bueno” en el 90% de las URLs.

1. Audita el CSS render-blocking: inlinea el CSS crítico y difiere el resto. Herramientas como Critical (de Addy Osmani) automatizan la extracción.
2. Implementa una CDN si no la tienes. Un CDN edge reduce el TTFB entre un 40% y un 70% dependiendo de la distancia geográfica al servidor origen.
3. Optimiza la cadena de descubrimiento del recurso LCP: asegura que la imagen o recurso LCP está referenciado directamente en el HTML, no descubierto tras parsear CSS o ejecutar JavaScript.
4. Revisa todos los scripts de terceros: analytics, A/B testing, chat widgets, pixel de redes sociales. Difiere los que no sean críticos con async o defer. Considera cargar los no esenciales tras la interacción del usuario.
5. Implementa performance budgets: define umbrales máximos de tamaño para JavaScript (< 200 KB comprimido), CSS (< 50 KB crítico) e imágenes por página.

Fase 3: Optimización de INP (Semanas 7-10)

Objetivo: llevar INP al rango “bueno” identificando y resolviendo las interacciones lentas.

1. Usa Chrome DevTools con la API de Long Animation Frames (LoAF) para identificar las interacciones que superan 200 ms.
2. Implementa code splitting para JavaScript: carga solo el código necesario para cada página y difiere el resto.
3. Aplica yielding en event handlers largos: divide las tareas que superan 50 ms en chunks más pequeños usando scheduler.yield().
4. Mueve las computaciones pesadas fuera del hilo principal usando Web Workers cuando sea posible.
5. Audita los scripts de terceros que bloquean el hilo principal durante las interacciones. Las herramientas de A/B testing y los tag managers son los infractores más frecuentes.

Fase 4: Monitorización y Mantenimiento (Semanas 11-12)

Objetivo: establecer un sistema de alerta que prevenga regresiones.

1. Configura alertas automáticas (DebugBear, SpeedCurve o CrUX Dashboard) para detectar regresiones en cualquiera de las tres métricas.
2. Integra Lighthouse CI en tu pipeline de despliegue para bloquear releases que empeoren los Core Web Vitals.
3. Programa una revisión mensual del informe de Core Web Vitals en Search Console para detectar tendencias.
4. Documenta las decisiones de rendimiento en un “performance budget” que el equipo de desarrollo consulte antes de añadir nuevos scripts o funcionalidades.

Para una implementación específica de Core Web Vitals en tiendas online, consulta nuestra guía sobre Core Web Vitals en e-commerce. Si tu sitio está en WordPress, la guía de Core Web Vitals en WordPress cubre las particularidades de ese ecosistema. Y si necesitas apoyo profesional, nuestro servicio de optimización de Core Web Vitals incluye auditoría completa, implementación y monitorización continua.

Conclusión: Core Web Vitals como lenguaje entre negocio y tecnología

Los Core Web Vitals resolvieron un problema que la industria del SEO arrastraba desde hacía más de una década: la falta de métricas objetivas, estandarizadas y públicas para medir la experiencia del usuario en la web. Antes de 2020, cada herramienta medía la “velocidad” de forma diferente, los equipos de marketing y desarrollo hablaban idiomas distintos, y los directivos no tenían forma de saber si su sitio era rápido o lento sin depender de opiniones subjetivas.

En 2026, LCP, CLS e INP son el estándar de facto. Google los usa para ranking. Los equipos de desarrollo los usan para establecer performance budgets. Los directivos los usan para justificar inversiones en infraestructura. Y los datos muestran consistentemente que mejorarlos tiene un impacto directo en conversiones, ingresos y satisfacción del usuario.

El error más frecuente es tratar los Core Web Vitals como un proyecto puntual: “pasamos la auditoría, lo damos por hecho”. Pero cada nuevo script de terceros, cada cambio de diseño, cada actualización de contenido puede introducir una regresión. Las empresas que mantienen sus métricas en el rango “bueno” de forma sostenida son las que han integrado la monitorización de rendimiento en su flujo de trabajo diario, no las que hacen una optimización masiva una vez al año.

Los datos están claros. Las herramientas están disponibles. Los umbrales son públicos y estables. La única variable es si tu equipo prioriza la experiencia del usuario como un factor de negocio o la relega a una tarea técnica secundaria. Los Core Web Vitals convierten esa decisión en algo medible.