The pages for Checkout and My Account might also be suitable for this change, but I didn't test that they have pageshow event handlers in the same way that the Cart page does.

Thank you for this PR @westonruter, our perops team was looking into those headers and actually looking to add them to more pages, I will bring them to the discussion.

@senadir Adding no-store to more pages will degrade the performance of browsing a site. See https://web.dev/articles/bfcache#minimize-no-store

not more pages, just the whole cart/checkout pages, as we aggressively cache other pages and we don't want to do that for cart/checkout.

Oh good. So in other words, in addition to removing cart (as done in my PR here), you also intend to remove checkout from this line as well:

Removing the Chrome-specific stuff seems ok - and I particularly support the idea of preserving core's cache-control directives, especially "private".

But this will remove the "no-cache" directive for all visitors on the cart page. There are likely thousands of WooCommerce sites behind edge caches which rely on those headers to prevent caching shopping carts across users.

I think it would be better to add "private" to cache-control on cart and checkout pages instead of no-cache.

@thingalon By no-cache do you mean no-store?

This PR removes no-store for all visitors to the cart page, yes. However, because nocache_headers() is being called, core is sending the private directive which prevents edge caches from caching those responses.

Core added the private directive in WordPress 6.3, which is far before the 6.7 minimum supported version. So it appears that private will already be getting sent.

@westonruter - this diff affects both the no-store and no-cache headers.

On a fresh temp WordPress / WooCommerce install:

$ curl -sI 'https://test-host.local/temp-site/cart/' | grep Cache-Control
Cache-Control: no-cache, must-revalidate, max-age=0, no-store, private

With the patch installed:

$ curl -sI 'https://test-host.local/temp-site-patched/cart/' | grep Cache-Control
(nothing)

The diff prevents nocache_headers() from being called on the cart page. Since shopping carts get served embedded in pages for unauthenticated users, it could cause full shopping carts to get caught up in reverse-proxy caches. :)

I think it'd be more appropriate to set Cache-Control: private on cart and checkout pages for unauthenticated users. i.e.: I think it'd be ok to drop the no-cache and no-store directives from cart pages, but I think we should retain private for the sake of reverse-proxy caches.

Thinking on it further: this will also bypass calling set_nocache_constants() on the cart page. The DONOTCACHEPAGE const defined there affects how common page-caching plugins like WP Rocket and WP Super Cache handle pages too.

@thingalon Oh yes, you're right. I confused myself because I also have in mind removing no-store from the default set of directives sent when calling nocache_headers(), leaving only private.

Update: See https://core.trac.wordpress.org/ticket/63636

So yes, Cache-Control: private is what needs to be added instead of calling nocache_headers() on the cart and checkout pages.

sequenceDiagram
    participant WP as WordPress
    participant WC as WC_Cache_Helper

    WP->>WC: Apply wp_headers filter (with $headers)
    WC->>WC: Check if WooCommerce page (cart, checkout, my account)
    alt If WooCommerce page
        WC->>WC: Define no-cache constants
        WC->>WC: Merge cache-control directives (private, no-cache, must-revalidate, max-age=0) into $headers (exclude no-store)
    else Not WooCommerce page
        WC->>WC: Return $headers unchanged
    end
    WC->>WP: Return modified $headers

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

@thingalon OK, how about 3d0d954?

In the authenticated state, the no-store directive is coming from wp_get_nocache_headers() sent from WordPress while logged-in. Otherwise, the other same directives from wp_get_nocache_headers() remain since they don't impact bfcache while also helping to ensure freshness. As noted above, I'm in the process of putting together a proposal to remove no-store from that. (Update: See Core-63636.)

The set_nocache_constants() call remains in place.

@westonruter - that looks good to me, and seems like a clear improvement around caching headers. Thanks for working on this!

@senadir - can you please review it for merging into WooCommerce? :)

Here's a demo of the impact. While not being logged-in to WordPress and emulating a Slow 4G connection, compare entering a coupon on the cart page, then navigating to the shop, and then going back to the cart page. Notice how much faster the experience is when bfcache is enabled, and notice that the coupon dropdown retains its open state with the unsubmitted coupon still populating the field:

Granted, the speed effect is exaggerated here because I had DevTools open with cache disabled, besides emulating Slow 4G.

Testing Guidelines

Hi ,

Apart from reviewing the code changes, please make sure to review the testing instructions (Guide) and verify that relevant tests (E2E, Unit, Integration, etc.) have been added or updated as needed.

Reminder: PR reviewers are required to document testing performed. This includes:

• 🖼️ Screenshots or screen recordings.
• 📝 List of functionality tested / steps followed.
• 🌐 Site details (environment attributes such as hosting type, plugins, theme, store size, store age, and relevant settings).
• 🔍 Any analysis performed, such as assessing potential impacts on environment attributes and other plugins, conducting performance profiling, or using LLM/AI-based analysis.

⚠️ Within the testing details you provide, please ensure that no sensitive information (such as API keys, passwords, user data, etc.) is included in this public issue.

@westonruter I'm going on sabbatical by the end of this week; I'd love if we could get this merged ASAP so I don't need to hand it over. Let me know if you need help applying feedback.
Merging it this week will also land it in the WooCommerce 10.1 release coming out early August.

I will try to amend the PR tomorrow morning to do so, but I'll be AFK for the rest of the week.

I've opened a similar pull request for Jetpack: Automattic/jetpack#44322