Core Web Vitals: cómo medir y corregir LCP, INP y CLS

En resumen: Core Web Vitals son tres métricas que Google usa para describir la experiencia de los usuarios reales: Largest Contentful Paint (LCP, carga, bueno a 2,5 s o menos), Interaction to Next Paint (INP, capacidad de respuesta, bueno a 200 ms o menos) y Cumulative Layout Shift (CLS, estabilidad visual, bueno a 0,1 o menos). Cada una se evalúa en el percentil 75 de las visitas reales en Chrome durante 28 días, por separado en móvil y escritorio. Google afirma que sus sistemas de clasificación las utilizan, pero la relevancia va primero. Para corregirlas, descompón cada métrica en sus partes y arregla primero la más grande.

La mayoría de los consejos sobre Core Web Vitals son listas de cincuenta trucos. Por eso muchos equipos dedican un sprint al «rendimiento» y sus cifras apenas se mueven. Las métricas tienen más estructura: cada una se puede dividir en unas pocas partes medibles y, normalmente, una de ellas causa la mayor parte del problema.

Esta guía explica qué miden las tres métricas, los umbrales vigentes a octubre de 2026, qué fuente de datos conviene creer, qué dice realmente Google sobre el posicionamiento y un plan de corrección que empieza por el diagnóstico para cada métrica, basado en la documentación de Google en web.dev.

Qué miden los Core Web Vitals

Según la visión general de Web Vitals en web.dev, el conjunto actual y estable tiene tres métricas:

Los umbrales coinciden con la tabla de About PageSpeed Insights.

La regla del percentil 75

Google no juzga una página por su promedio ni por una sola prueba. Web.dev indica que un buen umbral de medición es «el percentil 75 de las cargas de página, segmentado entre dispositivos móviles y de escritorio». En lenguaje llano: al menos tres de cada cuatro visitas reales deben cumplir el umbral «bueno». Para aprobar, una página necesita un resultado bueno en el percentil 75 de las tres métricas.

Esto tiene dos consecuencias que a menudo se pasan por alto:

1. Móvil y escritorio son independientes. Una página puede estar bien en escritorio y mal en móvil. El móvil suele ser el más difícil, porque los teléfonos tienen CPU y redes más lentas.
2. Tus visitantes más lentos deciden el resultado. Si una cuarta parte de tus visitantes usa móviles Android antiguos con conexiones débiles, su experiencia es tu puntuación. Probar en un portátil nuevo con el wifi de la oficina dice muy poco.

INP sustituyó a FID en 2024

Interaction to Next Paint sustituyó a First Input Delay (FID) como Core Web Vital el 12 de marzo de 2024. FID solo medía el retraso antes de que el navegador empezara a gestionar la primera interacción. INP abarca los clics, toques y pulsaciones de teclas durante toda la visita, y el tiempo completo hasta que se pinta el siguiente fotograma. Muchos sitios que aprobaban FID con facilidad suspenden INP, porque la parte lenta siempre fue el trabajo posterior a la primera interacción, que FID nunca contaba. Si todavía ves FID en un informe o plugin antiguo, ignóralo.

Web.dev también señala que los Core Web Vitals estables «no cambiarán más de una vez al año», y que las nuevas métricas candidatas permanecen en fase pendiente al menos seis meses, así que recibes aviso antes de que cambien las reglas.

Datos de campo vs. datos de laboratorio

Hay dos tipos de datos de rendimiento, y confundirlos es la razón más habitual por la que los equipos corrigen lo que no toca.

Algunos detalles de la documentación de Google:

• CrUX es un promedio móvil de 28 días, actualizado a diario, según la documentación de la API de CrUX. Se puede consultar para un origen completo o una sola URL, y filtrar por teléfono, escritorio o tableta.
• PageSpeed Insights muestra ambos. Su sección de campo usa los 28 días anteriores de datos de CrUX. Si una URL tiene muy pocas visitas, recurre a los datos de todo el origen; si el origen es demasiado pequeño, no hay datos de campo (About PageSpeed Insights). La sección de laboratorio y la puntuación de 0 a 100 provienen de Lighthouse.
• Lighthouse no puede medir INP. Web.dev afirma que las herramientas que cargan páginas «en un entorno simulado sin usuario no pueden medir INP» y propone Total Blocking Time (TBT) como aproximación de laboratorio.
• El informe de Core Web Vitals de Search Console agrupa páginas con experiencias similares y asigna a cada grupo el estado de su métrica más lenta para ese tipo de dispositivo. Usa datos de CrUX de los últimos 28 días (ayuda del informe de Core Web Vitals).

