Por qué tu WooCommerce mayorista carga lento (y qué medir antes de migrar)

Cuando una tienda mayorista carga lento, la primera reacción suele ser la misma: hay que migrar. Cambiar de WooCommerce a otra plataforma, o de un theme a otro, o de un hosting compartido a uno que promete ser más rápido. Es una decisión cara, lenta y arriesgada, y en la mayoría de los casos que revisamos no era necesaria. La tienda no era lenta por WooCommerce. Era lenta por una causa concreta que nadie había medido.

WooCommerce mueve catálogos de decenas de miles de productos sin problema. Lo que lo vuelve lento casi siempre es una combinación de hosting mal dimensionado, una base de datos sin mantener y plugins que cargan más de lo que aportan. Antes de tocar nada, conviene saber dónde se va el tiempo.

Medir antes de diagnosticar

La métrica que más se confunde es la velocidad. Una página puede sentirse lenta por el servidor o por el navegador, y son problemas distintos con soluciones distintas. El número que separa ambos mundos es el TTFB (time to first byte): cuánto tarda el servidor en empezar a responder.

• TTFB alto (sobre 600 ms): el problema está en el servidor — PHP, base de datos, hosting o falta de caché. Migrar de theme no lo arregla.
• TTFB bajo pero render lento: el problema está en el frontend — imágenes pesadas, scripts de plugins, CSS sin optimizar.

Con eso ya sabes en qué mitad mirar. Un primer barrido honesto lo da una prueba de carga simple desde Chile (no desde un servidor en Estados Unidos, que falsea el resultado) y una revisión del servidor bajo concurrencia real, no con una sola visita.

Las causas reales, en orden de frecuencia

En las tiendas mayoristas que auditamos, los culpables se repiten. Vale la pena revisarlos en este orden porque los primeros explican la mayor parte del tiempo perdido.

Hosting mal dimensionado

Un plan compartido que aguanta un blog no aguanta un catálogo B2B con vendedores trabajando en simultáneo. El síntoma es claro: la tienda anda bien de madrugada y se arrastra a media mañana. No es WooCommerce, es que el servidor se queda sin CPU y sin memoria cuando hay carga. Un VPS bien dimensionado o un hosting administrado para WooCommerce suele resolver más que cualquier optimización de código.

Base de datos sin mantener

Aquí está el problema más invisible y más común. La tabla wp_options guarda datos que WordPress carga en cada request: los autoloaded options. Plugins mal escritos —y plugins que se desinstalaron pero dejaron basura— inflan esa tabla a varios megabytes que se leen en cada página. Cuando los autoloaded options pasan de 1 MB, cada visita paga ese costo.

A eso se suman las queries lentas: búsquedas de productos sin índice, metadatos consultados en bucle, transients huérfanos. En catálogos grandes, una búsqueda sin un índice adecuado obliga a la base de datos a recorrer la tabla entera de metadatos cada vez. El registro de slow queries de MySQL te dice exactamente cuáles son; no hay que adivinar.

Plugins que pesan

No es la cantidad de plugins, es lo que cada uno carga. Un page builder o un plugin de sliders puede inyectar varios cientos de kilobytes de CSS y JavaScript en todas las páginas, incluso en las que no se usa. La pregunta correcta no es cuántos plugins hay, sino cuánto agrega cada uno al peso de la página y al tiempo de PHP. Un plugin de 50 dólares que reemplaza tres mal hechos suele ser más rápido y más barato de mantener.

Imágenes sin optimizar

Un catálogo mayorista con miles de fichas multiplica el problema de imágenes por miles. Subir fotos de 3 MB en JPG cuando deberían pesar 80 KB en WebP es la diferencia entre una grilla que carga al instante y una que se descuelga. La optimización en formato moderno, con tamaños correctos y carga diferida, no toca WooCommerce y mejora la experiencia de inmediato.

Sin caché de objetos ni CDN

WooCommerce repite las mismas consultas a la base de datos una y otra vez. Un object cache con Redis guarda esos resultados en memoria y descarga la base de datos de forma notable, sobre todo en el panel de administración y en el checkout, que no se pueden cachear como páginas estáticas. Y una CDN sirve imágenes y archivos estáticos desde un punto cercano al usuario, en vez de obligar a cada visita a ir al servidor de origen. Son dos piezas que muchas tiendas chilenas no tienen y que cambian el número.

El caso particular de los catálogos grandes

Las tiendas mayoristas tienen un problema que las de retail no: el volumen. Diez mil productos, cada uno con variaciones, listas de precios por cliente y metadatos, generan una carga que un catálogo de cien productos nunca ve.

• Variaciones en exceso: un producto con cinco atributos de cuatro opciones genera cientos de variaciones, cada una con sus propios registros. Multiplicado por el catálogo, la tabla de metadatos se vuelve enorme. A veces conviene modelar como productos separados en lugar de variaciones.
• Búsqueda sin indexar: la búsqueda nativa de WooCommerce consulta la base de datos directamente y escala mal. En catálogos grandes, un índice de búsqueda dedicado responde en milisegundos lo que antes tardaba segundos.
• Índices de base de datos: las tablas de metadatos sin los índices adecuados obligan a recorrer todo en cada consulta. Es uno de los arreglos de mayor impacto y menor riesgo.

Chequeo accionable antes de tocar nada

Si tu tienda mayorista va lenta, este es el orden que seguimos antes de proponer cualquier cambio mayor:

• Medir el TTFB desde Chile y separar problema de servidor del de frontend.
• Revisar el tamaño de los autoloaded options en wp_options.
• Activar el log de slow queries de MySQL y leer qué consultas pesan.
• Auditar el peso que cada plugin agrega a la página y al tiempo de PHP.
• Revisar el tamaño y formato de las imágenes del catálogo.
• Confirmar si hay object cache (Redis) y CDN activos.
• Verificar los índices de las tablas de metadatos y la estrategia de búsqueda.
• Probar el servidor bajo concurrencia real, no con una sola visita.

Cuándo sí conviene migrar y cuándo no

Migrar tiene sentido en casos puntuales: cuando el hosting actual no permite instalar Redis ni acceder al servidor, cuando la base de datos quedó corrupta por años de plugins mal desinstalados, o cuando el theme está tan acoplado a código a medida que mantenerlo cuesta más que rehacerlo. Ahí la migración es una decisión de arquitectura, no un parche.

No conviene migrar cuando el diagnóstico no se hizo. Cambiar de plataforma sin saber por qué la actual era lenta casi garantiza llegar a la nueva con los mismos problemas: las mismas imágenes pesadas, el mismo catálogo mal modelado, el mismo hosting justo. La plataforma rara vez es la causa.

Síntoma	Antes de migrar, revisa
Lenta a media mañana	Dimensionamiento del hosting bajo concurrencia
TTFB alto siempre	Autoloaded options, slow queries, object cache
Grilla de catálogo pesada	Formato y tamaño de imágenes, CDN
Búsqueda lenta	Índices de base de datos, motor de búsqueda dedicado

Una tienda lenta es un problema medible, y casi siempre es más barato de resolver que de reemplazar. Antes de tirar abajo lo que ya funciona, mide. El diagnóstico cuesta una fracción de la migración y, las más de las veces, te ahorra la migración entera.