Automatic Platform Optimization post-launch report

Automatic Platform Optimization: A look at real-world performance data

Cloudflare launched Automatic Platform Optimization (APO) for WordPress during last year's Birthday Week, bringing smart HTML caching to WordPress sites on the Cloudflare network. Synthetic tests at launch showed strong gains in metrics like Time to First Byte (TTFB), First Contentful Paint (FCP), and Speed Index. Now, with APO having been live for a while, we can examine how it performs for real customers under real-world conditions.

This analysis focuses on two key questions: how much faster APO makes WordPress sites, and how well it fits into existing WordPress setups, including sites running other plugins. The performance data comes from two sources: WebPageTest for controlled synthetic testing and Google's Chrome User Experience Report (CrUX) for real-user metrics.

Synthetic testing with WebPageTest

Cloudflare uses WebPageTest as its go-to tool for synthetic testing. It runs in real browsers, is highly programmable, and can scale to test millions of sites per day. Synthetic testing offers easily reproducible results, making it useful for comparing performance before and after a change.

Internal APO testing with WebPageTest showed a 72% reduction in TTFB and a 23% reduction in FCP. The original launch post has the full test setup and methodology.

Real-user data: Before and after APO

Synthetic testing only tells part of the story. Real User Monitoring (RUM) captures how sites actually perform across different devices and connection types. The noise-to-signal ratio in RUM data is higher, but it's the only way to see performance in the wild.

We pulled CrUX data for nearly 200 WordPress sites with APO enabled and compared two months of data before activation to two months after. To avoid any transition effects, we excluded the month that included the activation date. For example, a site that activated APO in October would use August and September as the before bucket and November and December as the after bucket.

CrUX data is broken down by geographic location, form factor, and connection type. To focus on overall performance, we aggregated results across all countries and connection types. Note that CrUX results don't include iOS devices due to platform limitations.

We grouped results into three buckets — good, moderate, and poor — for each metric. The thresholds for these buckets are arbitrary for each timing metric, so the percentage changes are more meaningful than the absolute values.

Time to First Byte (TTFB)

TTFB measures the time from when a user makes an HTTP request until the first byte arrives back at the browser. This metric saw the largest improvement across the board.

TTFB showed the biggest increase in the 'good' bucket and the biggest decrease in the 'poor' bucket, on both desktop and phone. The improvement in the mobile 'poor' bucket highlights how APO helps even on slower connection types like 3G, 2G, and slow 2G. Faster responses from edge servers translate into quicker TTFB, and that has a positive knock-on effect on all other performance metrics.

First Paint

First Paint measures the first time the browser renders any content — the earliest point where something appears on screen after a request. It's a good proxy for whether a user believes the site is working.

Desktop saw nearly a 10% increase in the 'good' bucket — the standout result for First Paint. Both desktop and phone show a clear trend of improvement.

First Contentful Paint (FCP)

FCP measures when a page starts rendering text, images, non-white canvas, or SVG content. It's a good indicator of perceived speed, since it captures how long users wait to see the first signs of the site loading.

FCP is the third metric in a row showing improvement on both form factors after APO activation. FCP happens later in the loading sequence than First Paint, and the impact of APO is correspondingly smaller. The pattern suggests APO has the strongest effect on earlier loading events.

Largest Contentful Paint (LCP)

LCP reports the render time for the largest image or text block visible in the viewport.

LCP follows the same pattern as the other metrics. The positive impact of APO activation is relatively equal on desktop and mobile.

Working with other plugins

APO has gained a number of features and improvements since launch to smooth integration with existing WordPress setups. WordPress sites commonly run many plugins, and APO is designed to work alongside them while still providing full-page caching. Sites that need finer control can adjust APO behavior to fit their specific plugin configurations.

APO’s feature set grows with real-world needs

The fast iteration cycle made possible by running Automatic Platform Optimization (APO) on Workers has been a key advantage since launch. Instead of waiting days or weeks for a release, bug fixes and missing functionality have shipped within hours. Larger features, such as subdomain support and cache-by-device-type, took longer, but the ability to ship on demand has been valuable for both the team and customers.

The following features have been added since October, followed by a look at how APO interacts with the broader WordPress plugin ecosystem.

Marketing query parameter caching

APO does not cache URLs with query strings by default. The first community feature request was to support caching for marketing attribution parameters such as UTMs. That support is now in place, with a full list of accepted parameters available in the official documentation.

Cache hit ratio improvements

Cloudflare’s static caching relies on file extensions to identify content types. HTML pages do not always have such extensions, so APO instead uses HTTP content negotiation, checking the Accept and Content-Type headers for the text/html substring.

Browsers automatically send correct Accept headers, but bots often do not. Initially, requests without a valid Accept header bypassed the APO cache and hit origin servers. After customers migrating from the “Cache Everything” page rule reported extra origin load, APO now checks all GET and HEAD requests against the cache. This change raised the cache hit ratio globally and improved page loads for well-behaved bots.

Cache poisoning mitigations

Cache poisoning is a common attack vector against caching layers. Since APO runs most of its logic at the edge, it can be updated without origin changes. To reduce poisoning risk, APO now bypasses caching when any of the following request headers are present:

• X-Host
• X-Forwarded-Host
• X-Original-URL
• X-Rewrite-URL

Additionally, GET requests with a body bypass APO caching entirely.

Page Rules integration

APO aims to keep configuration simple, but advanced use cases need fine-tuning options. Cloudflare Page Rules provide that mechanism, and APO now supports the following rules:

• Cache Level: Bypass
• Cache Level: Ignore Query String
• Cache Level: Cache Everything
• Bypass Cache on Cookie (Business and Enterprise plans only)
• Edge Cache TTL
• Browser Cache TTL

Details are available in the official APO documentation.

Subdomain support

APO recognizes cookies from popular plugins like WooCommerce, Jetpack, BigCommerce, and Easy Digital Downloads, but the service was initially restricted to WordPress root domains. Customer demand led to subdomain support in both the WordPress plugin and the zone settings API.

Enabling APO on a subdomain requires three steps:

1. Install version 3.8.7 or later of the Cloudflare WordPress plugin.
2. Log in with a Global key; API tokens are only valid for the root domain.
3. Enable APO. The subdomain will appear in the hostname list on the APO card.

The $5 per month cost for Free plans covers any number of subdomains.

Cache by Device Type

With most traffic coming from mobile devices, responsive design works well with APO because cached content adapts to the client’s screen. However, sites using plugins that serve distinct mobile themes will break if all users receive the same cached page.

Cloudflare’s caching layer already offered cache-by-device-type functionality, but it was limited to Enterprise customers. APO now includes this feature, with detection based on the User-Agent header. Content is stored in separate buckets for three device types:

• Mobile
• Tablet
• Everything else

Enabling this option is done either in the APO dashboard card or via the WordPress plugin. A single shared cache is recommended whenever possible, as device-type splitting lowers cache hit ratios and increases origin load.

Additional updates

Other improvements include more robust KV purging infrastructure, extended automatic cache purging for categories and tags, edge-case fixes for Google Fonts optimization, and HEAD request support. The WordPress plugin also now ships through an automated release pipeline.

Plugin Compatibility: What Broke and How It Was Fixed

With more than 50,000 WordPress plugins available, Cloudflare cannot test Automatic Platform Optimization (APO) against every one. Community feedback quickly highlighted the most common friction points, which fell into six categories: custom cookies, geolocation, mobile themes, AMP support, plugins that generate HTML, and other caching/optimization plugins.

Custom Cookies and Geolocation

APO ships with cookie-based bypass rules, but plugins that set their own cookies need those rules extended. Cloudflare maintains a supported plugins list for this purpose.

Geolocation plugins were hit by a configuration bug. APO relies on Cloudflare Workers internally, and those Worker subrequests were treated as cross-zone requests, causing the CF-Connecting-IP header to be replaced with a dummy IP before reaching the origin. That broke geolocation-dependent plugins such as Wordfence Security. The fix was to make the subrequest same-zone so the real client IP passes through, and APO now also sends the client IP via the X-Forwarded-For header for broader compatibility.

Mobile Themes and AMP

Plugins that swap in a custom theme for mobile visitors detect devices from the User-Agent string. APO added support for the "Cache by device type" feature in December, letting you maintain separate caches for mobile, tablet, and other devices with one configuration change.

AMP pages are a different case. The most popular AMP plugins render AMP markup when the URL carries an amp= query parameter, which would require a separate cache namespace. Given the complexity and Google's shift toward Core Web Vitals over AMP, Cloudflare decided to bypass APO caching for AMP URLs instead. Two alternatives exist: change the AMP URL structure from site.com/page/?amp= to site.com/amp/page/, which APO will cache by default, or apply a "Cache Everything" Page Rule to the amp= URLs. Both approaches require manual purges when content changes.

HTML-Generating and Caching Plugins

Page Rules extend APO's usefulness with HTML-generating plugins: you can bypass caching for pages with CAPTCHAs, or cap the Edge TTL at six hours or less for pages serving nonces or server-rendered ads.

For the popular caching plugins—LiteSpeed Cache, W3 Total Cache, WP Rocket, WP Fastest Cache, WP Super Cache, and Autoptimize—the activation sequence matters. Install the Cloudflare WordPress plugin, enable APO, clear any existing server cache, and confirm the origin returns the cf-edge-cache: cache,platform=wordpress response header.

If those plugins are also performing optimizations—JS minification and async loading, CSS minification/inlining/aggregation, HTML minification, image optimization and lazy-loading, or Google Fonts optimization—the Cloudflare cache must be purged afterward. Cloudflare recommends three options, in order of preference:

1. Use Cloudflare products instead: Auto Minify handles HTML/CSS/JS; Rocket Loader lazy-loads JavaScript; Mirage and Image Resizing optimize images; APO optimizes Google Fonts out of the box.
2. Activate plugin integrations with Cloudflare: WP Rocket, WP Fastest Cache, and W3 Total Cache (with Page Caching enabled) can connect via the Cloudflare API.
3. Trigger Cloudflare cache purging manually or via API: Required for LiteSpeed Cache, WP Super Cache, and Autoptimize after their optimizations run.

As a last resort, disable the plugin's optimization features but keep its caching functionality. Work continues with the WordPress plugin community to close remaining compatibility gaps.

Post-Launch Results

APO has delivered measurable improvements in both synthetic tests and real-world traffic. The Chrome User Experience Report provided a solid RUM dataset; APO showed gains on desktops and phones alike, with TTFB the most improved metric. First Paint, First Contentful Paint, and Largest Contentful Paint also moved in the right direction.

The months since launch have been spent broadening APO's applicability based on customer feedback. The community forum remains the place for questions about Cloudflare products, and more APO updates are in active development.