La regla práctica: los datos de campo deciden si tienes un problema; los de laboratorio ayudan a encontrar la causa. Una puntuación de Lighthouse de 98 con un LCP de campo malo significa que tus usuarios reales tienen peor experiencia que la simulación, a menudo por dispositivos lentos, anuncios, personalización o scripts de terceros que la prueba de laboratorio no activa.

Cuánto importan los Core Web Vitals para el posicionamiento

La documentación de experiencia de página de Google es clara en ambos sentidos:

• «Nuestros sistemas de clasificación utilizan los Core Web Vitals», y Google recomienda lograr buenos Core Web Vitals «para tener éxito en la Búsqueda».
• «No hay una señal única» para la experiencia de página; los sistemas de clasificación principales consideran diversas señales.
• «Google Search siempre busca mostrar el contenido más relevante, aunque la experiencia de página sea deficiente».
• Los buenos resultados en Search Console o en herramientas de terceros no garantizan que tus páginas aparezcan en los primeros puestos.
• «Intentar conseguir una puntuación perfecta solo por motivos de SEO puede no ser la mejor forma de invertir tu tiempo».

Nuestra lectura: los Core Web Vitals no elevarán una página irrelevante por encima de una relevante, pero pueden pesar entre páginas de calidad similar, y importan directamente para los usuarios. Una ficha de producto que tarda cinco segundos en mostrar su foto, o un botón «Comprar» que se congela medio segundo, pierde clientes sin importar la posición. Apunta a «bueno» en las tres y luego deja de perseguir puntos y vuelve al contenido.

Paso 1: averigua qué métrica falla y dónde

Antes de tocar código:

1. Abre el informe de Core Web Vitals de Search Console, primero el de móvil. Anota qué métrica falla y qué grupos de URL se ven afectados (fichas de producto, entradas del blog, la página de inicio).
2. Elige una URL representativa por cada grupo con fallos y pásala por PageSpeed Insights. Comprueba si los datos de campo son de esa URL o del origen.
3. Corrige una plantilla cada vez. Los problemas de Core Web Vitals casi siempre son problemas de plantilla: todas las fichas de producto comparten el mismo componente de imagen, los mismos scripts y el mismo diseño.

Nuestro verificador de Core Web Vitals gratuito ofrece una primera lectura rápida sin cuenta: obtiene de CrUX el LCP, INP y CLS del percentil 75 para visitantes en teléfono (para la página que introduzcas cuando Chrome tiene datos suficientes, o si no para todo tu origen) y mide el tiempo de respuesta del servidor, el tamaño del HTML, la compresión, los scripts que bloquean el renderizado en el head de la página y los formatos de imagen de esa página, por defecto tu página de inicio.

Paso 2: corrige el LCP por sus cuatro subpartes

LCP es el tiempo hasta que se renderiza la imagen o el bloque de texto más grande del viewport. Los elementos válidos incluyen <img>, <video>, elementos con una imagen de fondo CSS mediante url() y texto en bloque (LCP en web.dev). En la mayoría de las fichas de producto y landings es la imagen principal.

Optimize LCP divide el LCP en cuatro partes que suman el total:

Web.dev llama a estas proporciones «pautas, no reglas estrictas», pero son muy útiles para el diagnóstico. El panel Rendimiento de Chrome DevTools muestra el desglose de una carga grabada. La parte que más se pase de su proporción es por donde empiezas.

TTFB alto

El TTFB incluye redirecciones, establecimiento de la conexión y procesamiento en el servidor. La guía de TTFB de web.dev sugiere 0,8 segundos o menos como objetivo orientativo, aclarando que el TTFB no es en sí un Core Web Vital.

