How edge caching works

HTML cached at
Bunny's edge.

Most Bunny users are in proxy mode, but their HTML still comes from origin on every request. Here's exactly what changes when you cache HTML at the edge, and why it's safe.

The gap most Bunny users have

Proxied, but HTML still
hits your origin every time.

When Bunny is in proxy mode, your domain points to Bunny's network. Static files (images, CSS, JS) get cached at Bunny's edge and served fast. But HTML page requests travel through Bunny and land on your origin server, which has to run WordPress on every single request. Bunny is doing routing and TLS, but not caching what matters most.

Without edge HTML caching
Visitor
requests page
▶
routes to
Bunny PoP
no HTML cache
▶
fetches from
Origin server
runs WordPress
500 to 1200ms TTFB. Origin generates HTML on every single request.
With edge HTML caching, cache HIT
Visitor
requests page
▶
routes to
Bunny PoP
HTML in cache
▶
serves HTML
Visitor
receives HTML
Origin server, bypassed on this request
under 100ms TTFB. Origin never touched on a cache hit.
What you actually see

Three setups. Three very
different response times.

TTFB, time to first byte, is the clearest measure of edge caching impact. It's the time between the browser sending a request and receiving the first byte of HTML back. Everything the visitor feels as fast or slow starts here.

No proxy
500 to 1200ms
DNS only
Traffic goes directly to your origin server. WordPress generates HTML on every request regardless of visitor location. Every request pays the full server round-trip cost.
Proxy, no HTML cache
150 to 500ms
Bunny proxy only
Bunny handles routing, TLS termination, and caches static assets. But HTML is still fetched from origin on every request. You're paying for CDN without the main speed benefit.
Bunny plus this plugin
under 100ms
HTML cached at edge
Cache HITs are served directly from Bunny's nearest PoP. Your origin server is bypassed entirely. The response is already in edge memory, with no network hop to origin needed.

TTFB ranges reflect real-world cache hit measurements. Values vary by server location, host, and WordPress configuration.

Why Bunny is different from Cloudflare

Bunny doesn't have APO.
It has something more flexible.

Cloudflare APO is a product. You turn it on and it handles everything. Bunny works differently. Bunny has pull zones and edge rules: conditions and actions that run at the CDN layer before a request ever reaches your origin. That's actually more powerful and more persistent than Cloudflare Workers, but it means the rules need to be written and deployed correctly. That's what this plugin does.

Cloudflare APO
A managed product. Cloudflare handles the caching logic, bypass rules, and purging for you. Less control, less flexibility. Locked to Cloudflare's infrastructure and pricing tier.
Bunny edge rules What this plugin deploys
Condition and action pairs that run at Bunny's edge before origin is touched. You control exactly what gets cached, what gets bypassed, what headers get added, and what gets redirected. 74 rules, deployed via API, tracked by GUID so they can be safely redeployed.
Anatomy of a Bunny edge rule
Trigger
Condition that must be true
URL pattern, cookie presence, request header, remote IP, or response status. Multiple triggers can be combined with AND or OR logic.
Action
What happens when the condition matches
Cache the response, bypass cache, redirect, override TTL, add or remove headers, disable WAF, force SSL. Each rule has one primary action.
Extra actions
Optional secondary actions on the same match
Chain additional actions onto the same rule. For example, bypass cache and disable WAF in a single rule for the wp-admin path.
// Rule 04, bypass cache for logged-in WordPress users Trigger: Cookie matches *wordpress_logged_in_* Action: Override cache TTL to 0 (bypass) Order: 4 // runs before the HTML cache rule at slot 11
The full cache lifecycle

From cold edge to warm
cache and back again.

Understanding the full lifecycle helps you reason about what visitors experience at each stage, and where purge sync and cache warming fit in.

