Skip to content
webvise
· 6 min de lectura

Por qué la velocidad de tu tienda online te está costando ventas cada día

Las tiendas online son las que menos toleran los tiempos de carga lentos - y las que más tienen que ganar al solucionarlos. Esto es lo que muestran los datos y qué puedes hacer al respecto.

Temas

PerformanceE-CommerceWeb Development
Compartir

Una tienda que tarda 3 segundos en cargar en móvil pierde aproximadamente el 53 % de sus visitantes antes de que vean un solo producto. No es un escenario teórico - es una realidad medida a gran escala en millones de transacciones.

De los que se quedan, cada segundo adicional de carga reduce la tasa de conversión en torno a un 7 %. Para una tienda con €10.000 al mes de facturación, eso son €700 perdidos al mes por cada segundo extra de carga.

Ningún otro tipo de sitio web tiene tanto que perder con un rendimiento deficiente - y tanto que ganar al corregirlo - como una tienda online.

Los datos detrás de la velocidad

La relación entre velocidad de carga e ingresos es uno de los fenómenos mejor documentados del comercio electrónico:

Estudio / FuenteResultado
Google / Deloitte (2019)0,1 segundo más rápido → +8 % en tasa de conversión en móvil
Amazon (interno)100 ms de retraso = 1 % de pérdida de ingresos
Walmart (interno)1 segundo de mejora → +2 % en conversiones
Portent (2019)Los sitios que cargan en 1 segundo convierten 3× mejor que los que cargan en 5 segundos

Estos datos provienen de sectores distintos, períodos distintos y metodologías distintas - y todos apuntan en la misma dirección: más velocidad equivale a más ventas.

Por qué el ecommerce móvil es diferente

Más del 70 % del tráfico de ecommerce proviene hoy de dispositivos móviles. Sin embargo, el móvil convierte en torno a un 2 %, frente al 4 % aproximado en escritorio. Esta brecha - que representa miles de millones en ingresos no realizados - se explica en gran parte por la velocidad y la usabilidad en smartphone.

Las conexiones móviles no son uniformes. La cobertura 4G es irregular, especialmente en zonas rurales. Los dispositivos Android de gama media-baja - que representan una cuota significativa de los usuarios reales - tienen procesadores más lentos que se ven desbordados por páginas con mucho JavaScript. Una página de producto que carga bien en un iPhone de última generación en una ciudad puede ser prácticamente inutilizable para una parte importante de tus clientes reales.

El modo de interacción también es distinto: navegación con el pulgar, zonas de clic pequeñas, formularios de pago diseñados para escritorio. Todo ello genera fricción que se agrava aún más cuando la página tarda en responder.

  • Más del 70 % del tráfico ecommerce viene del móvil, que convierte a la mitad que el escritorio
  • La cobertura 4G varía mucho según la ubicación y la calidad del dispositivo
  • Los dispositivos de gama baja no son un caso marginal - representan un segmento real y significativo
  • La fricción en el proceso de pago en móvil se amplifica cuando la página responde con lentitud

Core Web Vitals: qué significan para tu tienda

Google mide el rendimiento de los sitios web a través de un conjunto de métricas llamadas Core Web Vitals. Cada una corresponde directamente a una experiencia que viven tus clientes al comprar:

MétricaQué mideRelevancia en la tiendaBuenoMejorableMalo
LCP (Largest Contentful Paint)Tiempo hasta que el contenido principal es visibleImagen del producto principal o banner hero< 2,5 s2,5 s – 4 s> 4 s
INP (Interaction to Next Paint)Velocidad de respuesta a clics y toquesBotón añadir al carrito, filtros, cambio de cantidad< 200 ms200 ms – 500 ms> 500 ms
CLS (Cumulative Layout Shift)Inestabilidad visual durante la cargaListado de productos que se desplaza al cargar imágenes< 0,10,1 – 0,25> 0,25

Los sitios que obtienen una puntuación verde en las tres métricas reciben una ventaja en el posicionamiento de Google. Los que no la superan son penalizados. Esto significa que una tienda lenta queda sancionada dos veces: menos visibilidad orgánica y menor tasa de conversión en el tráfico que sí llega.

Un mal INP es especialmente perjudicial en ecommerce. Si un cliente pulsa "Añadir al carrito" y no ocurre nada durante medio segundo, pulsará de nuevo - o pensará que la tienda está rota y se irá.

