Cada 100 milisegundos de retraso te cuestan ventas
Hay un número que debería estar en la pared de la oficina de todo responsable de ecommerce: 0,1 segundos. Según el estudio conjunto de Google y Deloitte publicado como “Milliseconds Make Millions”, cada 0,1 segundos de mejora en la velocidad de carga de un sitio retail aumenta las conversiones un 8%. En travel, el impacto sube al 10%. No son proyecciones teóricas: son datos observados en sitios con millones de visitantes mensuales.
Traduce ese número a tu tienda online. Si facturas 50.000 euros mensuales y tu LCP pasa de 4,2 segundos a 2,4 segundos —una mejora de 1,8 segundos—, el incremento potencial en conversiones es del orden del 15-25%. Son entre 7.500 y 12.500 euros mensuales adicionales con el mismo tráfico, el mismo catálogo y el mismo presupuesto publicitario. La única diferencia es que los usuarios completan la compra en lugar de abandonar por frustración.
Los Core Web Vitals en ecommerce tienen una particularidad que los diferencia de cualquier otro tipo de sitio web: el impacto de cada métrica se multiplica porque el recorrido del usuario implica múltiples interacciones con la página. Un usuario de un blog lee un artículo y se va. Un comprador online navega categorías, filtra productos, amplía imágenes, selecciona tallas, añade al carrito, introduce datos de envío, aplica cupones y confirma el pago. Cada uno de esos pasos es una oportunidad para que un LCP lento, un CLS inesperado o un INP deficiente provoquen el abandono.
Por qué los Core Web Vitals importan más en ecommerce
El ecommerce tiene la relación más directa entre rendimiento web y resultados de negocio. En un blog, un LCP lento puede costar una lectura. En un medio de comunicación, puede costar un clic. En una tienda online, cuesta dinero real medible en el informe de ventas del día.
Los datos de HTTPArchive de 2025 revelan que solo el 39% de los sitios ecommerce aprueba los tres Core Web Vitals simultáneamente, tres puntos por debajo de la media global del 42%. La razón es estructural: las tiendas online cargan más recursos por página que la mayoría de sitios web. Una página de categoría típica muestra entre 20 y 60 imágenes de producto, ejecuta JavaScript para filtros dinámicos, carga scripts de remarketing y analytics, muestra banners promocionales animados y conecta con sistemas de gestión de inventario en tiempo real.
Pero el argumento más poderoso no es técnico sino financiero. Vodafone documentó un aumento del 8% en ventas al mejorar su LCP un 31%. Rakuten incrementó las conversiones un 33% y los ingresos por visitante un 53% tras optimizar sus tres Core Web Vitals. NDTV redujo su tasa de rebote un 55% mejorando el LCP. Estos casos no son excepciones aisladas; son representativos de un patrón documentado por Google: la velocidad de carga es un factor de conversión directo, independiente del diseño, el precio o la oferta de productos.
Para las tiendas online en España, donde la competencia en búsquedas transaccionales como “comprar [producto] online” es cada vez más intensa, los Core Web Vitals funcionan como un factor diferenciador. Cuando dos tiendas compiten por la misma keyword con autoridad y contenido similares, Google favorece la que ofrece una mejor experiencia de usuario. Y los Core Web Vitals son la métrica objetiva que Google usa para medir esa experiencia.
Los desafíos específicos del ecommerce: imágenes, filtros y banners
Las tiendas online enfrentan problemas de Core Web Vitals que otros tipos de sitio web raramente encuentran. Estos desafíos están directamente vinculados a las funcionalidades que hacen que una tienda online sea una tienda online: catálogos visuales con decenas de imágenes, sistemas de filtrado interactivos, banners promocionales rotativos y procesos de checkout con múltiples pasos.
Imágenes de producto a escala. Un catálogo de 5.000 productos con 4 imágenes por producto genera 20.000 imágenes que necesitan estar optimizadas. Cada página de categoría muestra entre 20 y 60 de estas imágenes simultáneamente. Si cada imagen pesa 300 KB en lugar de 80 KB, una página de categoría carga 6 MB solo en imágenes. El problema se agrava porque las imágenes de producto necesitan calidad suficiente para que el usuario vea los detalles: textura de la tela, color exacto, acabado del material. La compresión agresiva que funciona para imágenes decorativas no siempre es aceptable para imágenes de producto.
Filtros dinámicos. Los filtros de categoría, talla, color, precio y marca son esenciales para la experiencia de compra, pero cada interacción con un filtro dispara una operación de JavaScript que recalcula los resultados, actualiza el DOM y en muchos casos hace una petición Ajax al servidor. Si esa operación tarda más de 200 milisegundos, el INP se degrada. Las tiendas con filtros implementados en frameworks JavaScript reactivos (React, Vue) sin optimización suelen tener INP de 300 a 500 ms.
Banners y sliders promocionales. Los banners de descuento, ofertas flash y sliders de productos destacados son omnipresentes en el ecommerce. El problema de CLS es doble: los banners que se cargan de forma asíncrona empujan el contenido hacia abajo cuando aparecen, y los sliders mueven elementos adyacentes si no tienen altura reservada. Un solo banner de oferta sin dimensiones explícitas puede generar un CLS de 0,15 a 0,25, superando por sí solo el umbral de 0,1 que Google considera aceptable.
Precios dinámicos y disponibilidad. Las tiendas que muestran precios con descuento calculados en JavaScript o que verifican disponibilidad de stock en tiempo real añaden dos problemas: el precio que se pinta inicialmente puede cambiar cuando el JavaScript se ejecuta (CLS), y la verificación de stock puede bloquear el hilo principal si no está bien implementada (INP).
Optimización de LCP en páginas de producto y categoría
El LCP en ecommerce tiene dos contextos dominantes: las páginas de categoría y las páginas de producto. Cada una tiene un elemento LCP diferente y requiere una estrategia de optimización distinta.
Páginas de categoría: El elemento LCP suele ser la primera imagen de producto visible o el banner principal de la categoría. La optimización sigue cuatro principios: servir imágenes en WebP o AVIF con compresión adaptada al tipo de imagen (lossy para fotos de producto, lossless para gráficos con texto), definir width y height en el HTML para que el navegador reserve espacio antes de la descarga, implementar srcset con al menos tres tamaños (móvil, tablet, desktop), y no aplicar loading="lazy" a las primeras 4-6 imágenes visibles en el viewport inicial.
Páginas de producto: El elemento LCP es casi siempre la imagen principal del producto. Aquí la optimización tiene un matiz adicional: la imagen LCP suele estar dentro de un componente de galería JavaScript que puede retrasar su renderizado. La solución es pre-renderizar la primera imagen como HTML estático fuera del componente de galería, con las dimensiones exactas declaradas, y dejar que JavaScript tome el control después para las funcionalidades interactivas (zoom, cambio de imagen, vista 360).
Un patrón técnico que marca la diferencia: el preload de la imagen LCP. Añadir <link rel="preload" as="image" href="producto-hero.webp"> en el <head> indica al navegador que comience a descargar la imagen LCP antes de que el parser HTML llegue al elemento <img>. En pruebas documentadas, este patrón reduce el LCP entre 0,3 y 0,8 segundos en páginas de producto.
El TTFB también es crítico para el LCP en ecommerce. Las plataformas que generan las páginas dinámicamente (WooCommerce consultando MySQL, PrestaShop procesando PHP) tienen un TTFB base de 300-600 ms sin caché. La caché de página completa reduce esto a 50-150 ms, pero requiere invalidación inteligente cuando cambian precios, stock o promociones. Las plataformas SaaS como Shopify gestionan esto automáticamente con su CDN global.
CLS en ecommerce: sliders, banners promocionales y precios dinámicos
El CLS (Cumulative Layout Shift) es la métrica más traicionera en ecommerce porque los cambios de layout que lo causan suelen ser invisibles para el equipo de desarrollo —ocurren durante la carga, cuando nadie está mirando con atención— pero son perfectamente percibidos por los usuarios, especialmente en móvil donde la pantalla es pequeña y cualquier desplazamiento de contenido desubica al usuario.
Sliders y carruseles. El slider de productos destacados o promociones es un clásico generador de CLS. El problema ocurre cuando el slider se renderiza por JavaScript después de que el HTML inicial ya se ha pintado: el espacio que ocupa el slider no existía en el layout inicial y al aparecer empuja todo lo que está debajo. La solución tiene dos partes: reservar el espacio exacto del slider con CSS antes de que JavaScript lo rellene (usando aspect-ratio o min-height en el contenedor), y si el slider carga imágenes de forma asíncrona, definir width y height en cada imagen del slider.
Banners de oferta inyectados dinámicamente. Las barras de envío gratis, las notificaciones de descuento por tiempo limitado y los avisos de stock bajo suelen inyectarse mediante JavaScript después de la carga inicial. Cada uno de estos elementos empuja el contenido hacia abajo y genera CLS. La solución es reservar el espacio para estos banners en el HTML inicial (incluso si están vacíos) o posicionarlos de forma fija (position: fixed o position: sticky) para que no afecten al flujo del documento.
Precios con descuento. Cuando el precio con descuento se calcula en JavaScript (descuentos por volumen, cupones aplicados automáticamente, precios de socio), el precio puede cambiar visualmente después de la carga inicial. Si el precio con descuento ocupa más espacio que el precio original (por ejemplo, muestra el precio tachado y el nuevo precio debajo), el contenido inferior se desplaza. La solución es renderizar ambos precios en el servidor o reservar espacio para el formato de precio más largo.
Web fonts. Las fuentes tipográficas personalizadas que no están pre-cargadas causan un efecto FOUT (Flash of Unstyled Text) o FOIT (Flash of Invisible Text) que puede generar CLS si el tamaño del texto con la fuente del sistema difiere del tamaño con la fuente personalizada. Usar font-display: swap combinado con <link rel="preload" as="font"> para las fuentes críticas minimiza este efecto.
INP en tiendas online: filtros, carrito y checkout
El INP (Interaction to Next Paint) mide la capacidad de respuesta de la página ante las interacciones del usuario. En ecommerce, donde cada interacción tiene un impacto directo en la conversión, un INP deficiente no solo es un problema técnico: es un problema de negocio. Cuando un usuario toca “Añadir al carrito” y la página tarda 350 ms en responder, la incertidumbre genera desconfianza. “¿Se ha añadido? ¿Tengo que pulsar otra vez?” Esa fracción de segundo de duda es una brecha por la que se escapan conversiones.
Filtros de categoría. Los filtros son la interacción más frecuente en páginas de categoría y una de las principales fuentes de INP deficiente. Cada cambio de filtro suele desencadenar: una consulta al servidor (si es server-side) o un recálculo del DOM (si es client-side), una actualización del listado de productos, un cambio en los contadores de filtros disponibles, y potencialmente un cambio de URL para SEO. Si todo esto ocurre de forma síncrona en el hilo principal, el INP sube a 300-500 ms. La solución es usar requestAnimationFrame o scheduler.yield() para dividir el trabajo en tareas más pequeñas, y actualizar primero la respuesta visual (feedback inmediato de que el filtro se ha aplicado) antes de procesar el resultado completo.
Botón de carrito y mini-carrito. Añadir un producto al carrito dispara una petición Ajax al servidor, una actualización del contador del carrito en el header, potencialmente una animación del mini-carrito y un recálculo de precios con impuestos. Si el JavaScript que gestiona el carrito está en el hilo principal y no está optimizado, el INP de la interacción “Añadir al carrito” puede superar los 200 ms. La optimización incluye: responder visualmente de forma inmediata (animación del botón, incremento del contador) mientras la petición al servidor se resuelve en background, y usar requestIdleCallback para operaciones no críticas como el tracking de analytics.
Proceso de checkout. El checkout es la página con mayor impacto en conversión y, paradójicamente, suele ser la peor optimizada para INP. Los campos de formulario con validación en tiempo real, los selectores de método de envío que recalculan precios, los campos de cupón que hacen peticiones al servidor y los botones de método de pago que cargan iframes de pasarelas externas contribuyen todos al INP. La estrategia es priorizar la respuesta visual inmediata en cada interacción y delegar los cálculos al servidor o a web workers fuera del hilo principal.
Benchmarks CWV por plataforma: Shopify, WooCommerce, PrestaShop
Los datos de HTTPArchive y CrUX permiten comparar el rendimiento de las principales plataformas ecommerce con datos reales de campo, no con pruebas de laboratorio.
Shopify lidera con una tasa de aprobación del 52% en los tres Core Web Vitals simultáneamente. Su ventaja es estructural: infraestructura controlada con CDN global de Cloudflare integrado, temas que pasan revisión de rendimiento antes de publicarse en el Theme Store, y un runtime JavaScript optimizado (Liquid + Alpine.js en vez de frameworks pesados). Las limitaciones: menos control sobre el servidor, dependencia de apps de terceros que pueden degradar el rendimiento, y limitaciones en personalización profunda del checkout.
WooCommerce tiene una tasa de aprobación del 31%, lastrada por la variabilidad inherente a WordPress. Los sitios WooCommerce con hosting gestionado, tema ligero (GeneratePress + WooCommerce, Kadence) y plugins optimizados pueden alcanzar el 90-95% en PageSpeed. Pero la realidad del ecosistema es que muchas tiendas WooCommerce corren sobre hosting compartido con temas multipropósito y 30+ plugins activos. La plataforma no es el problema; la configuración típica lo es.
PrestaShop registra una tasa de aprobación del 28%. Sus principales desafíos técnicos son: un frontend con dependencia histórica de jQuery que penaliza el INP, generación de páginas PHP sin caché a nivel de aplicación por defecto, y un ecosistema de módulos con control de calidad variable. PrestaShop 8 mejoró significativamente el rendimiento base, pero muchas tiendas siguen en versiones anteriores.
Magento/Adobe Commerce tiene la tasa de aprobación más baja entre plataformas enterprise (aproximadamente 22%), explicada por su complejidad arquitectónica: múltiples capas de caché (Varnish, Redis, Full Page Cache), un frontend pesado basado en RequireJS y Knockout.js (en Magento 2 Luma), y un TTFB base de 500-1.000 ms sin la stack de caché completa configurada. La nueva frontend Hyva mejora sustancialmente estos números al reemplazar todo el frontend con Alpine.js y Tailwind CSS.
La plataforma establece un suelo y un techo de rendimiento. Shopify tiene el suelo más alto (difícil hacerlo muy mal) y un techo razonablemente bueno. WooCommerce y PrestaShop tienen un suelo más bajo (fácil hacerlo mal) pero un techo potencialmente más alto con configuración experta. La elección depende de si el equipo tiene capacidad técnica para optimizar una plataforma open-source o prefiere la predictibilidad de una solución SaaS.
ROI de mejorar Core Web Vitals en ecommerce: datos reales
El retorno de inversión de optimizar Core Web Vitals en ecommerce es el argumento más sólido para convencer a la dirección de que asigne presupuesto a rendimiento web. No es un proyecto técnico abstracto: es una inversión con retorno medible en semanas.
Los estudios de caso publicados permiten construir un modelo de ROI fundamentado. El estudio de Google y Deloitte establece que cada 0,1 segundos de mejora en velocidad de carga aumenta las conversiones un 8% en retail. Aplicado a una tienda con 100.000 visitas mensuales, una tasa de conversión del 2% y un ticket medio de 60 euros: mejorar el LCP en 1 segundo (equivalente a 10 incrementos de 0,1 s) podría incrementar la tasa de conversión hasta un 2,16%. Ese 0,16% adicional sobre 100.000 visitas representa 160 conversiones adicionales al mes, o 9.600 euros de facturación extra mensual.
El coste de la optimización varía según la plataforma y el estado actual del sitio. Una auditoría de Core Web Vitals con plan de implementación cuesta entre 1.500 y 5.000 euros según la complejidad. La implementación de las mejoras (caché, optimización de imágenes, CSS/JS, hosting si es necesario) suele costar entre 3.000 y 15.000 euros en un proyecto cerrado. Si el retorno mensual es de 5.000-10.000 euros adicionales, la inversión se recupera en 1-3 meses.
Más allá del retorno financiero directo, la mejora de Core Web Vitals en ecommerce genera beneficios compuestos: mejor posicionamiento orgánico (más tráfico gratuito a largo plazo), menor tasa de rebote (más usuarios que interactúan con el catálogo), mayor engagement (más páginas vistas por sesión) y mejor experiencia en campañas de pago (los mismos anuncios generan más conversiones cuando la landing page es rápida).
Consulta nuestra guía sobre velocidad web y SEO para profundizar en la relación entre rendimiento web, posicionamiento orgánico y resultados de negocio.