Header Cart Count Shows Incorrect Value on Cached Pages

Hi,

We’re experiencing an issue with the header cart count when page caching is enabled.

Behaviour:
• Add an item to the cart
• Navigate to another (cached) page
• The header cart number reverts to the cached value instead of showing the actual cart quantity

Important notes:
• The issue disappears immediately if WP Rocket page caching is disabled.
• Other cache layers (Cloudflare and server cache) have been ruled out via staging tests.
• I also tested WP Rocket’s WooCommerce fragment compatibility plugin (Deactivate WooCommerce Refresh Cart Fragments Cache), but the behaviour remained unchanged.

WP Rocket support reviewed the setup and confirmed the same behaviour when page caching is active.

Could you please advise how the Header Builder cart element is intended to function when page caching is enabled, and whether there is a recommended configuration to ensure the cart count updates correctly on cached pages?

Thanks in advance.

Attachments:

You must be logged in to view attached files.

Hello,

In general, Wishlist, Cart and Compare pages should not be cached at all, so I suggest you exclude those pages from the cache and recheck the issue.

Please refer to the topic for more details https://docs.wp-rocket.me/article/54-exclude-pages-from-the-cache

Best Regards

Hi,

You have misunderstood what I have said. I am taking about the Cart Counter icon at the top right hand corner of every page? please see screen shot.

Attachments:

You must be logged in to view attached files.

Hello,

Actually, it has a fragment refresh functionality, so it should always display the number of items of the current user even with cache.

Try to exclude the following script “wc-cart-fragments and Clear” all caches after applying the changes.

Best Regards,

Hi,

Thank you for the suggestion.

I had already previously tested with all WP Rocket JavaScript optimisations disabled, and the issue still remained, which is why WP Rocket support narrowed this down to page caching itself rather than file optimisation.

For completeness, I also excluded wc-cart-fragments from Minify JS, Load JS Deferred, and Delay JavaScript Execution, then cleared all caches, but the behaviour is unchanged.

Current findings:

• The issue only occurs when WP Rocket page caching is active
• The issue disappears immediately when WP Rocket page caching is disabled
• Cloudflare and server-side caching were ruled out on staging
• Disabling JS optimisation does not resolve it
• WP Rocket’s WooCommerce fragment compatibility plugin also did not resolve it

Based on this, the issue appears to be specifically related to how the Header Builder cart element behaves when served from cached pages.

Could you please advise whether there is any known issue, setting, or recommended fix for ensuring the header cart count updates correctly with page caching enabled?

Hello,

Sorry to hear about the inconvenience. Kindly, please share your Site WP-ADMIN Login details in the Private Content field so that we can check this concern on your Site and help you out accordingly.

Best Regards

Please see Private Content field

Hello,

Your issue has been solved. Please go to Settings >> WP Rocket >> File Optimization >> JS Files >> Delay Javascript execution >> Exclude the Woodmart cart fragement and now the mini cart count is working fine: https://ibb.co/2G0Vj26

Best Regards.

Hi,

I have just checked, and the issue is still present on the staging site after you turn on this setting. It has not been solved.

Please note that:

1. Caching is not active when logged in, so you must use incognito, etc

2. After changing settings on WP Rocket the cache resets, so you must first load the page to create cache, then add to cart and then visit the same page you just cached.

Hello,

I have found that you are using the older version of Woocommerce plugin on the site. I have updated the plugin now your site is down. Can you please check and update all the plugins and WP version to the latest versions then check back the issue.

Best Regards.

Hi,

I have recreated the staging site again, and have updated all plugins except 1 which has custom modifications but is not related to this issue. WooCommerce & WP updates came overnight.

Any changes you made to the Staging site is lost.

The issue still exists. I have provided a new Staging login in hidden section.

Hello,

We have disabled third-party plugins on your staging site, except for WP Rocket, and this issue does not occur. You can verify this yourself.

Best Regards.

[Author]

Posts