WooCommerce y el problema de los plugins

WooCommerce impulsa una gran parte de las tiendas online - y también es una de las plataformas con mayor penalización de rendimiento a medida que el sitio crece. Una tienda WooCommerce funcional suele ejecutar entre 50 y 80 plugins. Cada uno añade peticiones HTTP, tiempo de ejecución de JavaScript y sobrecarga de CSS.

El resultado a nivel de página:

  • Las páginas de producto transfieren habitualmente entre 4 y 8 MB de datos en la primera carga
  • Una página de producto estándar en WooCommerce puede generar más de 100 consultas a la base de datos
  • Los bundles de JavaScript de varios plugins suelen bloquear el renderizado
  • Los scripts de terceros (reseñas, chat, analytics) alargan aún más las cadenas de peticiones
  • LCP medio de WooCommerce en móvil: entre 4 y 6 segundos

Un LCP de entre 4 y 6 segundos se sitúa claramente en la zona "mala" de la escala de Google - y muy por encima del umbral de abandono de la mayoría de los usuarios móviles. Los plugins de caché alivian el síntoma, pero no cambian la arquitectura subyacente que genera el problema.

El problema de las consultas a la base de datos es estructural. WooCommerce construye las páginas de producto dinámicamente en cada solicitud - extrayendo datos de producto, reglas de precios, estado del inventario, productos relacionados y estado del carrito cada vez. Con más de 100 consultas por carga, incluso el hosting más rápido tiene un techo.

Cómo es una arquitectura de ecommerce optimizada para el rendimiento

Una arquitectura headless commerce separa el frontend - lo que tus clientes ven e interactúan - del backend de comercio que gestiona productos, inventario y pedidos. El frontend se desarrolla en Next.js y se pre-renderiza en el momento del build. El backend (Shopify, BigCommerce o WooCommerce headless) gestiona las transacciones mediante API.

La diferencia de rendimiento es estructural, no cosmética:

  • Páginas de producto estáticas/ISR: pre-renderizadas en el build y servidas directamente desde un CDN edge - sin PHP, sin consultas a la base de datos al cargar
  • Imágenes de producto con carga diferida: las imágenes fuera de pantalla solo cargan cuando se necesitan, en formatos modernos (WebP, AVIF) que pesan entre un 30 y un 50 % menos
  • JavaScript mínimo: sin jQuery, sin Bootstrap completo, bundles con tree-shaking que solo incluyen el código que cada página realmente necesita
  • Incremental Static Regeneration: las páginas de producto se actualizan automáticamente cuando cambian el inventario o los precios, sin rebuild completo
MétricaWooCommerce (típico)Next.js Headless (típico)
LCP (móvil)4–6 segundosMenos de 1,5 segundos
Time to Interactive6–10 segundosMenos de 2 segundos
Peso de página (página de producto)4–8 MBMenos de 500 KB
Puntuación Lighthouse (móvil)25–4590–98

No son casos ideales teóricos. Son resultados consistentes observados en proyectos de ecommerce en producción con stacks modernos.

El cálculo de conversión para tu tienda

No tienes que fiarte de estudios agregados. Puedes hacer el cálculo directamente para tu tienda.

El principio es sencillo:

  • Toma tu facturación mensual actual
  • Estima tu tasa de conversión actual (pedidos ÷ sesiones)
  • Aplica la mejora esperada gracias a una mayor velocidad de carga
  • Calcula el incremento de ingresos resultante

Ejemplo: una tienda con €15.000/mes de facturación y una tasa de conversión del 1,5 %. Tras un rebuild de rendimiento, la tasa sube al 2,1 % - una mejora realista respaldada por los datos de investigación. Facturación mensual al 2,1 % con el mismo tráfico: €21.000. Son €6.000 más de ingresos al mes con el mismo número de visitantes.

Incluso una mejora más conservadora - del 1,5 % al 1,9 % - representa €4.000 más al mes. A ese ritmo, un rebuild de rendimiento se amortiza en pocas semanas.

El cálculo funciona a cualquier nivel de facturación. Una tienda de €5.000/mes que gana 0,5 puntos en la tasa de conversión añade €1.667/mes. Una tienda de €50.000/mes gana €16.667/mes con la misma mejora.

