Cloudflare’s content delivery network (CDN) is probably the most known Cloudflare product - and with good reason, it provides great performance, global reach, and has a great free tier. But when building an application with Cloudflare Workers and the rest of the developer platform, there are countless other ways to cache data on Cloudflare’s global network to improve application performance.

Here’s a quick overview of the various ways to use caching within your Cloudflare components (and when to rely on them):

• Cloudflare CDN: Cloudflare’s CDN is the traditional way of caching responses from a web server, where entire pages or web responses are generated on an external origin server and cached by Cloudflare’s CDN.

  • When to use: When your web application is self-hosted or on an external cloud and you want to cache your server’s response to speed up responses and decrease the load on your origin server. To do this, add the CDN in front of your site and configure your cache headers in your server’s responses.

• Cloudflare Workers’ Cache API: The Workers’ Cache API gives us a way to write and read from the cache at the location the Worker is running. It’s practical if you’re making a subrequest to an origin server/API call from your Worker code and want to cache the response, but can also be used for arbitrary data by wrapping it in a JavaScript Response.

  • When to use: When you are building an application on Workers and need to reduce calls to an external API or provide faster responses. Writing Workers also provides you with more flexibility over your caching logic than the CDN’s cache rules.

• Cloudflare Workers KV: Workers KV is an edge key-value database that is replicated globally which can be used to cache data. Writes to Workers KV are eventually distributed globally, unlike Cache API, which can be important for your application. (Workers KV itself heavily uses caching within it’s internal architecture, including tiered cache, to provide extremely quick response times for cached data).

  • When to use: When you are building an application on Workers and need a single global cache. You can also use Workers KV outside of caching use-cases, by using it as a key-value database to retrieve unstructured or semi-structured data within your application or serving static assets. The common use cases are application configuration data, routing data, A/B testing configurations, authentication & block-lists, as these are all read-heavy.

• Cloudflare Hyperdrive: Hyperdrive enables your regional databases to be performant when building global applications with Workers by providing connection pooling and caching. When caching is enabled on your Hyperdrive instance, query responses will be cached to provide faster responses.

  • When to use: When you have data in a regional database that you need to access from the edge. Hyperdrive’s caching can be especially useful if you are storing user configurations in your regional databases but need fast access from the edge. The common use cases for Workers KV are also common with Hyperdrive.

• Cloudflare AI Gateway: AI Gateway allows you to cache responses from text or image generation LLM providers to make your LLM-enabled interactions faster and to reduce your costs on your AI infrastructure. It can be placed in front of your existing AI providers and will reverse proxy to your original provider.

  • When to use: This is especially applicable when you provide customers with common ‘getting started’ input ideas, such as “What does your company do?” or “How much time do I have to wait for my package?”. These are common for customer service chatbots which get the ball rolling and can easily be cached because of the lack of any customer-specific conversation context.

All of the above methods allow you to cache pieces of data, small or large, across Cloudflare’s network to improve your application’s performance. It’s quite possible that you use all of these in various areas within your architecture.

How granular caching leads to better app performance

By using more granular caching with the options provided with the Cloudflare developer platform, you increase the likelihood of cache hits which directly improves your app performance: more requests get resolved at the edge, close to your users.

For instance, a request for data A, B, C will cache A, B, C, and subsequent requests for all permutations of that data (A, A & B, C & B, etc.) will be resolved from Cloudflare’s cache on the edge. This isn’t possible when caching entire server responses as only requests for data A, B, C will be considered a cache hit.

On the left-hand side of the diagram, web requests made through a CDN to a server can only cache complete requests and responses. On the right-hand side, Cloudflare Workers can cache pieces of data individually since they can be programmed as desired, and granular caching enables subsequent requests for subsets of that data to be fulfilled on the edge within Workers & the Cloudflare cache network.

Notes

There are also other places where you’ll see cache mentioned in the Cloudflare documention, though in completely different contexts which aren’t directly related to your application performance. For instance Cloudflare Workers’ Build Caching allows you to speed up build times for your Workers applications by storing and retrieving build outputs and dependencies on subsequent builds.