• Sirve el HTML desde una CDN y guárdalo en caché en el borde, aunque sea brevemente. The most effective ways to improve Core Web Vitals señala la CDN como la mejor forma de reducir el TTFB.
• Elimina las cadenas de redirecciones, incluidas las de enlaces publicitarios y acortados.
• Vigila los parámetros de URL únicos (de analítica o campañas) que hacen que cada petición sea un fallo de caché.
• Analiza las consultas lentas a la base de datos y el renderizado en servidor de la plantilla de la página.

Retraso de carga del recurso alto

A menudo es la subparte más grande y normalmente la más barata de corregir. El navegador podría haber empezado antes la descarga de la imagen, pero no sabía de su existencia.

• Pon la imagen LCP en el HTML inicial como un <img src> o srcset normal. Las imágenes insertadas con JavaScript, o que usan data-src para una biblioteca de carga diferida, se descubren tarde.
• Nunca apliques lazy loading a la imagen LCP. Quita loading="lazy" de la imagen principal; web.dev lo dice sin rodeos: «nunca apliques lazy loading a tu imagen LCP».
• Añade fetchpriority="high" a la imagen LCP, y a no más de una o dos imágenes.
• Si la imagen es un fondo CSS, precárgala con <link rel="preload"> y una prioridad de descarga alta, o cámbiala por un <img>.
• Sirve las imágenes críticas desde el mismo origen que el HTML siempre que sea posible, para reutilizar la conexión.

Duración de carga del recurso alta

• Sirve la imagen al tamaño en que se muestra, con srcset y sizes, para que los móviles no descarguen una imagen de escritorio.
• Usa formatos modernos como AVIF o WebP y comprime bien.
• Usa una CDN de imágenes que redimensione y convierta automáticamente.
• Reduce otras descargas de alta prioridad que compiten por el ancho de banda al mismo tiempo.

Retraso de renderizado del elemento alto

La imagen ya llegó, pero algo impide que el navegador la pinte:

• CSS que bloquea el renderizado: redúcelo, difiere los estilos no críticos, incrusta solo CSS crítico muy pequeño.
• Scripts síncronos en el <head>: añade async o defer.
• Renderizado en el cliente: si el contenido de la página aparece solo después de ejecutarse un framework de JavaScript, prefiere el renderizado en servidor o el prerenderizado.
• Scripts de tests A/B o de personalización que ocultan la página hasta decidir qué variante mostrar.
• Tareas largas de JavaScript que se ejecutan justo cuando la imagen está lista.

Si el LCP es un bloque de texto y no una imagen, el retraso y la duración de carga del recurso son cero, y el problema está en el TTFB, los recursos que bloquean el renderizado o las fuentes web.

Paso 3: corrige el INP por sus tres fases

INP registra clics, toques y pulsaciones de teclas durante toda la visita (no el desplazamiento ni el hover) e informa de la interacción más lenta, ignorando un valor atípico por cada 50 interacciones (INP en web.dev). Cada interacción tiene tres fases:

El problema de fondo casi siempre son las tareas largas: cualquier tarea que tarde más de 50 milisegundos en el hilo principal. Mientras se ejecuta una tarea larga, el navegador no puede responder al usuario.

Reduce el retraso de entrada

• Carga menos JavaScript durante el arranque; la evaluación de scripts crea tareas largas justo cuando los usuarios intentan tocar por primera vez.
• Audita tu gestor de etiquetas. Web.dev señala que «se pueden eliminar las etiquetas antiguas con código sin usar». Los widgets de chat, mapas de calor, tests A/B y scripts de anuncios suelen ejecutar mucho trabajo en el hilo principal.
• Usa la herramienta Coverage de Chrome y la división de código (code splitting) para dejar de enviar código que la página no utiliza.

Reduce la duración del procesamiento

• Haz menos en el controlador del evento. Actualiza primero lo que el usuario necesita ver y difiere el resto (llamadas de analítica, guardar el estado, recalcular recomendaciones).
• Cede el control al hilo principal entre bloques de trabajo. await scheduler.yield() continúa el trabajo restante en una tarea nueva y priorizada. No es compatible con todos los navegadores, así que web.dev sugiere recurrir a setTimeout envuelto en una Promise (Optimize long tasks).
• Evita el layout thrashing: leer valores de diseño (como offsetHeight) justo después de cambiar estilos en la misma tarea obliga al navegador a calcular el diseño de forma síncrona. Agrupa las lecturas y las escrituras.

