Does Cloudflare APO serve 304s from their edge or origin?

If I set a rule in page rules to cache everything. On .index.html it would return 200 from Cloudflare’s edge. Awesome my origin is totally not even touched after the first request from each PoP until edge TTL expires or manual cache clear.

If I instead install Cloudflare APO and turn it on, index.html will return a 304. Awesome, fast. But does this serve the 304 from my origin or from Cloudflare’s edge cache. Aka, is my origin still serving requests on each returning visit? If so, lame…

My understanding is they use Workers with APO to do this (makes sense…) but if I go to the Workers tab, I see no code or worker doing anything.

Just need clarification. Thanks!

Depends on the headers. You can check them yourself to indentify if something was served from Cloudflare or from your origin:

Served from Cloudflare:

Served from origin with 304:

As a 304 HTTP Code requires the last-modified header and i have never seen this one with APO, so I assume that the 304 codes are triggered by the origin. Also if you check your header and cf-cache-status is DYNAMIC, the request was passed to the origin.

Thanks! Can get some elaboration on that? Goal here is obviously offload near 100% of requests to the origin

304 can also be triggered by an If-None-Match request using the ETag header.

1 Like

Sorry all, I guess I’m looking for a more specific answer on request lifecycle here of APO requests. Appreciate the help.

The goal is not just general performance improvements, it’s about completely protecting the origin as much as possible by off-loading nearly 100% of requests to Cloudflare. I want to compare Cloudflare’s APO setup versus manual setups with them.

I want my origin to basically be a potato and the site to serve near statically as possible.

This is currently possible a couple ways with Cloudflare if you put the site into the wilderness with them:

Scrape it and deploy as workers site (true static)
Can do but not my goal for this one. Worker Sites store all assets in KV so those requests can be whatever. The real origin can be wherever too (local, remote and hidden, etc…)

  • User visits site
  • First request loads out of KV as 200
  • Second request sent from KV/Worker Cache as 304 until Worker cache TTL expires or cache is cleared

Page Rule to Cache Everything (fake/near static)
From each of Cloudflare’s PoPs, they will hit my origin once until edge TTL expires. My index.html and .pngs|jpgs|etc.. serve 200s via cf-cache-status-hit. You can improve this with Argo and tiered caching if you really want to (aka, less PoP’s hitting your server). The big con is (unless you are an enterprise plan) you can’t choose to ignore query strings and cache everything (e.g.: /lander?utm=1 and /lander?utm=2 are separate caches).

  • => User visits site
  • =>First request sent from origin as 200
  • =>Second request sent from edge cache as 200 until edge cache TTL expires or cache is cleared

Custom Worker to Cache Everything, Ignore Query Strings (fake/near static)
Just a custom script to throw into cache via worker. Look like anything but might look something like this:

  • =>User visits site
  • =>First request loads sent from origin as 200 and cached by worker
  • =>Second request loads sent from worker cache as 200 until worker cache TTL expires or cache is cleared

Cloudflare APO (fake/near static?)
So what is happening with index.html and .pngs? Directly from Cloudflare APO page:

Automatic Platform Optimization is the result of using the power of Cloudflare Workers to intelligently cache dynamic content. By caching dynamic content, Cloudflare can serve the entire website from our edge network to make a site’s time to first byte (TTFB) both fast and consistent.

So… how often are we loading from origin versus the other options here listed here for non-dynamic content. Let’s pretend the site has no dynamic content and is never going to change. Is it basically:

  • => User visits site?
  • => First request loads out of origin as 200?
  • => Second request loads out of Cloudflare Worker cache as 200 or 304?
  • => What about query strings?
  • => When does that expire, etc…?

Just trying to understand the lifecycle, thanks! Sorry this got long

Also, just so people don’t think I’m crazy person. You can tell exactly when I switched from Cloudflare APO to Cache Everything Page Rule.

It seems like Cloudflare APO is good but not that good for WordPress sites that barely change. I imagine if I got a burst of huge amount of traffic, my origin is likely to crash with APO versus the cache everything page rule. Thoughts?

Help! Bump

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