Core Web Vitals en una tienda online: qué rompe LCP, INP y CLS en fichas y categorías

En una tienda online, las Core Web Vitals se juegan en las plantillas: ficha, categoría y portada. Lo que más las rompe es la foto principal con carga diferida (LCP), las imágenes y banners sin hueco reservado (CLS) y los scripts de terceros en filtros y botones (INP). Google las da por buenas con LCP ≤ 2,5 s, INP ≤ 200 ms y CLS ≤ 0,1.

Para comprobarlo en tu web: Tiendas online

Esta guía se queda con lo que es propio de una tienda; el resto del trabajo está en la guía de SEO para tiendas online. Qué mide cada métrica en cualquier web está en la guía general de Core Web Vitals, y cómo leer el informe, en la de PageSpeed Insights. Un aviso de interés: este blog es de SmoothSeen, una herramienta de auditoría web que mide el posicionamiento en buscadores y en asistentes de IA.

Los umbrales, aplicados a una tienda

Cada métrica mide una parte de la experiencia: la carga (LCP), la interactividad (INP) y la estabilidad visual (CLS)1. Google fija para cada una un umbral de «buena» y otro a partir del cual es «mala»; entre medias, «necesita mejorar»2. La última columna es lo que suele haber detrás en una tienda:

El valor que cuenta es el percentil 75 de las visitas, por separado en móvil y en ordenador1: una plantilla pasa si tres de cada cuatro visitas tienen una experiencia buena. Y la métrica de respuesta es INP, que sustituyó a FID como Core Web Vital el 12-03-20243; una guía de tiendas que aún hable de FID está desfasada.

¿Por qué una tienda se mide por plantillas y no por fichas?

Porque casi ninguna ficha tiene datos de campo propios. Los datos de campo salen del informe CrUX (Chrome User Experience Report), que solo incluye páginas públicas y con un mínimo de visitantes; Google no publica ese mínimo4. Una ficha nueva, o una de las cientos que reciben pocas visitas, no llega.

Cuando una URL no tiene datos suficientes, PageSpeed Insights recurre a los de todo el origen, es decir, el dominio entero2. Search Console, por su parte, agrupa en su informe de Core Web Vitals las URL que ofrecen una experiencia parecida, y el estado de cada grupo es el de su peor métrica5: un grupo con LCP bueno y CLS malo sale como «malo».

Para una tienda, eso tiene tres consecuencias prácticas:

1. Lo que ves para una ficha puede ser la media del dominio. Si la portada es rápida y las fichas lentas, la media lo disimula.
2. Los grupos de Search Console coinciden casi siempre con las plantillas. Un grupo «malo» con cientos de URL de producto es la plantilla de ficha, no cientos de problemas.
3. Un arreglo se confirma a las cuatro semanas. Al validar una corrección, Search Console abre un seguimiento de 28 días5, el mismo periodo que usan los datos de campo de PageSpeed Insights2.

Si tu dominio tampoco tiene datos de campo, trabaja con el laboratorio de PageSpeed Insights, que simula la carga con Lighthouse2, sobre una URL de cada plantilla.

¿Qué rompe cada métrica en una tienda online?

Las plantillas de una tienda fallan casi siempre en los mismos sitios. Esta tabla los ordena por métrica, con su fuente:

Arreglos por orden de impacto

El orden empieza por lo que se arregla en la plantilla con poco esfuerzo y termina por lo que exige más trabajo técnico. Mide cada cambio en el laboratorio antes y después, y confírmalo en los datos de campo al cabo de unas semanas.

1. Quita la carga diferida de la imagen principal. En la ficha, la foto del producto; en la categoría, las primeras de la rejilla. El estudio de web.dev sobre la carga diferida concluye que diferir solo las imágenes de debajo del primer pantallazo revierte por completo el empeoramiento del LCP12.
2. Da prioridad a esa imagen con fetchpriority="high"6. En una prueba de laboratorio de Google Flights, marcar la imagen de fondo con prioridad alta bajó el LCP de 2,6 a 1,9 segundos13.
3. Pon width y height a todas las imágenes, o reserva su hueco con aspect-ratio en CSS14. Formatos, tamaños y compresión de las fotos de producto están en la guía para optimizar imágenes web.
4. Reserva el espacio de lo que llega tarde (banners, avisos, sellos, widgets de reseñas) con min-height o aspect-ratio14.
5. Revisa los scripts de terceros. Carga con async o defer lo que no hace falta para comprar, quita lo que no aporta y controla quién puede añadir etiquetas al gestor9. Exige decidir con marketing qué se queda.
6. Trocea las tareas largas. Cualquier tarea de más de 50 ms es una tarea larga; ceder el control al navegador entre trozos, por ejemplo con scheduler.yield(), deja que responda antes al usuario10.
7. Para el carrusel automático o, si lo mantienes, que se detenga al pasar el ratón, y mueve las diapositivas con transform en vez de left o top7.
8. Mejora el servidor: caché de página, CDN y un alojamiento a la altura del tráfico. Es lo más caro, así que conviene dejarlo para después de lo anterior.

Cómo queda en la plantilla

Los cuatro primeros puntos se escriben una vez en el tema y llegan a todas las fichas. Este fragmento es un ejemplo comentado; las rutas, los tamaños y las clases son ilustrativos:

<!-- FICHA: la foto principal suele ser el elemento del LCP.
     Sin loading="lazy", con prioridad alta y con sus dimensiones. -->
<img src="/img/cafetera-moka-6-frontal.webp"
     alt="Cafetera italiana de aluminio para 6 tazas, vista frontal"
     width="800" height="800" fetchpriority="high">

<!-- CATEGORÍA: las imágenes de la primera fila se cargan normal;
     a partir de la fila que queda fuera de la pantalla, en diferido. -->
<img src="/img/producto-13.webp" alt="Cafetera eléctrica de goteo, 10 tazas"
     width="400" height="400" loading="lazy">

<!-- WIDGET DE RESEÑAS que se inyecta tarde: hueco reservado antes de que llegue. -->
<div class="resenas-producto"></div>

/* El alto se toma del widget ya cargado, medido en móvil. */
.resenas-producto { min-height: 320px; }

Si tu plataforma añade loading="lazy" a todas las imágenes por defecto, el primer punto suele exigir un ajuste del tema o una opción del módulo de imágenes: compruébalo en el HTML de la ficha publicada, no en el panel.

¿Las Core Web Vitals son un factor de posicionamiento?

Sí, pero de los que desempatan. Google dice que las Core Web Vitals se usan en sus sistemas de clasificación y recomienda tenerlas en buen estado15. En la misma página añade dos matices que conviene leer juntos15:

• Su búsqueda siempre intenta mostrar el contenido más relevante, aunque la experiencia de página sea mediocre.
• Un buen resultado en el informe de Core Web Vitals no garantiza aparecer arriba. Donde hay mucho contenido útil disponible, una buena experiencia puede contribuir al éxito.

Para una tienda, eso significa que una ficha rápida sin descripción propia no gana a una ficha algo más lenta que responde mejor a lo que busca el comprador. Las fichas, las categorías y el marcado van primero; la velocidad, después. Lo que necesita el marcado de una ficha está en la guía de schema Product para fichas de producto.

Lo que la nota de PageSpeed no te dice

La puntuación de 0 a 100 de PageSpeed Insights es de laboratorio y cambia en cada prueba, con la red, el equipo que mide y la competencia por recursos2. En una tienda hay dos fuentes de variación más, que la documentación de Lighthouse cita: las pruebas A/B y los anuncios que cambian en cada carga16.

Además, esa nota no es la evaluación de las Core Web Vitals. Según la documentación de Lighthouse, la métrica que más pesa en ella es TBT, el tiempo de bloqueo total (30 %), seguida de LCP y CLS (25 % cada una)16, y TBT es una métrica de laboratorio. Dos reglas para no perseguir fantasmas:

• Decide con los datos de campo, por plantilla. La nota sirve para diagnosticar.
• Repite la prueba de laboratorio varias veces y quédate con la mediana: Lighthouse calcula que la de cinco ejecuciones es el doble de estable que una sola17.

SmoothSeen incluye la velocidad con las Core Web Vitals, de laboratorio y de campo cuando PageSpeed Insights los tiene, en el informe de cada página que analiza, junto al resto de comprobaciones de posicionamiento web. Analiza una página cada vez, así que para una tienda conviene pasarle una URL de cada plantilla; no sustituye al informe de Core Web Vitals de Search Console.

Preguntas frecuentes

¿Qué página de la tienda conviene medir primero?

Una ficha de producto y una categoría de las que más tráfico reciben, en móvil. Son las plantillas que más URL comparten: un fallo en ellas se repite en todo el catálogo, y un arreglo también. Después, la portada si tiene carrusel. Mira en Search Console qué grupo de URL sale peor y empieza por la plantilla que hay detrás.

¿Los widgets de reseñas, chat y publicidad empeoran las Core Web Vitals?

Pueden empeorar dos. Si se inyectan tarde sin hueco reservado, desplazan el contenido y suben el CLS; si cargan mucho JavaScript en el hilo principal, retrasan la respuesta a los clics y suben el INP. Reserva su espacio con CSS, cárgalos con async o defer cuando no hagan falta para comprar y quita los que nadie usa.

¿Por qué mi tienda no tiene datos de campo?

Porque el informe CrUX solo incluye páginas y dominios públicos con un mínimo de visitantes, que Google no publica. Si una ficha no llega, PageSpeed Insights usa los datos de todo el dominio; si el dominio tampoco llega, solo verás datos de laboratorio. Mientras tanto, mide una URL de cada plantilla en el laboratorio y repite la prueba varias veces.

¿Las Core Web Vitals son un factor de posicionamiento para una tienda?

Sí. Google dice que sus sistemas de clasificación las usan, pero también que siempre intenta mostrar el contenido más relevante aunque la experiencia de página sea mediocre, y que un buen resultado no garantiza las primeras posiciones. En una tienda, la descripción propia, los datos de producto y una buena estructura del catálogo pesan antes que la velocidad.

Qué hacer ahora

Pasa PageSpeed Insights a una ficha y a una categoría de tu tienda, mira qué métrica falla en el bloque de campo y aplica los arreglos en el orden de la lista, empezando por la plantilla. Cuando esté resuelta, vuelve a la guía de SEO para tiendas online para el resto del trabajo.