Reduce el retraso de presentación

• Mantén el DOM pequeño. Optimize INP explica que el trabajo de renderizado crece con el tamaño del DOM.
• Usa content-visibility para omitir el renderizado de secciones fuera de pantalla, como reseñas largas o pies de página.
• Evita renderizar grandes bloques de HTML con JavaScript en respuesta a un clic; renderiza solo lo necesario.

Para encontrar la interacción lenta, mira primero los datos de usuarios reales (qué páginas fallan) y luego reprodúcela en Chrome DevTools: graba una traza de Rendimiento mientras haces clic en el elemento sospechoso con la CPU limitada, y busca tareas largas después del clic.

Paso 4: corrige el CLS causa por causa

CLS suma los cambios de diseño inesperados. Cada cambio puntúa la fracción del viewport que se movió multiplicada por la distancia que se movió, los cambios se agrupan en ventanas de hasta cinco segundos y el CLS es la peor ventana (CLS en web.dev). Los cambios que ocurren dentro de los 500 ms posteriores a un clic, toque o pulsación de tecla se excluyen, porque el usuario los esperaba. El desplazamiento no cuenta como entrada, así que el contenido que se mueve mientras alguien hace scroll sí cuenta.

Según Optimize CLS, las causas habituales y sus correcciones:

Dos notas de la experiencia:

• Colapsar espacio también provoca cambios. Web.dev advierte que eliminar espacio reservado «puede causar tanto CLS como insertar contenido». Si un hueco de anuncio queda vacío, conserva el marcador de posición.
• Los banners de cookies y las barras promocionales son culpables frecuentes. Superpónlos al contenido en lugar de empujar la página hacia abajo.

No olvides la caché de atrás/adelante (bfcache)

Cuando los usuarios pulsan Atrás, una página restaurada desde bfcache aparece al instante, sin nuevos cambios de carga. Web.dev considera que ser apto para bfcache es una técnica muy eficaz para mantener bajo el CLS. Los dos bloqueos más comunes, según la guía de bfcache de web.dev: los listeners del evento unload (usa pagehide en su lugar) y la cabecera Cache-Control: no-store en páginas que no contienen datos sensibles. Chrome DevTools incluye una prueba en Application › Back/forward cache.

Un ejemplo práctico (cifras hipotéticas)

Lo siguiente es un ejemplo hipotético, no datos reales. Fernwood Home, una tienda de muebles online inventada, suspende la evaluación de Core Web Vitals en móvil en la plantilla de sus fichas de producto. Los valores de campo del percentil 75:

LCP: 4,6 s

Una traza de DevTools con un perfil de teléfono limitado muestra que el elemento LCP es la foto principal del producto. El desglose:

El retraso de carga del recurso supera más de tres veces su proporción objetivo, así que va primero. Las correcciones: renderizar la primera foto como un <img> simple en el HTML del servidor, quitarle loading="lazy", añadir fetchpriority="high", servir AVIF y WebP en tamaños para móvil mediante srcset, cachear el HTML en la CDN ignorando los parámetros de seguimiento en la clave de caché y cargar el script A/B con defer.

Resultado de laboratorio tras el despliegue: TTFB 0,7 s, retraso de carga 0,2 s, duración de carga 0,6 s, retraso de renderizado 0,3 s, para un LCP de 1,8 s.

INP: 340 ms

Los datos de campo señalan la ficha de producto; al reproducirlo en DevTools, la interacción lenta es el botón «Añadir al carrito». La traza muestra unos 90 ms de retraso de entrada (un widget de chat y dos etiquetas de seguimiento ejecutándose en el mismo momento), 190 ms de procesamiento (el controlador vuelve a renderizar todo el panel del carrito y envía tres llamadas de analítica de forma síncrona) y 60 ms de retraso de presentación.

Las correcciones: cargar el widget de chat solo tras la primera interacción del usuario, mostrar primero la actualización del panel del carrito y ceder el control antes de las actualizaciones de analítica y recomendaciones. Medición de laboratorio con el mismo perfil limitado: unos 150 ms.

