WP Rocket + WooCommerce: A Four-Level Troubleshooting Process for Homepage Caching Failure

WenPai Service adminCDN
, ,
1

Issue

The Time to First Byte (TTFB) for the WooCommerce store homepage surged from a normal 0.2s to 2.3s, and WP Rocket’s page caching completely failed. No cache files were generated at the nginx layer; every request was forwarded directly to PHP.

Environment

  • WordPress 6.9.1 multisite (subdirectory mode)
  • WooCommerce 10.3.7
  • WP Rocket 3.x + Object Cache Pro (Redis)
  • PHP 8.3, nginx

Troubleshooting Process: Four-Layer Root-Cause Analysis

Layer 1: Redis Crash

Redis maxmemory was set to 6 GB, but actual usage exceeded this limit, causing Object Cache Pro to frequently fall back to database queries.

Resolution: Increased maxmemory to 8 GB and configured Object Cache Pro with maxttl=86400 to prevent unbounded cache growth.

Layer 2: mu-plugin Injecting no-cache Header

A mu-plugin—originally added to block analytics scripts—was injecting the Cache-Control: no-cache HTTP response header via the wp_head hook. WP Rocket detects such headers and skips writing to the page cache.

Resolution: Removed the mu-plugin (its functionality had already been superseded by alternative methods).

Layer 3: Mandatory Cookie from Multi-Currency Plugin

WP Rocket’s configuration contained a mandatory cookie setting introduced by the YITH Multi-Currency plugin. Its logic stipulates that only requests carrying this cookie are eligible for caching. However, first-time visitors do not have this cookie, so no cache file is ever generated—creating a self-defeating loop.

Resolution: Cleared the mandatory_cookies setting in WP Rocket. Currency selection was migrated to frontend JavaScript handling, eliminating server-side cookie-based routing.

Layer 4: WC API Manager Disabling Homepage Caching

After resolving the first three layers, inner-page caching resumed normally—but the homepage remained uncached.

Investigation revealed that the WooCommerce API Manager plugin contains logic in wc-am-smart-cache.php: when the constant WC_AM_DISABLE_HOMEPAGE_CACHE is true (its default value) and the current page is the homepage, it sets DONOTCACHEPAGE = true. WP Rocket’s can_process_buffer() function checks for this constant and aborts caching if present.

Resolution: Added the following line to wp-config.php:

define('WC_AM_DISABLE_HOMEPAGE_CACHE', false);

Result

TTFB dropped from 2.3s to 0.18s (direct cache hit). The full flow—including WooCommerce’s geolocation_ajax 307 redirect—now completes in approximately 0.9s.

Lessons Learned

  1. WP Rocket cache failures require systematic, layered diagnosis: Start with response headers → check for interference from mu-plugins or other plugins → review WP Rocket’s own configuration → inspect third-party plugins that may set DONOTCACHEPAGE.
  2. mandatory_cookies is a subtle trap: Though designed to enable cookie-based cache variation, it prevents any cache generation for first-time visitors who lack the cookie—effectively blocking the initial cache entry.
  3. WC API Manager disables homepage caching by default: This behavior is not exposed in the plugin’s UI; it can only be overridden via the WC_AM_DISABLE_HOMEPAGE_CACHE constant in wp-config.php.
  4. Page cache diagnostics must use real HTTP requests: WP-CLI does not load advanced-cache.php, so cache-related issues cannot be reproduced or debugged via CLI commands.