Core Web Vitals para tiendas online: LCP, INP y CLS explicados

Qué miden LCP, INP y CLS, los umbrales bueno y malo en el percentil 75, datos de laboratorio y de campo, y cómo mejorarlos en Shopify y WooCommerce.

Equipo editorial de FixReports15 min de lectura

Las Core Web Vitals (Métricas web principales) son tres métricas de Google que describen cómo viven una página los visitantes reales: Largest Contentful Paint (LCP) para la carga, Interaction to Next Paint (INP) para la capacidad de respuesta y Cumulative Layout Shift (CLS) para la estabilidad visual. Una página las supera cuando al menos el 75% de las visitas están en el rango «bueno»: un LCP de 2.5 segundos como máximo, un INP de 200 milisegundos como máximo y un CLS de 0.1 o menos, medidos por separado en móvil y en ordenador. En las tiendas online, las puntuaciones que no aprueban suelen deberse a imágenes principales y de producto demasiado grandes o con carga diferida, a scripts de apps y de seguimiento, a fuentes web y a banners o widgets de reseñas que desplazan el contenido hacia abajo cuando la página ya se ha mostrado.

Puntos clave

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

Una página cumple las Core Web Vitals cuando el percentil 75 de sus cargas de página está en el rango bueno en las tres métricas.

MétricaQué mideBuenoNecesita mejorarMalo
LCPTiempo hasta que se renderiza la imagen, el vídeo o el bloque de texto más grande del área visible (viewport)2.5 s o menosMás de 2.5 s y hasta 4.0 sMás de 4.0 s
INPTiempo desde un clic, un toque o una pulsación de tecla hasta que se pinta el siguiente fotograma200 ms o menosMás de 200 ms y hasta 500 msMás de 500 ms
CLSCuánto se mueve de forma inesperada el contenido visible0.1 o menosMás de 0.1 y hasta 0.25Más de 0.25

Los umbrales proceden de las guías de web.dev sobre LCP (se abre en una pestaña nueva), INP (se abre en una pestaña nueva) y CLS (se abre en una pestaña nueva), en su versión de octubre de 2026.

El percentil 75 hace que el resultado refleje a la mayoría de los visitantes, no solo a los más rápidos, y Google separa móvil y ordenador (se abre en una pestaña nueva). PageSpeed Insights aprueba una página cuando las tres métricas son buenas; si no hay suficientes datos de INP, la evalúa solo con LCP y CLS (documentación de PageSpeed Insights (se abre en una pestaña nueva)). Google afirma que las Core Web Vitals estables no cambiarán más de una vez al año.

En una tienda, el elemento LCP suele ser el banner principal o la imagen principal del producto, y por eso la gestión de las imágenes es tan importante.

¿Por qué INP sustituyó a FID en marzo de 2024?

INP sustituyó a FID porque FID solo medía la primera interacción, y solo una parte de su retraso, mientras que INP tiene en cuenta las interacciones de toda la visita.

Google anunció en mayo de 2023 que INP pasaría a ser una Core Web Vital, y el cambio entró en vigor el 12 de marzo de 2024 (se abre en una pestaña nueva). FID solo informaba de la primera interacción, y solo de su retraso de entrada, no del tiempo dedicado a ejecutar los controladores de eventos ni a pintar el resultado. INP observa los clics, los toques y las pulsaciones de teclas durante toda la visita e informa de la más larga, sin tener en cuenta los valores atípicos; el desplazamiento y el paso del ratón por encima no cuentan. Los usuarios de las API de CrUX y de PageSpeed Insights tuvieron hasta el 9 de septiembre de 2024 para hacer el cambio (web.dev (se abre en una pestaña nueva)).

Cada interacción tiene tres partes: el retraso de entrada (la espera mientras hay scripts ocupados), la duración del procesamiento (la ejecución de los controladores) y el retraso de presentación (el pintado del siguiente fotograma) (web.dev (se abre en una pestaña nueva)).

En una tienda, esas interacciones son el selector de variantes, los botones de cantidad, «Añadir al carrito», el carrito lateral, los filtros y los menús. Una página podía superar FID con un primer toque rápido y aun así resultar lenta cuando alguien abría los filtros más tarde.

¿Qué diferencia hay entre los datos de laboratorio y los datos de campo?