01
Cold start, first request after a purge
After a purge (or on first install), the edge has no cached HTML. The first visitor request for each page travels through to origin. WordPress generates the HTML, returns it, and Bunny stores a copy at the edge PoP that served the request.
Origin hit
02
Warm cache, all subsequent requests
Every request to that page from the same Bunny PoP now returns the cached copy in edge memory. Origin is never contacted. Response time drops to under 100ms TTFB because no network hop is needed.
Edge HIT
03
Cache warmer fills the gap
The plugin schedules a WP-Cron job after every full purge. It crawls your sitemap, in configurable batches with a delay between each, making requests to pre-warm the edge before real visitors arrive. This eliminates the cold-start TTFB spike after you publish or clear cache.
Cron plus Edge fill
04
Content changes, purge triggered
When you publish a post or your cache plugin clears its cache, this plugin intercepts the purge hook and fires a matching Bunny API call. Where the cache plugin sends specific URLs (like WP Rocket does), Bunny purges just those pages. Full clears wipe the entire zone.
Purge, then Origin hit
05
Back to warm, the cycle repeats
After the purge, the warmer fires again. The edge fills from fresh origin responses. Visitors get sub-100ms TTFB. The cycle continues on every publish event.
Edge HIT
Cache decisions

What gets cached.
What always bypasses.

The 74 edge rules make a decision on every request before it reaches origin. Here's the split between what gets served from edge cache and what always goes to origin, and why.

Served from edge cache
Anonymous page requests. Visitors with no WordPress session cookies and no cart contents get HTML from edge memory.
Public CPT pages. Blog posts, product pages, LMS course listings, and event archives. Any public URL that renders the same HTML for all visitors.
Static assets. CSS, JS, images, fonts, and webfonts cached at the edge with long TTLs and query string ignored.
Search engine crawlers. Bots have no session cookies and benefit from edge-cached HTML the same as anonymous visitors.
Always bypasses to origin
Logged-in users. Any request with a wordpress_logged_in_* cookie bypasses the HTML cache entirely.
Cart and checkout. Session cookies from ecommerce plugins trigger per-visitor bypass so cart contents are never served from cache.
POST requests and AJAX. All non-GET requests bypass the cache so form submissions and AJAX calls always reach origin.
wp-admin, REST API, WP-Cron. All administrative and API paths bypass cache and WAF inspection where configured.
Member dashboards, LMS portals. Pages that render user-specific content are bypassed using page IDs read from each plugin's own settings.
Search results. URLs containing query strings from WordPress search bypass cache to prevent indexing search result pages.
What to expect

What a healthy cache
hit rate looks like.

Cache hit rate is the percentage of requests served from edge memory without touching your origin. A well-configured site with reasonable traffic should sit above 85%. Here's what drives it up and what pulls it down.

Typical well-configured site 88 to 96%
High-traffic ecommerce (many logged-in users) 60 to 80%
Members-only site (most visitors logged in) 20 to 50%
High anonymous traffic
The more visitors arriving without a login session, the higher your cache hit rate. Blogs, marketing sites, and content sites typically see the best numbers.
Cache warmer active
A warm edge after every purge means fewer cold-start misses. Pages that get warmed before traffic arrives count as hits from the first real visitor.
Longer cache TTL
Pages cached for 7 days accumulate more hits per miss than pages cached for 1 hour. Infrequently updated sites can safely use long TTLs.
Many logged-in users
Every logged-in user bypasses the HTML cache by design. Membership sites, LMS platforms, and community sites will see lower hit rates. That's expected and correct.
Frequent full purges
Every full cache clear resets your hit rate to zero until pages warm back up. Per-URL purges (available with supported cache plugins) only clear changed pages, keeping the rest warm.
Unique query strings
If your site generates many unique URLs via query parameters, each variant is a separate cache entry. The static file rules ignore query strings. HTML rules do not by default.

Ready to cache HTML
at Bunny's edge?

Free on WordPress.org. Connect your API key, deploy the 74 rules, and your HTML is edge-cached in minutes.

Install Free on WordPress.org View Getting Started Guide
Free forever • GPL-2.0+ • WordPress.org • Tested up to WordPress 7.0

This website uses cookies to enhance your browsing experience and ensure the site functions properly. By continuing to use this site, you acknowledge and accept our use of cookies.

Accept All Accept Required Only