Por qué el carrito de WooCommerce no se cachea (y qué implica para tu hosting)
Publicado el 24 de julio de 2026 · Actualizado el 5 de agosto de 2026
Por Rubén Ortega · 12 años en soporte técnico y preventa de empresas de hosting (Abansys, Arsys, Nominalia) · Declaración de vínculos
📌 Datos clave
- Por qué no se cachea
- El contenido es distinto para cada visitante
- Páginas siempre excluidas
- Carrito, finalizar compra, mi cuenta
- Consecuencia
- Cada visita ejecuta PHP y consulta la base de datos
- Qué medir entonces
- El tiempo de respuesta sin caché
- Recurso crítico
- Procesos concurrentes, más que espacio en disco
Respuesta rápida
El carrito no se puede cachear porque su contenido es diferente para cada persona que lo mira. Una caché de página guarda una copia del HTML y se la sirve a todo el mundo. Aplicado a un carrito, eso significaría enseñarle a un cliente los productos de otro.
Por eso todos los plugins de caché excluyen por defecto tres páginas: carrito, finalizar compra y mi cuenta.
La consecuencia es la que importa: en una tienda, buena parte del tráfico ejecuta PHP y consulta la base de datos de verdad. El rendimiento real del servidor deja de estar tapado por la caché.
Por qué una tienda es otro problema
En un blog, el 95 % de las visitas se sirven desde caché: el servidor entrega un fichero ya montado y casi no trabaja. Da igual que el hosting sea justo, porque apenas se le pide nada.
En una tienda, el recorrido de compra es todo lo contrario:
| Página | ¿Se cachea? | Por qué |
|---|---|---|
| Portada | Sí | Igual para todos |
| Categoría de productos | Sí, con cuidado | El stock cambia |
| Ficha de producto | Sí, con cuidado | El precio y el stock cambian |
| Carrito | No | Distinto para cada persona |
| Finalizar compra | No | Datos personales y pago |
| Mi cuenta | No | Sesión iniciada |
Y ahí está la trampa: las páginas que no se cachean son exactamente las que generan ingresos. Puedes tener una portada que carga en 200 ms y un proceso de pago que tarda tres segundos.
El dato que hay que mirar
Por eso, para una tienda, la medición útil no es la velocidad de la portada. Es el tiempo de respuesta sin caché.
Es fácil de comprobar tú mismo:
# Con caché: la portada tal cual
curl -o /dev/null -s -w "con caché: %{time_starttransfer}sn" https://tutienda.com/
# Sin caché: se fuerza a saltarse la copia guardada
curl -o /dev/null -s -w "sin caché: %{time_starttransfer}sn" "https://tutienda.com/?nocache=$RANDOM"Si la primera cifra es baja y la segunda es tres o cuatro veces mayor, tienes un servidor que va justo y una caché que lo está tapando. En un blog no lo notarías nunca. En una tienda, lo notas en cada pedido.
Está desarrollado en qué es el TTFB.
Qué le pide una tienda al servidor
Tres cosas, por orden de importancia:
1. Procesos concurrentes. Cada visitante en el carrito ocupa un proceso PHP durante todo el tiempo que tarde la página. Con un límite bajo, veinte personas comprando a la vez agotan el cupo y las siguientes ven un error — justo cuando más tráfico tienes.
2. Memoria PHP. WooCommerce con pasarelas de pago, transportistas y facturación consume mucho más que un blog. Por debajo de 256 MB se va justo.
3. Rendimiento de la base de datos. Cada operación del carrito escribe y lee. Es donde más se nota un servidor saturado.
Lo que no es el cuello de botella: el espacio en disco. Una tienda con mil productos ocupa poco. Se elige mal cuando se compara por GB.
Lo que sí se puede optimizar
El carrito no se cachea, pero hay margen:
- Caché de objetos (Redis, Memcached): guarda resultados de consultas repetidas. Es la
optimización que más se nota en una tienda, y requiere que el hosting lo ofrezca.
- Cachear catálogo y fichas con purga automática al cambiar stock o precio.
- Vaciar sesiones caducadas: WooCommerce acumula sesiones de carritos abandonados que
engordan la base de datos.
- Limitar los «productos relacionados», que generan consultas pesadas en cada ficha.
Para una tienda, lo que decide son los procesos concurrentes y la memoria PHP, no el precio. Raiola es el proveedor con el que tenemos programa; comprueba tú esos dos números antes de contratar, aquí o en cualquier otro.
Ver el hosting WordPress de Raiola
Enlace de afiliado: si contratas, cobramos una comisión de cada pago que hagas, también en las renovaciones. No te cuesta más.
Para dimensionar según tu volumen real: qué recursos necesita WooCommerce según el volumen de tu tienda.
Cómo saber si tu hosting se ha quedado corto
Señales concretas:
- El proceso de pago tarda notablemente más que el resto de la web
- Errores 500 o 503 en horas de más tráfico
- El escritorio de WordPress va lento aunque la tienda se vea bien
- Clientes que reportan pedidos duplicados — síntoma de tiempos de espera agotados
Antes de subir de plan, comprueba si el problema es tuyo: un plugin pesado consume igual en un servidor grande.
Preguntas frecuentes
¿Por qué no se puede cachear el carrito?
Porque su contenido es distinto para cada visitante. Servir una copia guardada mostraría a un cliente el carrito de otro.
¿Por qué mi tienda va más lenta que mi blog en el mismo hosting?
Porque el blog se sirve casi entero desde caché y la tienda no. Cada visita al carrito ejecuta PHP y consulta la base de datos.
¿Qué hosting necesita una tienda?
Uno con buen rendimiento sin caché, procesos concurrentes suficientes y memoria PHP holgada. El dato que importa no es la velocidad de la portada.
¿Sirve un CDN?
Para imágenes y ficheros estáticos, mucho. Para el carrito y el pago, no: ese contenido tiene que generarlo tu servidor en cada petición.
Guía general sobre el comportamiento de WooCommerce en alojamiento compartido. Las mediciones comparadas de proveedores concretos se publicarán con su metodología.