Un sitio que tarda 3 segundos en cargar en móvil pierde aproximadamente el 53 % de los visitantes móviles antes de que el contenido del producto sea visible (según los datos publicados por Google sobre umbrales de abandono en móvil).
De los que permanecen, cada segundo adicional de carga se correlaciona con una caída de conversión de aproximadamente el 7 % según múltiples estudios de comercio electrónico (Akamai, Google, Portent). Para una tienda con €10.000 al mes de ingresos, eso equivale a €700 mensuales perdidos por cada segundo extra que tardan sus páginas en cargar.
Ningún otro tipo de sitio web tiene tanto que perder por un rendimiento deficiente, ni tanto que ganar al solucionarlo, como una tienda de ecommerce.
Los números detrás de la velocidad
La relación entre la velocidad de página y los ingresos ha sido ampliamente estudiada. Los resultados son consistentes entre sectores y períodos:
| Estudio / Fuente | Conclusión |
|---|---|
| Google / Deloitte (2019) | Una mejora de 0,1 segundos produce un incremento del 8 % en la tasa de conversión en móvil |
| Amazon (interno) | Cada 100 ms de retraso equivale a un 1 % de pérdida de ingresos |
| Walmart (interno) | 1 segundo de mejora produce un aumento del 2 % en conversiones |
| Portent (2019) | Los sitios que cargan en 1 segundo convierten 3 veces mejor que los que cargan en 5 segundos |
No son hallazgos excepcionales en condiciones favorables. Provienen de datos reales a gran escala con millones de transacciones. La dirección es siempre la misma: más velocidad equivale a más ingresos.
Por qué el ecommerce en móvil es diferente
Más del 70 % del tráfico de ecommerce proviene ahora de dispositivos móviles. Sin embargo, el móvil convierte a aproximadamente el 2 %, frente al 4 % del escritorio. Esa brecha, que representa miles de millones en ingresos no realizados en todo el sector, se explica en gran medida por la velocidad y la usabilidad en móvil.
Las conexiones móviles no son uniformes. La cobertura 4G es irregular, especialmente en zonas rurales. Los dispositivos Android de gama media y baja, que representan una parte considerable del mercado, tienen procesadores más lentos que tienen dificultades con páginas con mucho JavaScript. Una página de producto que carga de forma aceptable en un iPhone nuevo en el centro de la ciudad puede resultar prácticamente inutilizable para una parte significativa de sus clientes reales.
El modelo de interacción también es distinto. La navegación en la zona del pulgar, los objetivos de toque pequeños y los formularios de pago diseñados para escritorio añaden fricción. Cuando esa fricción se combina con una página de carga lenta, las tasas de abandono se multiplican rápidamente.
- Más del 70 % del tráfico de ecommerce es móvil, pero convierte aproximadamente a la mitad que el escritorio
- Las conexiones 4G varían significativamente según la ubicación y la calidad del dispositivo
- Los dispositivos de gama baja representan una gran parte de los usuarios reales, no son casos extremos
- La fricción en el proceso de pago en móvil se amplifica cuando la página tarda en responder
Core Web Vitals y lo que significan para su tienda
Google mide el rendimiento del sitio a través de un conjunto de métricas llamadas Core Web Vitals. Cada una se corresponde directamente con algo que sus clientes experimentan al comprar:
| Métrica | Qué mide | Relevancia para ecommerce | Bueno | Necesita mejora | Deficiente |
|---|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Tiempo hasta que el contenido principal es visible | La imagen principal del producto o el banner destacado | Menos de 2,5 s | 2,5 s a 4 s | Más de 4 s |
| INP (Interaction to Next Paint) | Velocidad de respuesta de la página a clics y toques | Botón de añadir al carrito, filtros, cambios de cantidad | Menos de 200 ms | 200 ms a 500 ms | Más de 500 ms |
| CLS (Cumulative Layout Shift) | Cuánto se desplaza la página mientras carga | Listados de productos que se mueven al cargar imágenes | Menos de 0,1 | 0,1 a 0,25 | Más de 0,25 |
Los sitios que obtienen verde en los tres Core Web Vitals reciben una mejora de posicionamiento en los resultados de búsqueda de Google. Los que no los cumplen son penalizados. Esto significa que una tienda lenta pierde dos veces: menor visibilidad orgánica y menor tasa de conversión del tráfico que sí llega.
Una puntuación deficiente de INP en un sitio de ecommerce es especialmente dañina. Si un cliente toca «Añadir al carrito» y no ocurre nada durante medio segundo, muchos volverán a tocar o asumirán que el sitio no funciona y se irán.
WooCommerce y el problema de los plugins
WooCommerce impulsa una gran parte de las tiendas de ecommerce y es también una de las plataformas con mayores desafíos de rendimiento a escala. Una tienda WooCommerce en funcionamiento suele operar con 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 de WooCommerce puede generar más de 100 consultas a la base de datos
- Los paquetes de JavaScript de múltiples plugins bloquean con frecuencia el renderizado
- Los scripts de terceros (reseñas, chat en vivo, analítica) añaden cadenas de peticiones adicionales
- El LCP de WooCommerce en móvil oscila habitualmente entre 4 y 6 segundos en las auditorías de webvise; los resultados varían según el tema y la selección de plugins.
El rango de 4 a 6 segundos de LCP se sitúa en la zona «deficiente» de la escala de Google y supera el umbral de abandono para la mayoría de los usuarios móviles. Los plugins de caché reducen 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 de forma dinámica en cada petición: extrae datos del producto, reglas de precios, estado del inventario, productos relacionados y estado del carrito de la base de datos cada vez. Con más de 100 consultas por carga de página, incluso un hosting rápido tiene un techo.
Cómo es una arquitectura de ecommerce optimizada para el rendimiento
Una arquitectura de comercio headless separa el frontend, lo que sus clientes ven e interactúan, del backend de comercio que gestiona productos, inventario y pedidos. El frontend se construye en Next.js y se pre-renderiza en el momento de la compilación. 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 compilación y servidas directamente desde un CDN edge. Sin PHP, sin consultas a base de datos en la carga.
- Imágenes de producto con carga diferida: las imágenes fuera de pantalla se cargan solo cuando se necesitan, en formatos de nueva generación (WebP, AVIF) que son entre un 30 y un 50 % más ligeros que los JPEG equivalentes a calidad comparable (mediciones de Cloudinary y Web.dev).
- JavaScript mínimo: sin jQuery, sin Bootstrap completo, paquetes tree-shaken que solo incluyen el código que cada página necesita realmente.
- Incremental Static Regeneration: las páginas de producto se actualizan automáticamente cuando cambia el inventario o los precios, sin necesidad de una recompilación completa.
| Métrica | WooCommerce (típico) | Next.js Headless (típico) |
|---|---|---|
| LCP (móvil) | 4-6 segundos | Menos de 1,5 segundos |
| Time to Interactive | 6-10 segundos | Menos de 2 segundos |
| Peso de página (producto) | 4-8 MB | Menos de 500 KB |
| Puntuación Lighthouse (móvil) | 25-45 | 90-98 |
Estos rangos reflejan resultados típicos de las auditorías de webvise; los resultados dependen del tema, el conjunto de plugins, el peso de las imágenes y los scripts de terceros.
El cálculo de conversión para su tienda
Realice el cálculo para su propia tienda.
El marco es sencillo:
- Tome sus ingresos mensuales actuales
- Estime su tasa de conversión actual (pedidos ÷ sesiones)
- Aplique la mejora esperada por un incremento de velocidad
- Calcule el aumento de ingresos resultante
Escenario ilustrativo: una reconstrucción de rendimiento que eleva la conversión del 1,5 % al 2,1 % en una tienda con €15.000/mes de ingresos sobre el mismo tráfico se traduce en aproximadamente €6.000/mes de ingresos adicionales con un AOV de €100. Los resultados reales dependen del punto de partida.
Incluso una mejora más conservadora puede compensar significativamente el coste de la reconstrucción; el período de recuperación depende del volumen de tráfico y del AOV.
El cálculo funciona a cualquier nivel de ingresos. Una tienda con €5.000/mes que gana 0,5 puntos porcentuales en conversión añade €1.667/mes. Una tienda con €50.000/mes que obtiene la misma mejora gana €16.667/mes.
Qué medir primero
Antes de realizar cualquier cambio, establezca su punto de partida. Cuatro herramientas cubren el terreno:
- Google PageSpeed Insights: introduzca la URL de su página de producto (no solo la página de inicio) y obtenga 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 velocidad.
- Google Search Console → Core Web Vitals: muestra datos de usuarios reales procedentes de visitantes reales, no de condiciones de laboratorio. Si hay URLs en rojo, son pérdidas de ingresos en tiempo real.
- Lighthouse (Chrome DevTools): ejecútelo en modo incógnito en su página de producto. Compruebe el elemento LCP: ¿es la imagen principal del producto? ¿Está marcado con carga diferida? No debería estarlo.
- Pestaña de Red (Chrome DevTools): ordene las peticiones por tamaño. Busque imágenes grandes sin comprimir, scripts que bloquean el renderizado y peticiones de terceros que aumentan el tiempo de carga.
Preste especial atención al elemento LCP. Si la imagen principal del producto tiene carga diferida (algo habitual en las configuraciones de WooCommerce basadas en temas), ese único cambio, eliminar el atributo lazy-load de la primera imagen visible, puede mejorar el LCP entre 1 y 2 segundos de forma inmediata.
Mejoras rápidas antes de una reconstrucción completa
Si una reconstrucción completa no está en la agenda inmediata, estos cambios pueden mejorar el rendimiento dentro de la configuración actual:
- Compresión de imágenes y conversión a WebP: convertir las imágenes de producto a WebP puede reducir el peso de imagen entre un 40 y un 60 %. Herramientas como Imagify o ShortPixel lo gestionan automáticamente.
- Eliminar plugins no utilizados: realice una auditoría de plugins. Cada plugin instalado, incluso los desactivados, añade sobrecarga. Elimine todo lo que no sea necesario activamente.
- Activar el caché de páginas: WP Rocket o W3 Total Cache reduce el coste de la generación dinámica de páginas. No corrige la arquitectura, pero reduce el impacto en las visitas repetidas.
- Mejorar el hosting: el hosting compartido impone un techo duro al rendimiento. 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 temas cargan todos los scripts en cada página. Diferir los scripts que no se necesitan en la carga inicial reduce el tiempo de bloqueo del renderizado.
Estos cambios prolongan la vida útil de un sitio y pueden mover una puntuación de 35 a 55. No alteran el techo estructural. Una tienda WooCommerce con la pila completa de plugins, generación dinámica de páginas y base de datos compartida no alcanzará 85 o más en móvil independientemente del trabajo de configuración realizado.
Para tiendas con ingresos mensuales importantes, estas son tácticas de aplazamiento. La solución estructural, una reconstrucción headless, es la que mueve el marcador de forma permanente.
Cuándo tiene sentido financiero una reconstrucción de rendimiento
La regla aproximada: si su tienda genera más de €5.000/mes y su puntuación de PageSpeed en móvil es inferior a 60, una reconstrucción de rendimiento suele recuperar su coste en 6 meses a este nivel de tráfico. Se trata de una heurística, no de una garantía.
Con €10.000/mes y una mejora típica de la tasa de conversión previa a la reconstrucción de 0,4 a 0,6 puntos porcentuales, el incremento mensual es de €400-600. Un coste de reconstrucción de €3.000-5.000 se recupera en 6 a 10 meses, sin tener en cuenta ninguna mejora en los rankings de búsqueda orgánica por mejores puntuaciones de Core Web Vitals.
Las tiendas por encima de €20.000/mes con puntuaciones de rendimiento deficientes tienen una oportunidad de conversión no realizada considerable cada mes. La ventana de recuperación suele ser inferior a 3 meses.
Para ver exactamente dónde se encuentra su tienda, obtenga un informe gratuito de salud web en webvise.io/wp-health-report. Analiza sus Core Web Vitals, identifica sus problemas de rendimiento de mayor impacto y ofrece una imagen clara de lo que una reconstrucción cambiaría realmente. Sin registro requerido.