Edge Cache: Turning a Dynamic WP into Something as Fast as Static
Learn how to configure Edge Cache in Cloudflare for WordPress portals and guarantee instant load times without sacrificing your admin panel.
Migrating a WordPress site to a modern Headless architecture using Astro is the ideal scenario for achieving maximum speed and security. However, we know that there is not always the time or budget available to completely rewrite a complex portal that is already up and running.
In these cases, the best alternative is not to clutter your WordPress dashboard with heavy and unstable caching plugins. Instead, we can move the caching entirely outside of the host server using Cloudflare’s Edge Cache.
The TTFB nightmare in traditional WordPress
When a visitor accesses a standard WordPress site, the hosting server must:
- Receive the HTTP request.
- Initialize the PHP core and load dozens of plugins.
- Make queries to the MySQL database to assemble the header, post content, widgets, and footer.
- Process the resulting HTML and finally send it back to the user’s browser.
This process generates a high Time to First Byte (TTFB), often exceeding 1 to 2 seconds on shared hosting. TTFB is the time the browser spends waiting just to start receiving the first bytes of page data. If the TTFB is slow, the entire page load is dragged down, impacting Google Core Web Vitals.
What is Edge Cache and how it works
Cloudflare has hundreds of globally distributed datacenters (so-called edge servers). By default, Cloudflare only caches static files like images, CSS stylesheets, and JavaScript. Page HTML is passed directly through to your WordPress server.
Edge Caching (or Cache Everything) changes this rule. It forces Cloudflare to save a static copy of all the HTML code generated by your blog pages.
This way, when a second visitor tries to access the same post, Cloudflare serves the static HTML directly from the datacenter closest to them (often in under 50ms), without the request ever touching your hosting server.
Practical setup in Cloudflare
To implement full HTML caching safely without breaking the WordPress dashboard, follow this configuration recipe in your Cloudflare dashboard:
- Go to your domain and navigate to Caching > Cache Rules.
- Click Create Rule.
- Define the matching criteria so that caching is triggered for most visitors but ignores administrative paths. For example:
- If URI Path does not contain
/wp-admin/ - And URI Path does not contain
/wp-login.php - And Cookie header does not match
.*wordpress_logged_in_.*
- If URI Path does not contain
- In the rule action, under Cache eligibility, select Cache everything.
- Set the Edge TTL to define how long the HTML copy remains stored on Cloudflare servers before checking for new updates on the origin server (e.g., 2 to 4 hours for standard blogs).
Avoiding issues with dynamic areas and the admin panel
The biggest risk of caching full HTML pages is exposing private admin pages or showing personalized content (like shopping carts in WooCommerce) to the wrong visitors.
To prevent this:
- Cookie Bypass: Step 3 of the rule is critical. The
wordpress_logged_in_cookie is set by WordPress whenever a user logs in. By instructing Cloudflare to bypass cache when this cookie is present, we ensure that logged-in users always see the dynamic, live version of the site. - Cache Purge Integration: Use a lightweight caching plugin in WordPress (such as WP Super Cache or LiteSpeed Cache) configured to trigger an automatic purge of the Cloudflare cache via API whenever you update or publish a post. This ensures that the edge is updated instantly without waiting for the Edge TTL to expire.
By offloading the heavy rendering work to Cloudflare’s global network, your WordPress site will load in milliseconds with virtually zero server load.