Caché en WooCommerce: qué páginas puedes cachear y cuáles excluir
Distingue HTML público, sesiones y contenido personalizado. Revisa carrito, checkout, cuentas y reglas de CDN antes de ampliar la caché de tu tienda.
En WooCommerce puedes cachear contenido público cuando la respuesta es la misma para todos los visitantes que comparten esa caché. Carrito, checkout y cuenta requieren un tratamiento distinto porque muestran información o acciones ligadas al cliente. La decisión depende del contenido, la sesión y las reglas de cada capa.
Una portada rápida no demuestra que la tienda esté bien configurada. Hay que comprobar también compra, inicio de sesión y actualización de productos. Esta guía se centra en caché de página y CDN; para investigar otras causas, consulta cómo reducir el TTFB en WordPress.
1. Identificar qué caché responde
Puede haber caché en el navegador, un plugin, el alojamiento y una CDN. También puede existir caché de objetos para reducir consultas internas. Son mecanismos diferentes: una respuesta correcta en el plugin puede quedar cubierta por una copia antigua en el proxy.
Antes de cambiar reglas, anota las capas activas y cómo se observa cada una. Comprueba cabeceras y registros cuando estén disponibles. No interpretes una cabecera de la CDN como una descripción de toda la cadena hasta el servidor.
2. Elegir qué HTML público puede compartirse
Portada, categorías, fichas de producto y contenido editorial pueden ser candidatos cuando muestran lo mismo al público anónimo. Revisa si cambian según moneda, ubicación, grupo comercial o condiciones de acceso.
Una ficha con precios por cliente no es equivalente a una ficha pública, aunque ambas utilicen la misma URL. También puede haber información personalizada dentro del encabezado, como un resumen del carrito.
La estrategia debe definir qué se comparte, qué se obtiene por separado y qué solicitudes evitan la caché. No basta con comprobar que el cuerpo principal parece público en una visita sin sesión.
3. Excluir carrito, checkout y cuenta en las capas correspondientes
La documentación de WooCommerce señala carrito, checkout y Mi cuenta como páginas que deben mantenerse dinámicas. Comprueba sus URLs reales: pueden estar traducidas, personalizadas o incluir rutas secundarias.
Revisa las exclusiones del plugin y del hosting, y después las reglas de la CDN. Que una capa evite guardar una página no impide que otra responda con una copia compartida si está configurada para hacerlo.
Considera también confirmación de pedidos, recuperación de acceso y rutas con datos de cliente. La lista de exclusión debe seguir los recorridos reales de la tienda, no una colección de nombres copiada de otra instalación.
4. Considerar sesiones y cookies
WooCommerce documenta cookies como woocommerce_items_in_cart, woocommerce_cart_hash y el prefijo wp_woocommerce_session_. Ayudan a identificar condiciones que una solución de caché debe contemplar junto con las sesiones de WordPress y los plugins que personalizan contenido.
No elimines cookies o cabeceras de sesión únicamente para conseguir más respuestas cacheadas. Una regla puede mejorar el porcentaje de aciertos mientras rompe el comportamiento de compra.
Prueba visitantes anónimos con carrito, clientes identificados y usuarios con tarifas propias. Según la arquitectura, puede ser necesario omitir la caché de página o utilizar mecanismos de personalización compatibles. Eso debe decidirse y verificarse por recorrido.
5. Revisar Cloudflare y las reglas de HTML
En Cloudflare, revisa qué reglas hacen que una respuesta sea elegible para caché y cuáles la excluyen. Sus ejemplos de bypass por cookies muestran cómo condicionar esa decisión. Las opciones concretas deben comprobarse en el producto y plan utilizados.
Una regla amplia para HTML necesita exclusiones que representen sesiones, rutas privadas y acciones. Comprueba además orden y conflictos con otras reglas. No asumas que una exclusión del plugin se ha trasladado automáticamente a una regla independiente de la CDN.
Las peticiones de API o las acciones de añadir al carrito tampoco deben tratarse como páginas públicas intercambiables. Inventaría los mecanismos utilizados por tu versión, bloques y extensiones antes de ampliar el alcance.
6. Definir cómo se retira contenido antiguo
Cuando cambia un precio, una ficha o la disponibilidad, decide qué copias deben invalidarse y cuánto retraso es aceptable. Una purga en WordPress puede no retirar una copia de una CDN independiente.
Comprueba la ficha y los lugares donde vuelve a aparecer ese dato: categorías, destacados y búsquedas. Si un campo se actualiza desde un ERP, la prueba debe incluir esa ruta de actualización, no solo guardar el producto desde el administrador.
Vaciar toda la caché puede ayudar a diagnosticar, pero no sustituye una invalidación coherente. Si el mismo error regresa, identifica qué capa conserva o vuelve a generar la respuesta incorrecta.
7. Probar con dos sesiones independientes
Abre dos perfiles separados o utiliza un navegador normal y otro privado sin compartir sesión. Prepara un carrito distinto en cada uno y comprueba cantidades, precios y datos de cuenta. Una diferencia no esperada debe investigarse antes de aceptar la configuración.
Recorre catálogo, alta de producto en carrito, cambio de cantidad, checkout, acceso y cierre de sesión. Para probar un pedido, utiliza el entorno o mecanismo de prueba apropiado, sin generar cargos reales por una comprobación de caché.
Repite después de una respuesta cacheada y tras actualizar un producto. Comprueba también que una URL privada no entrega datos de otra sesión. Medir solo la primera visita no muestra cómo se comporta una copia ya almacenada.
Qué hacer si el checkout sigue lento
Una exclusión correcta puede dejar a la vista trabajo costoso del origen: llamadas externas, consultas, plugins o capacidad PHP. Ese recorrido dinámico necesita diagnóstico propio; cachearlo de forma compartida no resuelve su causa.
Registra ruta, estado de sesión y momento de la lentitud. Compara escenarios antes de cambiar servidor o sumar otro plugin. La guía de diagnóstico WordPress ayuda a separar esas capas.
Si necesitas revisar la tienda, trabajamos sobre WordPress y WooCommerce lentos, configuración de Cloudflare y mantenimiento WooCommerce, con pruebas de los recorridos que utiliza el negocio.