Una página en caché nunca debe contener los datos de un solo visitante. Eso excluye las páginas de usuarios con sesión iniciada, el carrito, el pago y la cuenta, las páginas generadas con una sesión o un carrito con productos, y las respuestas que establecen una cookie o están marcadas como privadas. Todo lo demás puede almacenarse en caché, siempre que los parámetros de filtro formen parte de la clave de caché, los parámetros de seguimiento queden fuera, los precios se purguen cuando cambian y ninguna página sobreviva a sus nonces.
Las reglas valen para cualquier Page Cache. Las cifras y los nombres de archivo son los del Page Cache de CachePilot, un ejemplo de cómo se plasman las reglas en código.
¿Qué nunca debe almacenarse en caché?
La guía de WooCommerce sobre cachés nombra las páginas de carrito, pago y cuenta y enumera las cookies que usa WooCommerce. Un Page Cache tiene que decidir dos veces: antes de responder a una petición y, una vez generada la página, antes de almacenarla.
Peticiones que omiten la caché
| Regla | Motivo |
|---|---|
| Regla: Usuarios con sesión iniciada, entradas protegidas, autores de comentarios | Motivo: Las cookies wordpress_logged_in, wp-postpass y comment_author indican contenido personal |
| Regla: Páginas de carrito, pago y cuenta | Motivo: Su contenido pertenece a un solo visitante |
| Regla: Todo excepto GET y HEAD | Motivo: Los demás métodos modifican datos; los fragmentos del carrito son la única excepción |
| Regla: Administración, AJAX, cron, API REST, feeds, embeds, archivos XML y PHP | Motivo: Estas respuestas no son páginas para visitantes |
| Regla: Parámetros de consulta desconocidos | Motivo: Parámetros como add-to-cart o s cambian lo que hace la petición |
| Regla: La cookie woocommerce_recently_viewed | Motivo: El widget muestra los productos de ese visitante |
| Regla: Una cookie de sesión cuando los impuestos dependen de la dirección del cliente | Motivo: Los precios mostrados dependen del visitante |
Páginas que nunca se almacenan
| Regla | Motivo |
|---|---|
| Regla: Un usuario con sesión iniciada o DONOTCACHEPAGE | Motivo: Los plugins de WordPress usan esta constante para excluir una página |
| Regla: Un carrito con productos o una sesión de WooCommerce | Motivo: La página puede mostrar avisos del carrito o precios para la dirección del visitante |
| Regla: Un precio generado con geolocalización | Motivo: El precio solo es válido para una ubicación |
| Regla: Una cabecera Set-Cookie, o Cache-Control con no-cache, no-store o private | Motivo: La propia respuesta se marca como personal |
| Regla: Resultados de búsqueda, páginas 404, feeds y embeds | Motivo: Rara vez se solicitan dos veces |
| Regla: HTML incompleto | Motivo: Con menos de 255 bytes o sin la etiqueta html de cierre, un fallo de generación llegaría a todos los visitantes |
Visitantes con un carrito con productos
La configuración sencilla omite la caché para todo visitante con una cookie de carrito. Es segura, pero esos visitantes no obtienen aciertos de caché. La otra configuración les sirve páginas en caché y rellena el minicarrito mediante fragmentos del carrito, mientras que las páginas generadas para ellos no se almacenan.
CachePilot usa la segunda configuración. Depende del tema: un tema que imprime el número de artículos del carrito en el HTML de la página necesita la primera.
¿Por qué importan los parámetros de seguimiento?
Los enlaces de boletines, anuncios y redes sociales llevan parámetros como utm_source, gclid o fbclid. No alteran la página. Si formaran parte de la clave de caché, cada enlace de campaña crearía su propia copia de la página, y casi todos los visitantes de una campaña obtendrían un fallo de caché.
Un Page Cache debería dejar estos parámetros fuera de la clave. La lista de CachePilot sigue la de WP Rocket 3.24 y tiene 61 entradas, cuatro de ellas prefijos de una familia completa: utm_*, mtm_*, pk_* y hsa_*.
¿Cómo se almacenan en caché los filtros de la tienda?
Los parámetros de filtro, orden y paginación sí cambian la página, así que pertenecen a la clave con sus valores. Ordenarlos antes hace que ?orderby=price&paged=2 y ?paged=2&orderby=price compartan una misma entrada. La lista de CachePilot tiene 14 entradas, entre ellas orderby, paged, min_price, max_price y los prefijos filter_*, query_type_* y attribute_*.
Un límite evita que los rastreadores que combinan todos los filtros llenen Redis con páginas que nadie vuelve a solicitar. En CachePilot, una petición con más de 6 parámetros almacenables en caché omite la caché.
Las cookies de moneda requieren el mismo tratamiento, de modo que un visitante que haya elegido otra moneda reciba la página en esa moneda. La página de sitios multiidioma trata los idiomas y las monedas.
¿Qué pasa con los fragmentos del carrito?
WooCommerce actualiza el minicarrito con una petición POST a ?wc-ajax=get_refreshed_fragments. Cada una de estas peticiones inicia WordPress, y para un visitante con el carrito vacío la respuesta es siempre la misma.
CachePilot almacena en caché esta petición mientras las dos cookies del carrito, woocommerce_cart_hash y woocommerce_items_in_cart, estén vacías. En cuanto el carrito tiene productos, la petición llega a WooCommerce como de costumbre.
¿Cuándo hay que purgar las páginas en caché?
Los cambios realizados mediante la API de WooCommerce, REST, WP-CLI, importaciones y ofertas programadas no disparan un guardado normal de entrada. Una caché que solo atiende a las entradas guardadas conserva los precios antiguos tras ellos. CachePilot purga de la siguiente manera:
- Existencias. Un cambio de existencias o del estado de existencias purga la página del producto junto con sus páginas de tienda y de categoría.
- Precios. Un cambio de precio, de fechas de oferta, de estado fiscal o de clase de impuesto vacía todo el Page Cache, porque los productos relacionados, las ventas cruzadas y los bloques de producto muestran ese precio en otras páginas.
- Ajustes de la tienda. La moneda, el formato de precio, los ajustes de impuestos, los tipos impositivos y los precios de WCML vacían el Page Cache una vez al final de la petición, de modo que una edición masiva cuesta un solo vaciado.
- Contenido. Guardar una entrada purga su paginación, las entradas contiguas, el autor, la fecha y las páginas superiores, los términos y las traducciones de WPML. Los menús, los widgets, el título del sitio y los enlaces permanentes vacían toda la caché.
¿Por qué como máximo 12 horas?
Muchas páginas de tienda contienen nonces, por ejemplo para la Store API o para peticiones REST desde la propia página. Un nonce de WordPress es válido entre 12 y 24 horas, según el momento de su ciclo en que se creó. Una página en caché con más de 12 horas puede llevar un nonce caducado, y un botón o formulario de ella falla.
CachePilot limita la duración de la página a 43.200 segundos, es decir, 12 horas, sea cual sea el ajuste. Autopilot usa 10 horas.
¿Cómo compruebo qué ocurrió con una página?
Tres pruebas en una copia de staging cubren los principales riesgos de cualquier Page Cache:
- Añada un producto en un navegador y abra después la misma página en otro navegador distinto. El segundo debe mostrar el carrito vacío.
- Cambie un precio y recargue la página del producto y la de su categoría.
- Cargue una página dos veces con ?utm_source=test. La segunda petición debería ser un acierto.
En CachePilot, el módulo Debug añade a las páginas HTML un comentario con el estado del Page Cache y el motivo de una omisión, por ejemplo “WooCommerce page” o “Cart not empty”.
La página de WooCommerce describe cómo trabaja CachePilot en una tienda.
Fuentes
- Documentación para desarrolladores de WooCommerce, configuración de plugins de caché: páginas y cookies.
- Documentación para desarrolladores de WordPress, nonces: validez de 12 a 24 horas.
- plugin/pagecache-rules.php: cachepilot_pc_defaults() con 61 parámetros ignorados y 14 almacenables, cachepilot_pc_decide() con la regla de los fragmentos del carrito, CACHEPILOT_PC_MAX_PARAMS = 6.
- PageCacheModule.php en modules/PageCache del plugin: shouldBypass(), getNoStoreReason(), wooCommerceRules(), MAX_PAGE_TTL = 43200, AUTOPILOT_TTL = 36000, PRICE_PROPS, FLUSH_HOOKS.
- plugin/readme.txt, registro de cambios 1.3.0 y 1.4.1.
