# Qué son las Core Web Vitals: LCP, INP y CLS

> Qué son las Core Web Vitals, los umbrales actuales de LCP, INP y CLS, qué pesan en Google y cómo medirlas en las fichas de tu tienda con datos reales.

URL: https://clione.ai/es/glosario/core-web-vitals/
Lang: es

Las Core Web Vitals no son una nota de velocidad ni una puntuación de cien: son tres medidas de cómo vive una página la gente que la visita de verdad. Las define Google dentro de su iniciativa Web Vitals, que nació para que un propietario no tenga que ser experto en rendimiento para saber qué experiencia da su web.[^webdev-vitals] A una tienda le importan por dos lados. Por el de Google, que **recomienda tener unas buenas Core Web Vitals para tener éxito en la Búsqueda** y las usa en sus sistemas de clasificación.[^google-page-experience] Y por el del cliente, que abandona una ficha que tarda, que no responde al tocar una talla o que mueve el botón de compra justo cuando va a pulsarlo.

## Cómo funciona

Son tres métricas, cada una sobre una parte de la experiencia:[^webdev-vitals]

- **LCP (Largest Contentful Paint)** mide la carga: el tiempo que tarda en pintarse el elemento más grande visible en pantalla, sea una imagen, un bloque de texto o un vídeo.[^webdev-lcp] Para una buena experiencia, 2,5 segundos o menos.
- **INP (Interaction to Next Paint)** mide la respuesta: observa todos los clics, toques y pulsaciones de teclado de la visita, y el valor final es la interacción más lenta, sin contar valores extremos.[^webdev-inp] Para una buena experiencia, 200 milisegundos o menos.
- **CLS (Cumulative Layout Shift)** mide la estabilidad visual: cuánto se desplaza de forma inesperada el contenido mientras la página está abierta.[^webdev-cls] Para una buena experiencia, 0,1 o menos.

**Se aprueba con el 75 % de las visitas, no con la media.** Google recomienda medir en el percentil 75 de las cargas de página, por separado en móvil y en escritorio, y da una página por buena cuando cumple los tres objetivos en ese percentil.[^webdev-vitals] Los datos salen del Chrome User Experience Report, que recoge mediciones anónimas de usuarios reales y alimenta PageSpeed Insights y el informe de Core Web Vitals de [Search Console](/es/glosario/search-console/).[^webdev-vitals]

El informe de Search Console añade el escalón intermedio, con estos umbrales:[^gsc-cwv-report]

| Métrica | Buena          | Necesita mejorar | Mala                           |
| ------- | -------------- | ---------------- | ------------------------------ |
| LCP     | 2,5 s o menos  | 4 s o menos      | más de 4 s                     |
| INP     | 200 ms o menos | 500 ms o menos   | más de 500 ms[^gsc-cwv-report] |
| CLS     | 0,1 o menos    | 0,25 o menos     | más de 0,25                    |

El informe agrupa las URL que dan una experiencia parecida, calcula cada valor sobre el 75 % de las visitas de los últimos 28 días y da a cada grupo el estado de su peor métrica. Un grupo sin datos suficientes de LCP y CLS no aparece.[^gsc-cwv-report]

**El conjunto cambia, pero despacio.** Las métricas pasan por tres fases, experimental, pendiente y estable, y una métrica estable no cambia más de una vez al año.[^webdev-vitals] El único cambio hasta ahora fue el de la respuesta: el 12 de marzo de 2024, **INP sustituyó a FID (First Input Delay)**, que solo medía el retraso de la primera interacción, y Chrome dio de plazo hasta el 9 de septiembre de 2024 para dejar de usar FID en sus herramientas.[^webdev-inp-launch][^webdev-inp]

Lo que pesan en Google tiene matices que Google escribe. Las Core Web Vitals se usan en sus sistemas de clasificación, pero sacar buenos resultados en el informe **no garantiza que tus páginas salgan arriba**, y perseguir una puntuación perfecta solo por SEO quizá no sea el mejor uso de tu tiempo. La relevancia va primero: Google muestra el contenido más relevante aunque la experiencia sea peor, y una buena experiencia ayuda cuando hay muchas páginas útiles donde elegir.[^google-page-experience] En su documentación, Google redondea los umbrales como «menos de 200 milisegundos» y «menos de 0,1»;[^google-cwv-search] web.dev y Search Console usan «o menos».

