Core Web Vitals para tiendas en línea: LCP, INP y CLS

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

Equipo editorial de FixReports15 min de lectura

Las Core Web Vitals 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 aprueba cuando al menos el 75 % de las visitas está en el rango “bueno”: LCP de 2.5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0.1 o menos, medidos por separado en celular y en computadora. En las tiendas en línea, los malos resultados casi siempre se deben a imágenes principales y de producto muy pesadas o con carga diferida, a scripts de apps y de seguimiento, a fuentes web y a banners o widgets de reseñas que empujan el contenido hacia abajo después de que la página aparece.

Puntos clave

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

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

MétricaQué mideBuenoNecesita mejorarDeficiente
LCPTiempo hasta que se muestra la imagen, el video o el bloque de texto más grande del área visible2.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 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 provienen 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), vigentes en octubre de 2026.

El percentil 75 significa que el resultado refleja a la mayoría de los visitantes, no solo a los más rápidos, y Google separa celular y computadora (se abre en una pestaña nueva). PageSpeed Insights aprueba una página cuando las tres métricas están en el rango bueno; si no hay suficientes datos de INP, evalúa solo 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 (hero) o la imagen principal del producto, y por eso el manejo de imágenes importa tanto.

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

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

Google anunció en mayo de 2023 que INP se convertiría en Core Web Vital, y el cambio entró en vigor el 12 de marzo de 2024 (se abre en una pestaña nueva). FID solo reportaba la primera interacción, y solo su retraso de entrada, no el tiempo dedicado a ejecutar los controladores de eventos ni a pintar el resultado. INP observa los clics, toques y pulsaciones de teclas de toda la visita y reporta la más larga, sin contar los valores atípicos; el desplazamiento y pasar el cursor por encima no cuentan. Quienes usaban 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, agregar al carrito, el carrito lateral, los filtros y los menús. Una página podía aprobar FID con un primer toque rápido y aun así sentirse lenta cuando alguien abría los filtros más tarde.

¿Cuál es la diferencia entre los datos de laboratorio y los datos de campo?

Los datos de laboratorio provienen de una sola prueba en condiciones fijas, mientras que los datos de campo se recopilan 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 propio monitoreo 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 descarga) y una ralentización de CPU de 4xLos dispositivos, redes y ubicaciones que tengan tus visitantes
INPNo se mide en una carga de página simple. Total Blocking Time (TBT) es una aproximación generalSe mide a partir de interacciones reales
Ideal paraDepurar y comprobar un cambio antes de publicarloSaber lo que realmente reciben los visitantes

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

Tres detalles del Chrome UX Report (CrUX) importan para las tiendas:

  • Es un promedio móvil de 28 días (se abre en una pestaña nueva) que se actualiza todos los días.
  • Cubre Chrome en computadora y en Android para los usuarios que cumplen las condiciones de reporte 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 tienen suficiente popularidad, 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 reporta LCP, INP y CLS de usuarios reales en el percentil 75, pero sobre 30 días en lugar de 28, así que espera algunas diferencias con CrUX.

¿Qué hace más lento el LCP en las páginas de una tienda?

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

  • Cargar de forma diferida la imagen LCP. web.dev dice que nunca hay que hacerlo (web.dev (se abre en una pestaña nueva)). Su análisis de páginas de WordPress encontró un LCP más lento en el percentil 75 en sitios que usaban la carga diferida nativa, y dejar de cargar de forma diferida las imágenes visibles sin desplazarse eliminó el retroceso (web.dev (se abre en una pestaña nueva)).
  • Una imagen que se descubre tarde. Un banner principal definido como background-image en CSS, o insertado 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 los efectos de aparición gradual en la imagen LCP (Shopify (se abre en una pestaña nueva)).
  • Prioridad baja. Las imágenes se cargan con prioridad baja hasta que termina el diseño de la página, por eso 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 le resta utilidad (web.dev (se abre en una pestaña nueva)).
  • CSS y scripts que bloquean la renderización. Las hojas de estilo grandes y los scripts síncronos en el <head> retrasan la renderización incluso después de que llega la imagen (web.dev (se abre en una pestaña nueva)).
  • Peso 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 lento el INP en las páginas de una tienda?

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

Si un comprador toca “Agregar al carrito” mientras todavía se ejecutan los scripts de reseñas, chat y analítica, el toque espera. Un selector de variantes que vuelve a renderizar todo el formulario del producto suma tiempo de procesamiento. Los megamenús enormes y las cuadrículas de colección con muchas muestras de color suman 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 el DOM más pequeño (web.dev (se abre en una pestaña nueva)). Shopify agrega pasos específicos para tiendas: auditar cada app, píxel y script del tema, aplazar lo que no sea crítico, cargar funciones cuando el usuario interactúa y desactivar los fragmentos anti-parpadeo de las pruebas A/B cuando no hay ninguna prueba activa (Shopify (se abre en una pestaña nueva)).

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