Los datos de laboratorio proceden de una única prueba en condiciones fijas, mientras que los datos de campo se recogen de visitantes reales a lo largo del tiempo, y Google recomienda usar los datos de campo para decidir qué corregir primero (web.dev (se abre en una pestaña nueva)).

Datos de laboratorioDatos de campo
OrigenUna carga de página simulada (Lighthouse, Chrome DevTools, la sección de laboratorio de PageSpeed Insights)Visitantes reales de Chrome (Chrome UX Report) o tu propia monitorización de usuarios reales
CondicionesDispositivo y red fijos. La prueba móvil predeterminada de Lighthouse (se abre en una pestaña nueva) usa «Slow 4G» (150 ms de ida y vuelta, 1.6 Mbps de bajada) y una ralentización de la CPU de 4xLos dispositivos, las redes y las ubicaciones que tengan tus visitantes
INPNo se mide en una simple carga de página. El Total Blocking Time (TBT) es una aproximaciónSe mide a partir de interacciones reales
Ideal paraDepurar y comprobar un cambio antes de publicarloSaber lo que reciben de verdad los visitantes

El TBT suma la parte de cada tarea del hilo principal que supera los 50 ms; web.dev aconseja menos de 200 ms en un hardware móvil medio, pero advierte que no sustituye a INP (web.dev (se abre en una pestaña nueva)).

Hay tres detalles del Chrome UX Report (CrUX) que importan a las tiendas:

  • Es una media móvil de 28 días (se abre en una pestaña nueva) que se actualiza a diario.
  • Cubre Chrome en ordenador y en Android para los usuarios que cumplen las condiciones de envío de datos de Chrome. Chrome en iOS queda excluido, así que una tienda cuyos compradores usan sobre todo iPhone solo ve datos de campo de una parte de su público (metodología (se abre en una pestaña nueva)).
  • Las páginas y los orígenes solo aparecen cuando son públicamente detectables y lo bastante populares, así que una tienda con poco tráfico puede tener solo datos a nivel de origen, o ninguno.

El panel de rendimiento web (se abre en una pestaña nueva) de Shopify también informa del LCP, el INP y el CLS de usuarios reales en el percentil 75, pero sobre 30 días en lugar de 28, así que es normal ver algunas diferencias con CrUX.

¿Qué ralentiza el LCP en las páginas de una tienda?

El LCP suele ser lento en las tiendas porque la imagen principal pesa demasiado, se descubre tarde o se retrasa a propósito con la carga diferida o con una animación.

  • Carga diferida de la imagen LCP. web.dev dice que no hay que hacerlo nunca (web.dev (se abre en una pestaña nueva)). Su análisis de páginas de WordPress observó un LCP más lento en el percentil 75 en los sitios que usaban la carga diferida nativa, y dejar de aplicarla a las imágenes visibles sin desplazarse eliminó ese empeoramiento (web.dev (se abre en una pestaña nueva)).
  • Una imagen que se descubre tarde. Una imagen principal definida como background-image en CSS, o insertada por el script de un carrusel, no está en el HTML que el navegador analiza primero. Shopify desaconseja usar fondos CSS para el contenido principal y aplicar efectos de aparición gradual a la imagen LCP (Shopify (se abre en una pestaña nueva)).
  • Prioridad baja. Las imágenes se cargan con prioridad baja hasta que se completa el diseño, así que Shopify recomienda fetchpriority="high" en la imagen LCP (Shopify (se abre en una pestaña nueva)). web.dev señala que aplicarlo a más de una o dos imágenes reduce su utilidad (web.dev (se abre en una pestaña nueva)).
  • CSS y scripts que bloquean el renderizado. Las hojas de estilo grandes y los scripts síncronos del <head> retrasan el renderizado incluso cuando la imagen ya ha llegado (web.dev (se abre en una pestaña nueva)).
  • Tamaño de los archivos y fuentes. Usa formatos modernos, srcset y sizes, y una CDN. Para las fuentes web, usa un valor de font-display distinto de auto o block.
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

¿Qué hace que el INP sea lento en las páginas de una tienda?

Un INP lento en una tienda suele significar demasiado JavaScript en el hilo principal, en gran parte procedente de apps, etiquetas de seguimiento y funciones del tema, así que los toques tienen que esperar.