CLS: 0,21

Tres causas: un widget de estrellas de reseñas insertado sobre el precio tras la carga, un cambio de fuente web que reajusta el título del producto y miniaturas sin dimensiones. Las correcciones: reservar la altura del widget de reseñas, precargar la fuente del título y ajustar la de respaldo con size-adjust, y añadir width y height a cada miniatura. CLS de laboratorio: 0,04.

Cómo leer el resultado

Las cifras de laboratorio confirman que las correcciones funcionan. Las cifras de campo, que son las que deciden la evaluación, se mueven a medida que las visitas nuevas reemplazan a las antiguas en la ventana de 28 días. Fernwood debería esperar un cambio gradual durante unas cuatro semanas y luego hacer clic en Start tracking en el informe de Search Console para iniciar la validación, que también dura 28 días. Si el LCP de campo se queda en, digamos, 2,3 s en lugar de 1,8 s, es normal: los móviles y las redes reales son más lentos que cualquier perfil de laboratorio.

Errores comunes

• Perseguir la puntuación de Lighthouse. La puntuación de 0 a 100 es un resumen de laboratorio. La evaluación de Google usa datos de campo en el percentil 75.
• Probar solo en escritorio. El móvil se evalúa por separado y suele fallar primero.
• Aplicar lazy loading a todo. Cargar de forma diferida las imágenes bajo el pliegue está bien; hacerlo con la imagen principal es una de las causas más habituales de un mal LCP.
• Corregir solo la página de inicio. Gran parte del tráfico suele aterrizar en plantillas de producto, categoría o artículo. Corrige las plantillas con más URL fallidas.
• Añadir un script más. Cada etiqueta, widget y script de pruebas compite por el hilo principal. Elimina uno por cada uno que añadas.
• Esperar resultados instantáneos. Los datos de campo necesitan unos 28 días para reflejar por completo un despliegue.
• Ignorar lo básico en móvil. Una página sin etiqueta viewport o con imágenes sobredimensionadas es lenta en móvil antes de cualquier optimización. La prueba de compatibilidad móvil gratuita comprueba esos básicos.

Una lista de verificación para la primera hora

1. Pasa tu dominio por el verificador de Core Web Vitals gratuito para obtener el LCP, INP y CLS de usuarios reales en móviles, además del tiempo de respuesta del servidor, la compresión y los scripts bloqueantes.
2. Abre el informe de Core Web Vitals de Search Console para móvil y haz una lista de los grupos de URL con fallos.
3. Para cada grupo con fallos, pasa una URL por PageSpeed Insights y anota qué métrica falla en campo.
4. Para el LCP, graba una traza de DevTools y apunta las cuatro subpartes. Corrige primero la mayor.
5. Para el INP, encuentra la interacción lenta y las tareas largas posteriores.
6. Para el CLS, revisa las imágenes sin dimensiones, el contenido inyectado tarde y las fuentes.
7. Publica, confirma en laboratorio y revisa los datos de campo a las dos y a las cuatro semanas.

Los Core Web Vitals son una parte de la salud técnica. Nuestra guía de auditoría de SEO técnico los sitúa en contexto junto con el rastreo, la indexación, las redirecciones y los datos estructurados.

Cómo te ayuda Searvia con los Core Web Vitals

El verificador de Core Web Vitals gratuito no requiere cuenta y te da el panorama de usuarios reales de tu sitio en menos de un minuto. Dentro de Searvia, la pestaña Page speed de un proyecto de sitio web ejecuta PageSpeed Insights cada semana en tus páginas más visitadas y muestra tanto las puntuaciones de laboratorio como los datos de usuarios reales de Chrome para LCP, INP y CLS de los últimos 28 días. Las correcciones se ordenan por el tiempo que ahorran, y Write a fix plan for my files with AI convierte los puntos principales en cambios paso a paso para tu stack (3 créditos). Conecta Search Console para ver clics y posiciones junto a la velocidad y así saber si una plantilla más rápida realmente trajo más tráfico. La guía de ayuda de velocidad de página explica la configuración en unos dos minutos.