APO Cache: how to deal with multi-currency & VAT rates

Hi,
I have started using Cloudflare APO for my wordpress/woocommerce webite which enables dynamic caching. The issue I’m now getting is that (depending which country a customer is from) I’m showing products with different currencies and VAT rates. Before using Cloudflare I was using quic.cloud and here I could define which cookies an/or query strings should trigger a new cache variant (e.g. one cookie for currency, a second one for country, a third one for VAT yes/no and quic.cloud saves a cache variant for e.g. UK/GBP/VAT, UK/GBP/NO VAT, US/USD/NO VAT, DE/EUR/VAT, DE/EUR/NO VAT, NL/EUR, NL/EUR/NO VAT, etc.). It seems that it isn’t possible to configure something like this with Cloudflare APO, so the only option is to completely disable the dynamic caching (which makes APO quite useless).

Any ideas how this could be achieved?

1 Like

Enterprise plan users can set cache keys based on cookies. Otherwise, if you can set your origin to use query strings as opposed to cookies to differentiate different combinations of currency, country and VAT, you could combine APO with a Cache Everything Page Rule (or use the new Cache Rules with even more flexibility).

Hi,
thanks for the reply.

But wouldn’t the “cache everything” rule also start caching logged in users and so serve “private” content to the wrong user?

I was discussing this with the developer of my multi-currency plugin and he says due to the inflexibility of Cloudflare’s caching approach the only thing he could imagine how to enable dynamic caching of multi currency pages is by either re-writing multi currency related query strings into URLs to trick Cloudflare to cache these (e.g. mywebshop/product1/?EUR&UK&VAT becomes mywebshop/product1/EUR_UK_VAT) or by refreshing prices through AJAX calls after loading the page.

These are all quite “dirty” workarounds for a problem which should be fixed by the CDN providers in my opinion.

1 Like

The solution exists but requires Enterprise Plan (as previously mentioned by @cbrandt).

Also, has your developer actually taken a look at the new Cache Rules (Beta) and found this equally “inflexible”?

2 Likes

Thanks for the hint to the cache rules (beta), this may help in combination with query strings. I’ll have a look into these.

2 Likes

We had a look into the “cache beta” rules, but they seem only to be allowing to disable cache for certain conditions. What I was used from quic.cloud is that it is building up different versions of the cached information based on certain cookie values (e.g. product A (US/no VAT), product A (UK, 20% VAT), product A (DE, 19% VAT), so that every visitor (logged in or not) is seeing the correct prices and VAT information served by the CDN.

Cloudflare seems not to be able to provide this feature (APO is just serving the same cached page for every not logged in user and just stopps caching dynamic content for logged in users), cache beta rules allow you again to stop caching dynamic pages when a certain cookie is present and even the enterprise plan only allows to cache or not to cache but not building up different versions of the dynamic cache based on attributes.

Hi,

I’m afraid you haven’t had luck in implementing them correctly. You can use Cache Rules (beta) to specify which URLs to cache based on multiple parameters, including query string and even cookies.

However, I must say that, to the best of my knowledge, Cache Rules or Page Rules cache will differ from APO cache, and my understanding is that if you use a Cache Rule in combination with APO, for the URLs where a Cache Rule is triggered, you’ll have cache based on the regular Cloudflare caching mechanism, that is, pages are cached at the colocation where first request was received, while APO uses KV to store the cached page across every colocation. Still, it will be a much better situation than having a request sent to your origin each time.

With that caveat in mind (I hope Cloudflare staff from the APO Team can confirm or deny my working hypothesis here), you can create the following Cache Rule for your APO-enabled host:

When incoming requests match:
(http.host eq "APO-ENABLED-DOMAIN-NAME" and http.request.uri.query contains "currency")

(The hostname part is only needed if your zone has subdomains that you do not want to be affected by this rule, such as staging, for instance) Then your URLs like example.com/?currency=usd... will be cached separately from example.com/?currency=eur etc.

If you check their headers, you’ll see that APO is not caching them, but you’ll have a HIT nevertheless:

image

Please review the following documentation about how to implement Cache Keys on an Enterprise Plan. It indicates that you can, in fact, not only decide what to cache or not to cache, but create distinct cached versions of the same URL based on parameters like cookie, header, query string etc.

There are a couple of common reasons to change the Cache Key Template. You might change the Cache Key Template to:

  • Fragment the cache so one URL is stored in multiple files. For example, to store different files based on a specific query string in the URL.
1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.