Qué medir primero

Antes de hacer ningún cambio, establece tu punto de partida. Cuatro herramientas cubren lo esencial:

  • Google PageSpeed Insights: introduce la URL de una página de producto (no solo la portada) y obtén una puntuación de 0 a 100 en móvil. Por debajo de 50 es urgente. Por debajo de 30 significa que los clientes están abandonando activamente por la lentitud.
  • Google Search Console → Core Web Vitals: muestra datos de usuarios reales, no condiciones de laboratorio. Si tienes URLs en rojo aquí, son pérdidas de ingresos activas en este momento.
  • Lighthouse (Chrome DevTools): ejecútalo en modo incógnito sobre tu página de producto. Comprueba el elemento LCP - ¿es la imagen principal del producto? ¿Está marcada como carga diferida? No debería estarlo.
  • Pestaña Red (Chrome DevTools): ordena las peticiones por tamaño. Busca imágenes sin comprimir, scripts que bloquean el renderizado y peticiones de terceros que alargan el tiempo de carga.

Presta especial atención a tu elemento LCP. Si tu imagen de producto principal tiene carga diferida - algo frecuente en los themes de WooCommerce - ese único cambio (eliminar el atributo lazy-load de la primera imagen visible) puede mejorar el LCP entre 1 y 2 segundos de inmediato.

Mejoras rápidas antes de un rebuild completo

Si un rebuild completo no está en el horizonte inmediato, estas acciones pueden mejorar el rendimiento dentro de tu configuración actual:

  • Compresión de imágenes y conversión a WebP: convertir las imágenes de producto a WebP puede reducir su peso entre un 40 y un 60 %. Herramientas como Imagify o ShortPixel lo hacen automáticamente.
  • Eliminar plugins sin usar: haz una auditoría de tus plugins. Cada plugin instalado - incluso los desactivados - genera sobrecarga. Elimina todo lo que no sea activamente necesario.
  • Activar caché de páginas: WP Rocket o W3 Total Cache reduce el coste de la generación dinámica de páginas. No resuelve la arquitectura, pero mitiga el impacto en visitas repetidas.
  • Mejorar el hosting: el hosting compartido impone un techo de rendimiento difícil de superar. Migrar a un hosting WordPress gestionado (Kinsta, WP Engine, Cloudways) suele añadir entre 10 y 20 puntos en Lighthouse.
  • Diferir el JavaScript no crítico: la mayoría de los themes cargan todos los scripts en cada página. Diferir los scripts que no son necesarios en la carga inicial reduce el tiempo de bloqueo del renderizado.

Estas acciones prolongan la vida útil de un sitio existente y pueden llevar una puntuación de 35 a 55. Pero no cambian el techo estructural. Una tienda WooCommerce con una pila completa de plugins, generación dinámica de páginas y base de datos compartida no alcanzará nunca 85+ en móvil, independientemente de la cantidad de configuración que se haga.

Para tiendas con una facturación mensual importante, son medidas de transición. La solución estructural - un rebuild headless - es lo que mueve el marcador de forma permanente.

Cuándo un rebuild de rendimiento tiene sentido financiero

La regla aproximada: si tu tienda factura más de €5.000/mes y tu puntuación PageSpeed en móvil está por debajo de 60, un rebuild de rendimiento casi seguramente se amortizará en menos de 6 meses solo con las ganancias en conversión.

Con €10.000/mes y una mejora típica de 0,4 a 0,6 puntos en la tasa de conversión tras el rebuild, el incremento mensual es de €400 a €600. Para un coste de rebuild de €3.000 a €5.000, la inversión se recupera en 6 a 10 meses - antes de contar cualquier mejora en posicionamiento orgánico gracias a mejores Core Web Vitals.

Las tiendas que superan €20.000/mes con malas puntuaciones de rendimiento están dejando cantidades significativas sobre la mesa cada mes que pasan sin actuar. El período de retorno suele ser inferior a 3 meses.

Para ver exactamente dónde se encuentra tu tienda, obtén un informe de salud gratuito en webvise.io/wp-health-report. Analiza tus Core Web Vitals, identifica tus principales problemas de rendimiento y te da una imagen clara de lo que un rebuild cambiaría en la práctica. Sin registro.