Cloudflare performance tuning beyond the default cache rules
The default cache rule caches what is obviously cacheable. Real performance lives in the rules nobody writes by default, the ones specific to your traffic.
Cloudflare caches the obvious assets at the edge the moment it is turned on: images, CSS, JavaScript bundles, the files every site already knows are cacheable. That default is real value, delivered with zero configuration. It is also a small fraction of what a properly tuned account actually gets you.
The performance that shows up in Core Web Vitals, and in a conversion rate that quietly improves, lives in the cache rules nobody writes by default: the API response that is safe to cache for sixty seconds, the personalized page that can still cache its shell while only the dynamic fragment stays live, the origin request that never needed to happen at all.
What the default leaves on the table
A default configuration treats every response the same way: cache the obvious, pass through everything else to the origin. Most applications have a middle tier the default never touches — content that changes, but not on every request, and every one of those requests that reaches origin unnecessarily is latency your visitor pays for and a bill your origin pays for.
Routing and image delivery, not just caching
Argo Smart Routing picks a faster path across Cloudflare's own network when the direct route is congested, which matters most for visitors furthest from your origin. Polish re-encodes images for the requesting device automatically, which is the kind of gain that never shows up in a code review because nothing in the application changed — only what left the edge did.
None of this replaces fixing an actually slow endpoint. It is what happens after that endpoint is fixed, when the remaining latency is mostly network distance and payload size rather than application logic.
Deciding what is worth tuning yourself
Some of this is a genuine build-versus-buy question: writing your own edge caching logic in a Worker is possible, and occasionally the right call for something Cloudflare's rule engine cannot express — but for the common cases, that is reimplementing a feature the platform already offers, at a cost of a system you now have to maintain yourself.
We tune caching, routing, and image delivery as part of our Cloudflare implementation practice, using the same engineering judgment we apply to any performance work: measure first, change one thing at a time, and keep whatever the platform already does well.
Check your own case
Where does your team stand on this?
The article describes the pattern. These take your answers and tell you which part applies to you — no signup to see the result.