Workers Cache

> This is the caching API we've always wanted Workers to have. Here's why it took us this long

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!)

Huge props to just sticking with the HTTP spec on this one with `Cache-Control` headers with `stale-while-revalidate` support. It's amazing how many other providers mess that up.

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

Great feature. Although I’m starting to get annoyed by obvious signs of LLM writing like no X, no Y etc.

I was a bit confused what this adds other than just standard CDN-Cache-Control page caching that we do now. Some quirks I've found;

- 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.

Finally :)

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.

finally, this was needed.

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"

The previous Worker in-front of the cache never made sense to my old school proxy in-front of the appserver mindset. Already using this to speed up a tool. Nice work.

Amazing, exactly what Workers lacked, I was quite annoyed that a worker would spin up when 99% of my requests then return a cache. Waste of 3ms, times millions.

i just love the sweet $0 invoice at the end of each month for all these services.

Thanks CF.

Finally proper stale-while-revalidate support!

Reinventing the web, one service at a time. Is it really that hard to build things like this on a per-case base, small scale, all on a bare bones VPS? Do we need a global gateway to help us not screw up the basics? Service looks nice but makes me sad somehow.

  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.

curious, how does one configure something like this for AWS Lambda? Appreciate it.

I am assuming it is a bunch of manual work.

The feature is great. The post itself is a slop grenade.

Does anything beat a free static site hosted with Cloudflare workers at this point, performance wise?

now, waiting for opennext adapter maintainers to catchup with it

Please please please write your own blogposts. I already read “but here’s the biggest unlock, and it’s the part that’s hardest to see” all day.

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

[dead]