APO cache BYPASS with Worker Routes - possible regression

[igor.seyts]

What is the name of the domain?

a-hr.pro

What is the error number?

n/a

What is the error message?

cf-edge-cache is cache,platform=wordpress but cf-cache-status is BYPASS and cf-apo-via is origin,miss (not tcache)

What is the issue you’re encountering

increased page loading time, failed to Verify APO works (only 1 of 3 shows expected value)

What steps have you taken to resolve the issue?

purged cache (both in APO plugin and dashboard)
applied recommended settings in APO plugin
restarted server
tried adding a function described in Wordpress APO cf-edge-cache response header is missing!

What are the steps to reproduce the issue?

open HTTP response header check | Uptrends and test www.a-hr.pro

Screenshot of the error

[igor.seyts]

Would anyone be so kind as to point me in the right direction to identify the cause of this issue?

[igor.seyts]

It seems that the routing worker could be the reason for the issue - the moment I disable it all works as expected. That’s a bit strange as the worker should trigger redirect only for users in Ukraine

Could someone please point me in the right direction on how redirects (URL re-build/re-write) could impact caching?

[igor.seyts]

I have checked with my hosting provider and switched to a default theme + turned off most of the plugins and the only caching-related difference was MISS instead of BYPASS

This leads me to believe that some changes on Cloudflare side provoked the problem, not the site or host

I would appreciate if someone could assist with the matter

[igor.seyts]

It would be great to hear some suggestions from the community and/or Zaraz support team

[igor.seyts]

As a result of our own troubleshooting, we came to the conclusion that Cloudflare APO is being bypassed (cf-cache-status: BYPASS) when traffic routed via a worker with extremely minimal code (that should simply pass the request to the origin)

Steps to reproduce:

1. Create a worker with the minimal code as follows:

addEventListener("fetch", (event) => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  return fetch(request);
}

2. Create a route through the worker

3. Perform a HTTP response header check for a test page using HTTP response header check | Uptrends

Result:
cf-cache-status BYPASS
cf-apo-via origin,miss
cf-edge-cache cache,platform=wordpress

[igor.seyts]

This is quite frustrating - both APO and workers are not exactly free services, but I get nothing from CF to get this fixed.

[Laudian]

@igor.seyts

but I get nothing from CF to get this fixed.

When I visit your site, I get cf-cache-status: HIT everywhere.

Is there any specific resource where you encounter this problem?

[igor.seyts]

Hi @Laudian,
thanks for your response.

Could you please confirm if you were following these recommendations for verification?

[Laudian]

@igor.seyts

Could you please confirm if you were following these recommendations for verification?

No. I verified that it’s working by visiting your site and seeing that it’s working.

[igor.seyts]

Hi @Laudian
Thanks for trying to help me out!

I’m still strugging to understand why the verification way advised by CF is showing BYPASS and the %% of cached content is ridiculously low

Just a reminder - the moment I disable route worker all works as described in here Verify APO works · Cloudflare Automatic Platform Optimization docs

[igor.seyts]

Just a quick update

The case was logged with CF support 2+ weeks ago, yet there is no clarity on why the issue persists.

[igor.seyts]

First of all, I would like to share publicly my feedback on Cloudflare support.

Without any doubt, handling of this particular case was by far the worst experience I ever had with any IT service provider!

I registered the case with Cloudflare support on 26/03. The case included:

• Description with screenshots
• Steps to reproduce
• Code of the original and simplified workers

Since 26/03:
I sent 25+ messages, at least half of them were chasers and reminders. The longest wait time was 14 (!) days.

In total, I received 11 responses, out of which:

• 4 were generic
• 4 were claiming all works as expected
• 1 blaming Polylang cookie
• 1 suggesting a workaround (using Cache Rule)
• 1 combining both (blaming Polylang cookie and suggesting a workaround using Cache Rule)

Not even once did I receive an acknowledgement of the issue, and the case was closed on 25/04 (one month after we opened it) because we downgraded back to a Free plan (as paying for such quality of support was a nonsense).

Funny enough, the workaround suggested by the support team was a shot in the right direction (I will cover this in the next post), however:

• it was incomplete/insufficient
• it was confirming my assumption that the issue was on the Cloudflare end.

[igor.seyts]

Now let’s switch to the constructive side:

As the issue wasn’t acknowledged/resolved at the Cloudflare side, we had to do the following:

1. Damage control
   I discovered that the more specific worker routes override the generic ones, so we excluded static resources and 1 of 2 language locales coming through the worker. That was more of a damage control measure, but still, we instantly saw an improvement!
   This also invalidated the CF support’s claim that the issue was provoked by the Polylang cookie (as the locale where the worker wasn’t triggered had exactly the same plugins/theme/settings as the other one)

2. Workaround implementation - Transform rule
   Deletion of pll_language cookie with the Transform rule of amendment of the worker didn’t change the behaviour of the CF cache (still BYPASS)

3. Workaround implementation - Cache rule (suggested by CF support)
   For the remaining language locale (passing via the worker), we created a Cache Rule that was setting an attribute Eligible for Cache.
   By itself, it was insufficient.
   So, we added Edge TTL and Browser TTL to the same root and saw a stable HIT! Over the last 24 hours this solution was working well, and the %% of cached content served jumped to over 80%, but we will have to keep an eye on it as it’s not a fix, but a workaround.

Summary: looks like APO cache is occasionally glitching when the request is coming through the Worker Route. Most likely, this could be related to either:

• changes in the cache key/adding CF-specific headers, and/or
• loss of TTL headers somewhere between the worker and APO cache, and/or
• something else on the CF side

We can’t be sure when and if Cloudflare will decide to pay attention to this case, but we decided to share this solution with the public.