Si un comprador toca «Añadir al carrito» mientras los scripts de reseñas, de chat y de analítica siguen ejecutándose, el toque espera. Un selector de variantes que vuelve a renderizar todo el formulario del producto añade tiempo de procesamiento. Los megamenús enormes y las cuadrículas de colección con muchas muestras de color añaden retraso de presentación.

web.dev recomienda dividir las tareas largas y ceder el control al hilo principal, actualizar primero la pantalla y aplazar el resto, y mantener un DOM más pequeño (web.dev (se abre en una pestaña nueva)). Shopify añade pasos específicos para tiendas: auditar cada app, cada píxel y cada script del tema, aplazar lo que no sea crítico, cargar las funciones cuando se interactúa con ellas y desactivar los fragmentos antiparpadeo de las pruebas A/B cuando no haya ninguna prueba en marcha (Shopify (se abre en una pestaña nueva)).

¿Qué provoca los cambios de diseño en las páginas de producto y de colección?

Los cambios de diseño en las tiendas se deben sobre todo a contenido que aparece o cambia de tamaño después del primer renderizado: imágenes sin dimensiones, barras de anuncios y de cookies, widgets de reseñas, bloques de apps y cambios de fuente.

web.dev enumera como causas habituales los elementos multimedia de dimensiones desconocidas, el contenido añadido encima del contenido existente, los widgets de terceros que cambian de tamaño solos y las fuentes web cuyo tamaño difiere del de su fuente alternativa (web.dev (se abre en una pestaña nueva)). En una tienda, eso significa una barra de envío gratuito insertada arriba, valoraciones con estrellas que se cargan después del título, mensajes de pago a plazos bajo el precio y carruseles de recomendaciones. Shopify señala que el contenido emergente también puede provocar cambios de diseño (Shopify (se abre en una pestaña nueva)).

Los cambios que se producen en los 500 ms siguientes a una acción del usuario no cuentan, pero los que se producen al desplazarse sí, y las herramientas de laboratorio a menudo no los detectan (web.dev (se abre en una pestaña nueva)). Asigna a las imágenes width y height o un aspect-ratio en CSS, reserva espacio para los widgets, muestra los banners superpuestos al contenido, reduce los cambios por sustitución de fuentes con size-adjust y anima con transform en lugar de top o left.

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

¿Cómo mejorar las Core Web Vitals en Shopify?

En Shopify, la mayor parte de la mejora viene de cargar la primera imagen de forma inmediata y con prioridad alta, recortar los scripts de las apps y comprobar el resultado en los informes de rendimiento web del panel de control.

Consulta los datos en tu panel de control

Encontrarás un resumen en la página Tienda online > Temas (Online Store > Themes), y los informes completos de LCP, INP y CLS en Estadísticas > Informes (Analytics > Reports). Los datos pueden tardar hasta 36 horas en aparecer, y el modo privado debe estar desactivado (Centro de ayuda de Shopify (se abre en una pestaña nueva)).

Controla la carga de imágenes en Liquid

El filtro image_tag aplica la carga diferida a las imágenes de las secciones situadas más abajo en la página, salvo que definas preload (referencia de image_tag (se abre en una pestaña nueva)): carga inmediata en las secciones 1 a 3 y carga diferida a partir de la sección 4. Como section.index es nil en el editor de temas, comprueba > 3 en lugar de <= 3:

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

En las cuadrículas de productos, Shopify sugiere cargar de forma inmediata solo las primeras tarjetas (por ejemplo, forloop.index <= 4) (Shopify (se abre en una pestaña nueva)). Usa preload: true con moderación; Shopify recomienda precargar solo uno o dos recursos que se descubran tarde.

Elimina lo que dejan las apps

Desactiva las inserciones de apps que no uses en Tienda online > Editar tema > Inserciones de aplicaciones (Online Store > Edit theme > App embeds) (Centro de ayuda de Shopify (se abre en una pestaña nueva)). Desinstalar una app elimina sus bloques de app, pero las apps que editaron directamente los archivos del tema pueden dejar «código fantasma» que, según Shopify, puede causar problemas de calidad y de rendimiento (Shopify (se abre en una pestaña nueva)). Shopify también indica que las etiquetas de script (script tags) dejarán de ejecutarse el 1 de marzo de 2027. Para las fuentes, Shopify recomienda su propia CDN o las fuentes del sistema en lugar de servicios de fuentes externos (Shopify (se abre en una pestaña nueva)).

