WordPress Edge Caching, Now Running on Workers

Cloudflare's Automatic Platform Optimization for WordPress is now live, and the implementation is notable for where the logic runs: not on the origin server or the client, but in Cloudflare Workers at the edge. The service builds on earlier concepts around zero-configuration HTML edge caching and uses Workers KV to address the cold-start problem for HTML content across Cloudflare's network.

The feature works with or without the Cloudflare for WordPress plugin. With the plugin, cache invalidation happens in about 30 seconds; without it, invalidation can take up to 30 minutes unless a manual purge is triggered. In both cases, HTML is cached at the edge with a 30-day TTL, and WebP images are optimized automatically regardless of plugin status.

While the launch targets WordPress, the underlying approach is generic and could apply to other content management systems.

Why Move Plugin Logic to the Edge?

Performance-focused WordPress plugins traditionally run on the origin server alongside the CMS. That introduces maintenance overhead and requires tuning for each plugin's security and performance settings. Client-side optimizations bring their own problems, notably the execution cost of JavaScript in the browser.

Running these optimizations inside Cloudflare Workers avoids both issues. The code runs on Cloudflare's infrastructure, is kept up to date with current best practices, and isn't subject to per-server configuration drift. The worker executes from every edge data center, with scaling handled by the serverless platform itself.

The Default HTML Caching Gap

By default, the Cloudflare CDN caches assets based on file extension and does not cache HTML. Configuring HTML caching is possible via a Cache Everything page rule, but that's a manual process and frequently requires Business or Enterprise plan features. For most WordPress sites behind a CDN, HTML requests travel all the way to the origin.

Even with a CDN optimizing the connection between the nearest edge and origin, the origin may be far from the user or slow under load. Round-trip time to the origin affects connection setup, SSL negotiation, and time to first byte. Edge caching of HTML addresses this directly. While HTML is sometimes viewed as dynamic, the vast majority of page views are anonymous users requesting content that changes rarely.

Caching Rules and Headers

Implementing edge HTML caching requires explicit rules on what to cache and when to refresh. The plugin communicates these rules to the edge via a custom header, cf-edge-cache, added to every origin response. Two values are possible:

  • cf-edge-cache: no-cache — the page contains private information and should not be cached.
  • cf-edge-cache: cache, platform=wordpress — the page is eligible for caching, subject to additional cookie checks.

If the header is absent, the feature assumes the plugin isn't installed and operates in plugin-less mode. The worker never caches a response unless all of these conditions are met:

  • Origin returns a 200 status.
  • Response content type is text/html.
  • Request method is GET.
  • Request path has no query strings.
  • Request contains no WordPress-specific cookies: wp-*, wordpress*, comment_*, woocommerce_* — with exceptions for wordpress_eli and wordpress_test_cookie.
  • Request contains none of these headers: Cache-Control: no-cache, Cache-Control: private, Pragma: no-cache, Vary: *.

Caching is also bypassed when browser devtools are open with "Disable cache" enabled.

Plugin vs. Plugin-less Operation

The recommended setup uses the Cloudflare for WordPress plugin. It provides HTML edge caching with 30-day TTL, cache invalidation in roughly 30 seconds, bypass for logged-in users and WordPress-specific cookies, and reduced origin load because requests served from the CDN cache never reach the origin.

Without the plugin, the feature still caches HTML, but the behavior differs in important ways:

  • Cache invalidation may take up to 30 minutes; a manual purge speeds it up.
  • Cookies still trigger cache bypass.
  • Origin load is not reduced: even for cache hits, the origin receives a request to apply revalidation logic.

In plugin-less mode, the stale-while-revalidate logic runs after the response is served to the user.

Revalidation Strategy

Revalidation without the plugin relies on a handful of HTTP headers. The worker compares the cached version against the origin response:

  • ETag: if cached and origin versions both have ETags and they differ, the origin response replaces the cached copy. This applies to strong and weak ETags alike.
  • Last-Modified: if both versions carry Last-Modified and the origin date is newer, replace the cached copy.
  • Date: when no ETag or Last-Modified is present, compare Date values. A difference greater than 30 minutes triggers a replacement.

When the plugin is present, the invalidation path is cleaner: the plugin calls the Cloudflare API, which purges the cache and marks content stale.

KV for Global Cold Starts

The regular Cloudflare cache works well for frequently requested content. But for a typical personal blog, cached content may exist only in a subset of the edge network. To improve cold-start loading times globally, the worker also stores content in Workers KV.

Workers KV is a single namespace storing content keyed by zone identifier and URL:

Stale markers are separate keys: when present at the edge, the worker knows to revalidate. After successful revalidation of updated content, the stale marker is deleted. This design means content becomes readable from any data center within about a minute after a single request populates KV.

When stale content is served, the worker fetches new content from the origin asynchronously, applies optimizations, and caches the result both in the local CDN cache and globally in KV.

Edge Transformations for Google Fonts

Beyond caching, the worker can pre-process HTML. Google Fonts, for example, typically require the browser to load an HTML page, then a CSS file from one domain, and then font files from another. That sequence introduces performance penalties.

The worker inlines the CSS and serves fonts directly from the edge, reducing the number of connections required. This transformation runs as a background task that doesn't block the response to the user; once complete, it updates KV and replaces the global cached version.

Earlier implementations needed roughly 600 lines of code for streaming HTML processing and character encoding support. Workers platform improvements — specifically a streaming HTML rewriter with CSS-selector API and support for asynchronous fetch during parsing — cut that to under 200 lines.

The Automatic Platform Optimization launch is WordPress-first, but the architecture is generic, marking a new place for CMS plugins to run: at the edge, on the Workers platform.