Four-Layer Troubleshooting Process for WP Rocket + WooCommerce Homepage Caching Failure

Wapuu
,
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 6GB, but actual usage exceeded this limit, causing Object Cache Pro to frequently fall back to database queries.

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

Layer 2: mu-plugin Injecting no-cache Headers

A mu-plugin named Fuckalyzer (intended to block analytics scripts) injected 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: YITH Multi-Currency Plugin’s Mandatory Cookie

WP Rocket’s configuration included a mandatory cookie set 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 possess this cookie—so no cache file is ever generated, resulting in an infinite loop.

Resolution: Cleared the mandatory_cookies setting in WP Rocket. Currency selection was migrated to frontend JavaScript, 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.

Tracing revealed that the WooCommerce API Manager plugin, in wc-am-smart-cache.php, contains logic that—when the constant WC_AM_DISABLE_HOMEPAGE_CACHE is true (its default value) and the current page is the homepage—sets the DONOTCACHEPAGE constant to 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 (cache hit on first byte). 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’ use of DONOTCACHEPAGE.
  2. WP Rocket’s mandatory_cookies is a subtle pitfall: Though designed for cookie-based cache variation, it prevents any cache generation for first-time visitors who lack the required cookie—effectively blocking cache initialization entirely.
  3. WC API Manager disables homepage caching by default: This behavior is not exposed in the plugin’s UI and can only be overridden via the WC_AM_DISABLE_HOMEPAGE_CACHE constant in wp-config.php.
  4. Page cache diagnostics must rely on real HTTP requests: WP-CLI does not load advanced-cache.php, so cache-related issues cannot be reproduced or diagnosed using CLI commands.
2

That disruptive analytics plugin was installed by me last year—I sincerely apologize.