¿Cómo mejorar las Core Web Vitals en WooCommerce?

En WooCommerce, asegúrate de que los plugins no anulen la priorización de imágenes de WordPress, almacena en caché todo excepto el carrito y la finalización de compra, y elimina los scripts que se cargan en todas partes sin necesidad.

  • Mantén la gestión de imágenes del núcleo. Desde WordPress 6.3 (publicado el 8 de agosto de 2023), el núcleo añade fetchpriority="high" a la imagen que probablemente sea el elemento LCP (de al menos 50 000 píxeles cuadrados por defecto) y no aplica la carga diferida a las tres primeras imágenes del contenido (Make WordPress Core (se abre en una pestaña nueva)). Si un plugin de optimización añade su propia carga diferida, comprueba que excluya la imagen principal de la página y la imagen principal del producto.
  • Almacena en caché las páginas, no los carritos. La guía de WooCommerce recomienda la caché de páginas en el servidor o mediante un plugin y una CDN, sin almacenar en caché las páginas del carrito y de finalización de compra (documentación para desarrolladores de WooCommerce (se abre en una pestaña nueva)).
  • Revisa los cart fragments. Desde WooCommerce 7.8, el script de cart fragments (fragmentos del carrito) solo se carga donde hay un widget Carrito, pero algunos temas incluyen ese widget directamente en el código. El bloque Mini-Cart no usa cart fragments (blog para desarrolladores de WooCommerce (se abre en una pestaña nueva)).
  • Localiza los plugins pesados. WooCommerce sugiere usar Query Monitor para encontrar los plugins lentos y aplazar el JavaScript que no sea crítico.

Si tu diseño muestra más de tres imágenes visibles sin desplazarse, puedes subir el umbral de WordPress:

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

¿Cuánto tardan en notarse las correcciones?

Las pruebas de laboratorio muestran el efecto de una corrección de inmediato, pero los datos de campo necesitan hasta unas cuatro semanas para reflejarla por completo, porque CrUX promedia los 28 días anteriores.

Ejecuta la prueba de laboratorio varias veces antes y después de un cambio, porque cada ejecución da resultados distintos, y después sigue las cifras de campo en PageSpeed Insights, en el informe Métricas web principales de Search Console o en los informes de Shopify. Un análisis gratuito te da una primera lectura en aproximadamente un minuto. El Informe de Rendimiento ejecuta una prueba de laboratorio en móvil con limitación de red (4G lento, CPU 4x) y añade los datos de campo del Chrome UX Report, incluido el INP cuando Google tiene suficientes datos de tu tienda.

Preguntas frecuentes

¿Influyen las Core Web Vitals en el posicionamiento en Google?

Google afirma que sus sistemas de clasificación usan las Core Web Vitals, pero que unas buenas puntuaciones no garantizan los primeros puestos y que sigue mostrando el contenido más relevante aunque la experiencia de página sea mala (Google Search Central (se abre en una pestaña nueva)).

¿Por qué PageSpeed Insights no muestra datos de campo de mi tienda?

CrUX solo incluye las páginas y los orígenes que son públicamente detectables y que tienen suficientes visitantes de Chrome que cumplen los requisitos. Una tienda con poco tráfico puede tener solo datos a nivel de origen, o ninguno, así que básate en las pruebas de laboratorio y en los informes de tu propia plataforma.

¿Necesito una puntuación de 90 o más en Lighthouse para aprobar?

No. La puntuación de rendimiento de Lighthouse es un resultado de laboratorio, mientras que la evaluación de las Core Web Vitals usa datos de campo en el percentil 75, así que una página puede aprobar con una puntuación modesta en Lighthouse y suspender con una alta.

¿Debo aplicar la carga diferida a todas las imágenes de producto?

No. Aplica la carga diferida a las imágenes que quedan por debajo de la primera pantalla, pero carga de forma inmediata la imagen principal de la página y la imagen principal del producto, con fetchpriority="high" en una de ellas.

¿Por qué mis resultados en móvil son peores que en ordenador?

Google mide el móvil y el ordenador por separado, y los teléfonos tienen procesadores y redes más lentos. La prueba móvil de Lighthouse lo simula con un perfil Slow 4G y una ralentización de la CPU de 4x.

Fuentes

Todas las guías