## En una tienda

Una [ficha de producto](/es/glosario/ficha-de-producto/) tiene las tres métricas a la vista. Un **ejemplo ficticio** de dónde suele estar cada una:

| Métrica | Qué la marca en una ficha                                                        | Qué la empeora                                                |
| ------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------- |
| LCP     | La foto principal del producto, cuando es el elemento más grande en pantalla     | Una imagen pesada o que se descubre tarde                     |
| INP     | Elegir una talla o un color, pulsar «Añadir al carrito», abrir la guía de tallas | Scripts largos en el hilo principal que retrasan la respuesta |
| CLS     | La zona de precio, las estrellas de las reseñas, el aviso de _cookies_           | Imágenes sin dimensiones y bloques que se insertan después    |

Las causas de la última columna son las que da web.dev. Una imagen cuenta como candidato a LCP;[^webdev-lcp] la respuesta de una interacción se retrasa por tareas largas en el hilo principal del navegador;[^webdev-inp] y los saltos de contenido suelen venir de recursos que cargan de forma asíncrona, de elementos que se añaden al DOM por encima de lo que ya había y de imágenes o vídeos sin dimensiones conocidas.[^webdev-cls] En una tienda, mucho de eso lo añaden las aplicaciones, y por eso el [renderizado de JavaScript](/es/glosario/renderizado-javascript/) de una ficha pesa también en su INP.

Google publica casos de negocio. Entre los que recogió web.dev en 2021, **Vodafone Italia mejoró su LCP un 31 % y vendió un 8 % más**.[^webdev-business] Es un caso de una empresa en una fecha, no una previsión para tu catálogo.


Que la nota de Lighthouse son las Core Web Vitals. Lighthouse carga la página en un entorno simulado, sin ninguna persona, así que **no puede medir INP**: en su lugar da el Total Blocking Time como aproximación.[^webdev-vitals] Y la medición de laboratorio no sustituye a la de campo, porque el móvil, la red y la forma de usar la página cambian cada valor.[^webdev-vitals] Un 100 en Lighthouse no significa aprobar con tus clientes, ni un suspenso en Search Console se arregla mirando solo el laboratorio.


## Cómo comprobarlo

1. **Abre el informe de Core Web Vitals de Search Console**, primero en móvil. Corrige antes lo que está en «Mala» y, dentro de cada estado, lo que afecta a más URL o a las más importantes.[^gsc-cwv-report]
2. **Pulsa una URL de ejemplo y pásala por PageSpeed Insights.** Ten en cuenta que el informe da valores por grupo de URL y PageSpeed Insights suele darlos por URL, así que pueden no coincidir.[^gsc-cwv-report]
3. **Si no hay datos**, el sitio es nuevo en Search Console o el Chrome User Experience Report no tiene visitas suficientes para ese tipo de dispositivo.[^gsc-cwv-report]
4. **Diagnostica en el laboratorio**, con Lighthouse o las herramientas de Chrome, y usa el Total Blocking Time como pista para INP: mejorarlo en el laboratorio puede mejorar INP con usuarios reales.[^webdev-vitals]
5. **Mide en tu propia web.** La biblioteca `web-vitals` de JavaScript mide las tres métricas como las calculan las herramientas de Google, y web.dev recomienda montar tu propia medición con usuarios reales para detectar a tiempo un empeoramiento.[^webdev-vitals]

## Concepto cercano: experiencia en la página

La experiencia en la página (_page experience_) es más amplia. Google pregunta, además de por las Core Web Vitals, si la página se sirve de forma segura, si se ve bien en el móvil, si evita el exceso de anuncios y los intersticiales intrusivos y si se distingue bien el contenido principal. No es una única señal: sus sistemas miran varias, y **de todos esos aspectos, solo las Core Web Vitals se usan directamente en la clasificación**; el resto no ayuda a subir de forma directa, aunque hace la web más satisfactoria.[^google-page-experience] Las Core Web Vitals son la parte que se mide con números.

Para seguir, el término de [renderizado del lado del servidor](/es/glosario/ssr/) explica cómo llega el contenido de una ficha al navegador, y la [ruta de lectura](/es/aprender/rastreo-e-indexacion/) de este tema ordena el resto de términos.