Los cambios de diseño en las tiendas vienen sobre todo de 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 comunes los elementos multimedia sin dimensiones conocidas, el contenido que se agrega por encima del contenido existente, los widgets de terceros que cambian de tamaño solos y las fuentes web de tamaño distinto a su fuente de respaldo (web.dev (se abre en una pestaña nueva)). En una tienda, eso significa una barra de envío gratis insertada arriba, calificaciones con estrellas que cargan después del título, mensajes de pagos a meses o en cuotas debajo del precio y carruseles de recomendaciones. Shopify señala que el contenido de las ventanas emergentes también puede causar cambios (Shopify (se abre en una pestaña nueva)).

Los cambios que ocurren dentro de los 500 ms posteriores a una acción del usuario no cuentan, pero los que ocurren al desplazarse sí, y las herramientas de laboratorio a menudo no los detectan (web.dev (se abre en una pestaña nueva)). Dales a las imágenes width y height o un aspect-ratio en CSS, reserva espacio para los widgets, muestra los banners como capas superpuestas, 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 inmediato y con prioridad alta, recortar los scripts de las apps y revisar el resultado en los reportes de rendimiento web del panel de administración.

Revisa los datos en tu panel de administración

Hay un resumen en la página Online Store > Themes (Tienda online > Temas), y los reportes completos de LCP, INP y CLS están en Analytics > Reports. Los datos pueden llegar con hasta 36 horas de retraso, 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 carga de forma diferida las imágenes de las secciones que están 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 diferida a partir de la sección 4. Como section.index es nil en el editor de temas, compara con > 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 inmediato 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 descubren tarde.

Elimina lo que dejan las apps

Desactiva las incrustaciones de apps que no uses en Online Store > Edit theme > App embeds (Centro de ayuda de Shopify (se abre en una pestaña nueva)). Desinstalar una app elimina sus bloques, 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 menos el carrito y el checkout, y elimina los scripts que se cargan en todas partes sin necesidad.

  • Conserva el manejo de imágenes del núcleo. Desde WordPress 6.3 (publicado el 8 de agosto de 2023), el núcleo agrega fetchpriority="high" a la imagen que probablemente sea la LCP (de al menos 50 000 píxeles cuadrados de forma predeterminada) y omite la carga diferida en las tres primeras imágenes del contenido (Make WordPress Core (se abre en una pestaña nueva)). Si un plugin de optimización agrega su propia carga diferida, comprueba que excluya el banner principal 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 con un plugin y una CDN, y mantener sin caché las páginas del carrito y del checkout (documentación para desarrolladores de WooCommerce (se abre en una pestaña nueva)).
  • Revisa los fragmentos del carrito. Desde WooCommerce 7.8, el script de fragmentos del carrito (cart fragments) se carga solo donde hay un widget de carrito, pero algunos temas incluyen ese widget directamente en el código. El bloque Mini-Cart no usa los fragmentos del carrito (blog para desarrolladores de WooCommerce (se abre en una pestaña nueva)).
  • Encuentra los plugins pesados. WooCommerce sugiere Query Monitor para encontrar 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 varía, y luego sigue los datos de campo en PageSpeed Insights, en el informe de Core Web Vitals de Search Console o en los reportes de Shopify. Un escaneo gratuito te da una primera lectura en aproximadamente un minuto. El Reporte de Rendimiento ejecuta una prueba de laboratorio móvil con limitación (4G lenta, CPU 4x) y agrega datos de campo del Chrome UX Report, incluido INP cuando Google tiene suficientes datos de tu tienda.

Preguntas frecuentes

¿Las Core Web Vitals afectan el posicionamiento en Google?

Google afirma que sus sistemas de clasificación usan las Core Web Vitals, pero que una buena puntuación no garantiza los primeros lugares y que sigue mostrando el contenido más relevante aunque la experiencia en la 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 páginas y orígenes que son públicamente detectables y que tienen suficientes visitantes de Chrome elegibles. Una tienda con poco tráfico puede tener solo datos a nivel de origen, o ninguno, así que apóyate en las pruebas de laboratorio y en los reportes de tu propia plataforma.

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

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

¿Debo cargar de forma diferida todas las imágenes de productos?

No. Usa carga diferida para las imágenes que están debajo de la primera pantalla, pero carga de inmediato el banner principal y la imagen principal del producto, con fetchpriority="high" en una de ellas.

¿Por qué mis resultados en celular son peores que en computadora?

Google mide celular y computadora 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 CPU de 4x.

Fuentes

Todas las guías