WooCommerce sites often slow down when traffic spikes or product pages become too dynamic to cache efficiently. Traditional caching setups can break functionality, such as shopping carts and checkouts, leading to frustrated customers and lost sales.

If you’re running a WooCommerce store on a RunCloud-managed server, RunCloud Hub gives you full control over how server-side caching is applied. With its built-in RunCache system (powered by nginx), you can fine-tune your cache rules to boost performance without breaking key store features.

In this guide, we’ll walk you through how caching works with WooCommerce, where the common pitfalls are, and how to configure RunCloud Hub for maximum speed and stability.

The Challenge with Caching WooCommerce and PHP Sessions

WooCommerce often starts a PHP session as soon as a visitor lands on your site. This can happen on any page, including product pages, even before a visitor adds anything to their cart. This is usually done via the WooCommerce core hook woocommerce_session_start.

When a PHP session begins, nginx (the web server technology used by RunCloud Hub for caching) is configured to bypass its page cache for that specific user. This is an important safety measure. If nginx were to serve a cached HTML page that contained session-specific data (like cart information or user details), it could lead to one user seeing another user’s private information. Therefore, to prevent data leakage, caching is skipped once a visitor’s session is active.

How RunCloud Hub Caches WooCommerce Sites

RunCloud Hub’s RunCache uses nginx for full-page caching. This means nginx either caches the entire HTML output of a page or it doesn’t cache it at all for a particular request.

  • Default Exclusions: RunCloud Hub automatically configures RunCache to exclude some WooCommerce pages from caching. This includes:
    • /cart.*
    • /checkout.*
    • /my-account.*

You can verify these and other exclusion rules in your application’s settings under RunCloud Hub > Your App > RunCache > Rules.

These pages must remain dynamic as they display user-specific information. To learn more, refer to the WooCommerce Cache Documentation and How to Configure Caching Plugins for WooCommerce.

  • Guest Visitors: For visitors who do not have an active WooCommerce session (e.g., first-time visitors who haven’t interacted with cart-related functions), pages such as your homepage, category pages, and blog posts will generally be cached and served quickly.

  • Visitors with Sessions: If a visitor’s action triggers a WooCommerce session (like viewing a product page configured to start a session, or adding to cart), subsequent page loads for that visitor might bypass the cache. This means product pages might not be cached for them if a session has been started.

Why Product Pages Might Be Cached Differently on Other Platforms

You might wonder why other hosts seem to cache WooCommerce product pages more aggressively. Here’s how they differ:.

  • LiteSpeed Cache: When using a LiteSpeed server, the LiteSpeed Cache plugin can use advanced techniques like ESI (Edge Side Includes). ESI allows caching parts of a page (such as the header and footer) while keeping dynamic sections (like a mini-cart or user-specific welcome message) uncached.

  • RunCloud Hub (nginx): The nginx caching module in RunCloud Hub caches the entire page, or nothing at all. This approach is more conservative and straightforward, significantly reducing the risk of caching anomalies or data leakage. This is intentional as RunCloud prioritizes stability and data integrity over small performance gains.

While ESI can offer performance benefits, nginx’s full-page caching is simpler and more secure out of the box.

Best Practices for WooCommerce on RunCloud Hub

  1. Verify Exclusions: Double-check that your Cart, Checkout, and My Account pages are correctly excluded in your RunCache rules. Although these are usually set by default, if you have enabled any custom rules, they could interfere with the caching behaviour.

  2. Understand Product Page Caching: You should be aware that product pages can be served uncached to visitors once a WooCommerce session is active for them. However, product pages can still be cached for guests without a session. Refer to our documentation page to learn how to configure the best caching solution for your website using RunCloud Hub.

  3. Maximize Caching for Guests: 

What Can Trigger Cache Bypass (Besides Carts)

Even without an active cart, certain actions or plugins can trigger a session and bypass RunCache:

  • Plugins: Many WooCommerce extensions can also start sessions. For example, the official WooCommerce Stripe Payment Gateway extension is known to set the WooCommerce session on every single product page. This means even viewing a product can cause the page to be served uncached for that user.

  • Cookies: If RunCloud detects the presence of specific WooCommerce cookies in a visitor’s browser, then the RunCloud Hub plugin will bypass the cache. Common cookies that can trigger a bypass include:
    • woocommerce_cart_hash
    • woocommerce_items_in_cart
    • wp_woocommerce_session_ (followed by a unique ID)
    • wordpress_logged_in_ (for logged-in WordPress users)

Troubleshooting RunCloud Hub Cache for WooCommerce

If you suspect caching isn’t working as expected for your WooCommerce site on RunCloud Hub, follow these steps:

  1. Check Response Headers:
    • Use your browser’s Developer Tools (usually F12, then go to the “Network” tab).
    • Refresh the page you’re testing.
    • Click on the main page request (usually the first HTML document).
    • Look for the X-RunCloud-Cache header.
      • HIT: The page was served from RunCache.
      • MISS: The page was not in the cache and was generated fresh (it might be cached for a similar request in the future).
      • BYPASS: RunCache intentionally did not serve or store this page due to an exclusion rule, cookie, or other condition.
  1. Test as a Guest: Always test caching in an incognito/private browser window or after logging out of WordPress. Logged-in users (identifiable by the WordPress admin bar) will always bypass the cache.

  2. Inspect Cookies: In your browser’s Developer Tools (under Application > Cookies), check for the presence of the cookies mentioned above. If these exist, it explains why caching might be bypassed for your current browser session.
  1. Review RunCache Rules: In your WordPress dashboard, navigate to RunCloud Hub > Your Web Application > RunCache > Rules. Examine your “Exclude page cache based on matching URL path” and “Exclude page cache based on matching cookie name” lists. For more information, refer to our documentation on Excluding Pages from the Cache.

  2. Plugin and Theme Influence:
    • A plugin or theme might start sessions unexpectedly or send no-cache headers.
    • To test this, consider cloning your site to a staging environment. Then, disable all plugins except RunCloud Hub (and WooCommerce if testing shop pages). Switch to a default WordPress theme (like Twenty Twenty-One).
    • Test caching. If it works, re-enable your theme and plugins individually, testing after each activation, to identify the culprit. Payment gateway plugins, analytics tools, or membership plugins are common sources of cache-bypassing behavior.

  3. Use Query String Bypass for Testing: RunCloud Hub allows you to define a query string that forces a cache bypass (e.g., ?nocache=1). This is configurable in RunCache settings under “Prevent page cache when matching query string exists”. Appending this to a URL helps you compare a cached version with a freshly generated one, which can be useful for diagnosing issues related to stale content or confirming that caching was the problem. Read our detailed documentation on ignoring query parameters while caching to learn more.

If you’ve tried all the above and are still facing issues, gather as much information as possible (specific URLs, X-RunCloud-Cache header statuses, cookies present, relevant RunCache rules, and steps you’ve taken). You can then contact RunCloud support with these details for further assistance.