How to fix WooCommerce category pages that never cache

When WooCommerce category pages take several seconds to load on every visit, the problem may not be the theme, images, or WP Rocket settings. In one WordPress performance investigation, the category pages were missing cache on every request because a quote plugin was forcing WooCommerce to create a customer session for every anonymous visitor.

The culprit was Request a Quote (Addify). Its code called set_customer_session_cookie(true) on every page load through afrfq_custom_start_wc_session() on wp_loaded. Because each request set a WooCommerce session cookie, the WP Cloud edge cache correctly refused to cache the page. The result was a full origin render of roughly three seconds on every category-page request.

Issue background

The site had a complicated WordPress stack that included Impreza, Elementor, WPBakery, WooCommerce, and multiple theme- and builder-specific components. Previous performance reviews had concluded that consolidating the theme and page-builder stack would provide the largest long-term improvement.

However, the immediate goal was narrower: identify smaller changes that could improve WooCommerce product-category pages without requiring a larger rebuild.

Live testing of a representative category page showed a cache miss on every request and an origin render time of roughly three seconds. That made caching behavior the most important area to investigate before spending time on incremental frontend optimizations.

Diagnosis

The development review traced the problem to the Request a Quote (Addify) plugin.

The plugin was starting a WooCommerce customer session on every page load by calling:

set_customer_session_cookie(true)

through its afrfq_custom_start_wc_session() function on wp_loaded.

This meant that even an anonymous visitor simply browsing a catalog or category page received a WooCommerce session cookie. Once that cookie was set, the edge caching layer treated the response as personalized and did not cache it.

As a result, every visitor triggered the full WordPress and WooCommerce render path instead of receiving a cached page. The category page therefore remained around the multi-second origin-render range even though the hosting stack had edge caching available.

The investigation also confirmed that WP Rocket was not the root cause. Its page cache was intentionally disabled because the hosting environment handled page caching at the platform level. WP Rocket remained relevant for frontend optimizations, but the missing edge cache was caused by the quote-plugin session cookie.

Resolution steps

The recommended fix is to prevent the quote plugin from starting a WooCommerce session until that session is actually needed.

1. Confirm repeated cache misses. Inspect response headers on a WooCommerce category page and verify whether repeated anonymous requests are always returning a cache miss.
2. Check for unexpected WooCommerce session cookies. If anonymous catalog visitors receive a WooCommerce customer-session cookie before interacting with cart, account, or quote functionality, determine which plugin is starting the session.
3. Trace the session initialization in code. In this case, Request a Quote (Addify) was calling set_customer_session_cookie(true) through afrfq_custom_start_wc_session() on wp_loaded.
4. Scope session creation to the actual quote workflow. The recommended approach was an update-safe snippet that starts the WooCommerce session only when a visitor adds something to the quote basket or reaches a page where the session is genuinely required, such as quote, cart, or account functionality.
5. Preserve quote functionality. The goal is not to disable WooCommerce sessions globally. The quote feature should continue to receive a session when needed while normal category and catalog browsing remains cacheable.
6. Clear caches and retest anonymously. After the session behavior is corrected, clear the relevant platform and frontend caches, then repeat the category-page request without logged-in state or existing WooCommerce cookies.
7. Verify the cache headers. The success condition is that repeat anonymous category-page requests can be served from edge cache rather than forcing another origin render.
8. Measure before and after. The development review estimated that a correctly cached category page could be served in under 100ms from edge cache instead of requiring roughly three seconds of origin rendering.

After the session-cookie issue is addressed, additional optimizations can still be worthwhile. The review identified several secondary opportunities:

• Audit WP Rocket settings such as minification, delayed JavaScript, Remove Unused CSS, and lazy loading.
• Confirm Imagify is serving WebP or AVIF and run bulk optimization on existing media.
• Regenerate WooCommerce thumbnails at appropriate display sizes.
• Reduce products per page or defer offscreen products on category archives.
• Dequeue unused page-builder assets from category templates where possible.
• Consolidate overlapping code-injection and carousel plugins.
• Review font loading and preload behavior.

Those changes are incremental. The session-cookie problem was identified as the highest-impact targeted fix because it prevented the caching layer from working at all.

Final outcome

The performance review successfully identified the root cause of the slow WooCommerce category pages: Request a Quote (Addify) was forcing a WooCommerce customer-session cookie on every anonymous page load, which prevented the WP Cloud edge cache from caching the category pages.

The development team recommended scoping that session initialization to visitors who actually use the quote functionality. The task was then passed back into the normal development workflow for implementation and measurement. The source task does not document the fix as deployed, so the expected sub-100ms cached response should be treated as the target outcome rather than a completed production result.

The broader lesson is to verify caching before assuming a slow WooCommerce archive needs a theme rebuild or extensive frontend work. A single plugin that starts a session too early can silently disable full-page caching and add seconds to every request.

If your WooCommerce category pages are always cache misses, or a quote, cart, inventory, or personalization plugin is setting sessions for anonymous visitors, contact Freshy. Our WordPress team can help diagnose WooCommerce session cookies, plugin behavior, WP Rocket, edge caching, and category-page performance.