Caché en WooCommerce: qué revisar en carrito, pago y cuenta de cliente

Activar una caché puede hacer que una tienda responda antes, pero abrir la portada y verla rápida no demuestra que la compra funcione correctamente. El catálogo público y el carrito de una persona no tienen las mismas necesidades.

El criterio de cierre debe ser doble: comprobar el cambio técnico y conservar la independencia de cada compra. Esta guía propone una revisión práctica para el responsable de una pyme. No es una receta de configuración universal ni acredita resultados de una tienda concreta.

Identifica qué caché se ha cambiado

Antes de tocar ajustes, pide un mapa sencillo de las capas que intervienen: navegador, plugin, servidor y, si existe, CDN. Anota quién puede modificar cada una. Desactivar un plugin no demuestra que el servidor haya dejado de entregar una copia anterior.

Distingue también qué se guarda. Una imagen de producto y el HTML que contiene información de una cuenta no son el mismo recurso. No hace falta prohibir toda la caché para proteger una compra; hace falta saber qué respuesta puede compartirse y cuál depende del visitante.

Como criterio de trabajo, registra un único cambio por intervención cuando sea posible. Si se modifican varias capas a la vez, deja constancia: será más difícil atribuir una diferencia a un ajuste concreto. Una purga que parece arreglar temporalmente el problema es una pista, no una explicación de la causa.

Revisa las páginas reales, no solo tres nombres habituales

La documentación oficial de caché de WooCommerce indica que carrito, checkout y cuenta deben mantenerse dinámicos por contener información específica del cliente. También advierte de que muchos plugins ya los excluyen: conviene comprobarlo antes de añadir reglas duplicadas.

Localiza las páginas que tiene asignadas tu tienda y sus direcciones finales. Copiar una exclusión para una ruta en inglés no prueba que cubra una página traducida o personalizada. Pide que el técnico contraste la configuración con el recorrido que utiliza realmente el comprador.

Esta tabla es una propuesta de revisión, no una lista de reglas que debas pegar en el servidor:

Si el catálogo aplica precios por perfil, moneda, idioma u otras condiciones, no lo trates automáticamente como idéntico para todos. Anota esa personalización y solicita una revisión específica. El objetivo no es acumular exclusiones, sino justificar el tratamiento de cada zona.

Las cookies de sesión no son un estorbo que haya que borrar

La referencia de cookies de WooCommerce explica que algunas permiten reconocer cambios del carrito y relacionar la visita con sus datos de sesión. Su presencia depende de las funciones activadas y de las interacciones realizadas.

Borrar cookies y comprobar que el síntoma desaparece no acredita que el ajuste sea correcto para quien vuelve con una compra empezada. Conserva esa observación como parte del diagnóstico, sin convertir el borrado en la solución que se exige a los clientes.

No copies valores de cookies, identificadores de sesión ni datos de compradores en capturas o tickets públicos. Para documentar una incidencia basta una descripción saneada de las condiciones y del comportamiento observado. Tampoco cambies el consentimiento para conseguir una prueba aparentemente favorable: anota su estado y mantén el funcionamiento previsto de la web.

Prepara dos sesiones de prueba que realmente estén separadas

Nuestra propuesta es probar con dos perfiles de navegador independientes, identificados como A y B, usando solo cuentas y datos de demostración autorizados. Dos pestañas de un mismo perfil no bastan para representar dos compradores distintos.

Antes de empezar, acuerda qué acciones están permitidas. Un entorno de pruebas no garantiza por sí solo que cobros, correos, webhooks o integraciones externas estén desconectados. No generes pedidos ni envíes formularios reales para comprobar la caché sin disponer de un procedimiento autorizado.

En el entorno preparado, plantea estos recorridos:

1. A selecciona un producto de demostración y B otro distinto. Revisa que cada carrito contiene su selección.
2. A cambia la cantidad. Comprueba el estado de A y vuelve a revisar B.
3. Repite la visita después del cambio de caché para observar tanto la primera carga como las siguientes.
4. Si está autorizado probar cuentas, revisa la entrada y salida de una cuenta de demostración y qué ve después la visita sin sesión.
5. Recorre los pasos de pago que permita el entorno, sin efectuar un cobro ni activar servicios reales.

Si aparece información de la otra sesión, detén la prueba y escala la incidencia. No sigas explorando datos ajenos para conseguir más capturas. Una prueba satisfactoria de dos perfiles aporta evidencia acotada: no certifica todas las combinaciones de extensiones, idiomas o tipos de cliente.

Si el checkout se queda cargando, no culpes directamente a la caché

La guía oficial sobre el indicador de carga del checkout contempla distintas causas, entre ellas conflictos de extensiones, solicitudes bloqueadas y problemas del servidor. Distingue además entre checkout clásico y checkout por bloques; no conviene cambiar de uno a otro como primera prueba improvisada.

Registra la página, la hora, el paso y la versión desplegada, sin incluir datos personales. Después, el responsable técnico podrá relacionar esa observación con las solicitudes y registros autorizados. Que una purga altere el síntoma no descarta un problema distinto.

Si se necesita volver al ajuste anterior, utiliza el procedimiento de reversión acordado y comprueba de nuevo el recorrido. No encadenes purgas y cambios sin conservar qué versión estaba activa en cada intento.

Pide un cierre que incluya funciones, no solo velocidad

La entrega debería identificar las capas revisadas, el ajuste aplicado, los recorridos comprobados, el entorno y las excepciones pendientes. También conviene indicar quién conserva la configuración y qué hará si el problema reaparece.

La comparación del rendimiento móvil ayuda a evaluar la otra mitad del cambio: si mejora la experiencia bajo condiciones comparables. Una puntuación mejor no sustituye las pruebas de compra, igual que un carrito correcto no demuestra por sí solo una mejora de velocidad.

En el mantenimiento WooCommerce se puede acordar la revisión según las necesidades de la tienda, el alcance y las horas contratadas. Para empezar, facilita la URL afectada, cuándo aparece el fallo y qué cambio lo precedió; no envíes contraseñas ni datos de compradores. El primer resultado útil es delimitar el problema y las pruebas necesarias, no prometer que un único ajuste resolverá cualquier tienda.