Core Web Vitals para e-commerce: soluciones para LCP, INP y CLS
Las páginas de producto lentas cuestan conversiones. Aquí tienes lo que LCP, INP y CLS significan realmente para una tienda online, y las soluciones de mayor impacto para cada métrica.
Has ejecutado PageSpeed Insights en tu página de producto. Tres indicadores rojos te devuelven la mirada. La puntuación es 41. La página también carga lentamente en tu teléfono de prueba, pero no estás seguro de cuál de las tres métricas te está costando ventas — o cuál arreglar primero.
Core Web Vitals son las tres métricas de carga e interacción que Google publica para cada sitio. Afectan al ranking en los márgenes. Afectan a la conversión mucho más que eso. Para una tienda online donde cada segundo de retraso le resta confianza al botón de compra, el impacto en conversión por sí solo justifica arreglarlas, incluso antes de tener en cuenta el SEO.
Las tres métricas, brevemente
- LCP (Largest Contentful Paint) mide cuánto tarda en cargarse el elemento visible más grande — normalmente tu imagen hero de producto. Bueno: por debajo de 2,5 segundos. Pobre: por encima de 4 segundos.
- INP (Interaction to Next Paint) mide la sensación de respuesta de tu página ante toques y clics. Reemplazó a FID en marzo de 2024. Bueno: por debajo de 200 ms. Pobre: por encima de 500 ms.
- CLS (Cumulative Layout Shift) mide cuánto saltan los elementos mientras carga la página. Bueno: por debajo de 0,1. Pobre: por encima de 0,25.
La guía de web.dev sobre Core Web Vitals de Google cubre las definiciones formales; el resto de este artículo se centra en qué hacer al respecto en una tienda real.
Por qué el e-commerce sufre más que los blogs
Una entrada de blog es texto, quizá una imagen hero, quizá un embed. Una página de producto es una imagen hero, una galería de miniaturas, un widget de reseñas, un carrusel de recomendaciones, una burbuja de chat, un popup de upsell, un cajón de carrito, analítica para tres plataformas, un grabador de mapas de calor y un framework de tests A/B. Cada uno de ellos envía JavaScript. Cada uno compite por el hilo principal.
Una tienda Shopify típica en 2026 envía alguna combinación de:
- Klaviyo (captura de email, popups)
- Privy u OptinMonster (intención de salida)
- Smile.io o Loyalty Lion (widget de recompensas)
- Yotpo o Judge.me (reseñas)
- Tidio o Gorgias (chat)
- Hotjar o Microsoft Clarity (grabación de sesiones)
- GA4, Meta Pixel, TikTok Pixel (analítica)
Cada uno parece gratis cuando lo instalas. Ninguno lo es. El coste aparece primero en INP, luego en LCP, luego en tu tasa de conversión.
Soluciones de LCP para páginas de producto
LCP en una página de producto es casi siempre la imagen hero. Tres cambios en orden de impacto:
1. Sirve el formato y el tamaño correctos. Un PNG de 4000×4000 directo de tu fotógrafo de producto pesa 6 MB. La misma imagen como WebP o AVIF correctamente dimensionada a las medidas que realmente se renderizan suele estar por debajo de 150 KB. Tanto Shopify como WooCommerce manejan esto si dejas de anular su redimensionado.
2. Precarga la imagen hero. Añade una pista de precarga en <head> para que el navegador empiece a buscarla antes de parsear el resto de la página:
<link rel="preload" as="image"
href="/products/wallet-hero.webp"
imagesrcset="/products/wallet-hero-400.webp 400w,
/products/wallet-hero-800.webp 800w,
/products/wallet-hero-1200.webp 1200w"
imagesizes="(max-width: 768px) 100vw, 50vw">
3. No apliques lazy-load a imágenes por encima del pliegue. loading="lazy" en tu hero es el asesino de LCP individual más común en páginas de producto. Aplica lazy-load a miniaturas y a tomas de galería bajo el pliegue; nunca a la primera imagen visible.
Referencia: Optimizar LCP en web.dev.
Soluciones de INP para páginas de producto
INP es donde la mayoría de las tiendas lo pasan peor. El patrón es consistente: la página parece cargada, el usuario toca "Añadir al carrito" y hay un congelamiento de 600 ms antes de que pase nada. Ese congelamiento es JavaScript ejecutándose en el hilo principal.
1. Difiere scripts no críticos. Añade defer o carga con async cualquier cosa que no sea necesaria para renderizar el botón de compra. Widgets de reseñas, burbujas de chat, motores de recomendación — todos deberían cargarse después de que la página sea interactiva, no durante.
2. Audita los widgets de terceros sin piedad. La mayoría de las tiendas llevan dos widgets que hacen el mismo trabajo (dos herramientas de analítica, dos proveedores de popups). Elige uno. Quita el otro. Cada widget extra se acumula.
3. Reemplaza widgets pesados de reseñas con valoraciones renderizadas en el servidor. Un widget de reseñas que hidrata 500 reseñas en el DOM del lado del cliente está entre los 3 principales culpables de INP. Renderiza la valoración agregada y las tres principales reseñas en el servidor; carga la lista completa de reseñas de forma diferida cuando el usuario haga scroll hasta ahí.
Para tiendas basadas en Next.js / React, los docs de React sobre hidratación pesada y el SSR con streaming de Next.js son las madrigueras correctas.
Soluciones de CLS para páginas de producto
El desplazamiento de layout es el más barato de los tres de arreglar y el más vergonzoso de dejar roto. Tres cambios:
1. Establece dimensiones explícitas en cada imagen. Incluye siempre atributos width y height (o aspect-ratio en CSS) para que el navegador reserve espacio antes de que cargue la imagen:
<img src="/products/wallet.webp"
width="800" height="800"
alt="Hand-stitched leather wallet, front view">
2. Usa font-display: swap con cuidado. Un Flash of Unstyled Text desplaza el layout cuando carga la fuente personalizada. O bien precarga la fuente o usa font-display: optional para evitar swaps tardíos.
3. Reserva espacio para los embeds. Widgets de reseñas, carruseles de recomendaciones y huecos de anuncios que se inyectan encima del contenido existente provocan desplazamientos en cascada. Envuélvelos en un contenedor de altura fija mientras cargan.
Referencia: Optimizar CLS.
Cómo EshopAuditor saca esto a la luz
La puntuación CWV de EshopAuditor refleja el rendimiento de tu página de inicio, medido por Google PageSpeed Insights en las estrategias Mobile y Desktop. El resto de las páginas rastreadas se analizan en busca de estructura HTML, esquema, metadatos y problemas de SEO on-page — pero sin una ejecución de Lighthouse por página. Lighthouse por página es computacionalmente caro de ejecutar a escala; el CWV de la página de inicio es la señal indicativa del perfil de rendimiento típico de todo el sitio.
El CWV de la página de inicio es indicativo, no exhaustivo: si tu página de inicio es lenta, tus páginas de producto casi siempre son más lentas (mismo tema, mismos widgets, misma carga de scripts). Para el CWV exacto por página en todo tu catálogo, combina este informe con la vista de Core Web Vitals de Google Search Console, que usa datos de campo CrUX de usuarios reales en cada URL para la que Google tiene impresiones.
La verdad incómoda sobre CWV y el ranking
Google ha sido claro: Core Web Vitals es una señal de ranking, pero menor. Dos páginas con calidad de contenido comparable, en una consulta donde el CWV esté cerca, verán al CWV actuar como desempate. Eso es todo.
Lo que Core Web Vitals afecta de forma dramática es la tasa de conversión. Un retraso de 1 segundo en LCP no te baja de la página 1 a la página 2 de Google. Pero perjudica de forma medible la tasa de checkout — y en el tráfico de e-commerce, esa caída de conversión normalmente eclipsa cualquier subida o bajada de SEO. A lo largo de un trimestre de tráfico, la diferencia paga tus herramientas, tu inversión en anuncios y tu tiempo varias veces.
Arregla Core Web Vitals porque hacen tu tienda más rentable, no porque Google lo diga. La victoria en SEO es un extra.
Ejecuta una auditoría gratuita de tu tienda en eshopaudit.io — no se requiere registro para el primer escaneo.