enable_edge_caching: Agent-Applied Cloudflare Edge Caching

enable_edge_caching is the tool the Get AI Traffic agent uses to turn on Cloudflare HTML edge caching after you approve a fix. It adds a cache rule to your Cloudflare zone so your pages can be served from a node near the visitor instead of rebuilt by your origin on every request.

This page documents what the tool touches, what it refuses to touch, and how to undo it. For whether a slow origin is actually your problem and whether caching is the right call, read Your Cloudflare Cache Is Empty, and Your Server Is the Bottleneck. That’s the diagnosis. This page is the mechanics.

What it does

The tool reads your zone’s current cache-settings rules, then adds one rule that marks your site’s HTML as eligible for edge caching, scoped to your domain host. It writes the rule through your site’s Cloudflare connection, using a zone-scoped token resolved server-side. Once it lands, a Cloudflare node near the visitor can answer a request from cache instead of passing it to your origin.

The rule is merged into your existing rules, not written over them: any rule the tool did not create is left in place, and re-running the tool replaces its own rule rather than stacking a duplicate.

If the site has no Cloudflare integration configured, the tool does nothing and returns a skipped status. It is Cloudflare-only. It cannot enable caching on a CDN it is not connected to.

What it will not touch

• Your other cache and page rules. The change is additive. Existing rules in the zone are preserved, and only the tool’s own HTML-caching rule is added or refreshed.
• Your origin’s cache headers. The rule marks HTML as cache-eligible but sets no edge TTL override, so Cloudflare still honors the Cache-Control your origin sends. A page your server marks private or no-store, like a logged-in dashboard or a cart, is not force-cached by this rule.
• Anything outside Cloudflare. Caching at other layers (your host, another CDN, a reverse proxy) is not visible to this tool and not changed by it.

Timing

Cloudflare ruleset changes are not instant. A new cache rule typically takes about 30 to 60 seconds to propagate across the edge before requests start being served from cache. After that, the first request to each page still fills the cache from your origin (a MISS), and later requests are served from the edge (a HIT). Do not judge the result on the first hit to a page.

Rolling back

Before writing the rule, the tool records the prior cache-settings rules to the ledger. roll_back re-applies exactly those captured rules, removing the HTML-caching rule and restoring the zone to its previous state.

Related tools

• purge_cache clears a URL from the Cloudflare edge so the next read sees your live origin, not a stale cached copy. The agent runs it after applying changes so an edit is not masked by an old cached page. Once caching is on, it is also how you force a single page to refresh instead of waiting for the cache to expire.
• enable_image_optimization turns on Cloudflare Polish and WebP delivery, a separate Cloudflare change that speeds up how your images load rather than how your HTML arrives.

Findings this tool resolves

• no_edge_caching: your HTML is served dynamically with no edge cache in front of it, the cf-cache-status: DYNAMIC case.
• slow_lcp: when the LCP bottleneck is a slow origin response (time to first byte), edge caching removes the origin round trip. When the bottleneck is on the page itself, the fix is elsewhere.