I was looking forward to the "why it took us this long" explanation but it wasn't explicitly spelled out. Any Cloudflare staff here able to expand on that?

(The article does a good job of showing how many different smart design decisions went into this, but given caching is core to what a Cloudflare does I'm still a little surprised it took 9 years to get here!)

On top of that the cache tags are a slick way to do invalidation. This looks like a great product.

- You still get billed per request, whether the request hits cache or not (but don't get billed for CPU time)

- You now get billed for static asset requests! This makes no sense to me. "One thing to watch: when caching is enabled, requests that are normally free — static asset requests and worker-to-worker invocations through service bindings or ctx.exports — are billed at the standard request rate, because each one now consults the cache in front of your Worker." Yeah that sounds like a bug that just happens to generate them more money.

- The cache key automatically has the worker deployment version, so even gradual deployments populate their own cache which is nice

- It seems like you can set a totally custom cache key? But that was previously Enterprise only, can't see if that's still the case here.

Time to migrate rarely-updating websites that still need a CMS to Cloudflare.

> One thing to watch: when caching is enabled, requests that are normally free — static asset requests and worker-to-worker invocations through service bindings or ctx.exports — are billed at the standard request rate, because each one now consults the cache in front of your Worker.

That’s a very weird limitation from a product standpoint. You might end up spending more money by enabling caching.

I wonder if static assets and worker-to-worker invocations are really more expensive to them with caching enabled, or if this is just a metering problem.

I would have made this free in the interest of making billing simpler and of making the decision to enable caching more straightforward.

If you’re min-maxing costs, this encourages awkward setups where you split workers into two, one with caching enabled and one with caching disabled.

A big worry was always "why does workers sit in front of my cache? that's a waste of an invocation if i'm returning a cached result"

Thanks CF.

  When Workers Cache is enabled, every cacheable request to your Worker hits Cloudflare's cache first. If there's a fresh cached response, Cloudflare returns it directly — your Worker doesn't run, and you don't pay CPU time for it. On a miss, your Worker runs, and if your response is cacheable, Cloudflare stores it for the next request. The next request from anywhere on Earth can be served straight from cache.

I know about the infamous "Enterprise plan" (especially, when your bandwidth is as high as ours in 100s of TBs) and know of at least one other tech shop that was required to pay for it ... but we haven't got that sales call, yet.

I am assuming it is a bunch of manual work.

I just don’t understand why undermine your own announcements by delegating comms to the machine. It’s disrespectful to the reader.