Setting up a cookie to allow caching of product pages on a per currency basis

[nicdwilson]

Description

The request comes as a result of a high volume user of WooPayments requesting help with the creation of a caching mechanism that would allow multi-currency to be used in a reverse proxy cached environment.

After some discussion at p1705549584944779-slack-C7U3Y3VMY it was decided to open this request as a means to monitor demand.

The mechanism

On switching currencies, the first request is parameterized with a query string. Following requests use the session cookie to monitor the currency in use by the user.

This makes it impossible to cache a product page on a site using multi-currency on a per currency basis.

The woocommerce_currency filter can be used now to set a cookie identifying the currency in use.

But building this into core WooPayments would allow us to set the cookie value to the exchange rate in use. This would provide a mechanism for cache invalidation.

Site managers could then set up VCL rules for Varnish, ACL rules for NGINX reverse proxy mechanisms, or custom rules for Cloudflare or Cloudfront instances.

While these mechanisms remain the responsibility of the site administration to set up, a cookie mechanism built into core could be documented for developers and sys-ops staff, and as a bonus allow them to share such VCL/ACL rules.

The cookie would not be needed by WooPayments, but provides great value to high volume sites seeking to improve performance.

Additional context

We should aim to remove the WC session to store the currency in favor of the new cookie.

The cookie should not be set on every request as some caching mechanisms such as Batcache will read the response headers and prevent the page from being cached if any cookies are being set.

More context in https://github.com/Automattic/woocommerce-payments/issues/8130#issuecomment-2085975611.

Another thing to note when caching product pages is that if Apple Pay/Google Pay is enabled on the product page, it will create a WC session upon page load, thus preventing the page from being cached. We might want to open another issue for this.

[zmaglica]

Before assigning it to the team Fractal, I would like to have feedback from @Automattic/transact-architecture . Do you think that this feature could benefit to the Woo Payments, and do you think that the implementation mechanism is correct, and can you suggest some improvements?

[hagedigital]

Howdy! I reached out to Woo to requested assistance with this implementation. While I can fully understand it can be achieved with a custom route, one really satisfying part of WooPayments is the all-in-one first party approach for payments, security and extra features like multi currency.

Having a broad, public and accessible guide on how to manage the cache for high traffic Woo stores would be a really useful tool. I'm sure most Woo stores with a passion for performance would appreciate it

[marcinbot]

Before assigning it to the team Fractal, I would like to have feedback from @Automattic/transact-architecture . Do you think that this feature could benefit to the Woo Payments, and do you think that the implementation mechanism is correct, and can you suggest some improvements?

Yes. I am not completely familiar with the caching plugins but the proposed implementation sounds like a solid enough approach. No further improvements are needed - we just set an arbitrary cookie when the currency or its rate is changed. Let's assign it.

[zmaglica]

This issue impacts Multi-Currency, so assigning to Fractal (based on team responsibilities Pc2DNy-3z-p2) @bborman22 . Assigning as part of Gamma Triage process PcreKM-yM-p2.

[AashikP]

Another request in 7850083-zd-a8c

[DaniBLE]

Yes, please request this. Desperately in need of a cache plugin that is compatible with WooPayments mult-currency. Thanks.

[bborman22]

Hey team! Please add your planning poker estimate with Zenhub @cesarcosta99 @lovo-h @rafaelzaleski @reykjalin @ricardo

[ricardo]

Re-opening because of revert: https://github.com/Automattic/woocommerce-payments/pull/8738

Context

After continued discussion in p9F6qB-eXd-p2, we've identified an issue related to caching pages when multi-currency is enabled, and since this is particularly significant for high-volume merchants, we've decided to revert the previously introduced wcpay_currency cookie and think about this issue more thoroughly.

What we've learned so far

Originally, in the implementation of the cookie approach (#8534) a cookie was set on every response to keep exchange rates as up-to-date as possible.

This behavior prevented Batcache from caching the page, thus negating the performance benefits intended by the caching mechanism.

It has been suggested (h/t to @bborman22 ) that while we may continue using the cookie, it should not be set on every request while confirming that doesn't create any caching issues.

On top of that, a new aspect has been raised concerning how the multi-currency widget works. To leverage the new currency cookie effectively without triggering a new WooCommerce session, it's critical to ensure that changing the currency via the widget does not initiate a new session, since this also prevents Batcache from caching the page.

I've edited the issue to include these in the acceptance criteria.

[ricardo]

Added the following to the issue:

Another thing to note when caching product pages is that if Apple Pay/Google Pay is enabled on the product page, it will create a WC session upon page load, thus preventing the page from being cached. We might want to open another issue for this.