FAQs

No, you do not need create Edge Cache TTL page rules. When the WordPress plugin is installed, APO automatically caches content for 30 days and invalidates on change within 30 seconds. However, because APO now supports cache-related page rules, make sure existing page rules do not affect the resources served by APO.

No. APO ignores Origin Cache Control for caching on the Edge, but APO serves original Origin Cache Control to the client.

The browser cache control headers may be missing with APO if you set your Browser Cache TTL to Respect Existing Headers. For example:

curl --silent --verbose --output /dev/null https://example.com/ --header 'Accept: text/html' 2>&1 | grep cache-control

< cache-control: max-age=86400, stale-while-revalidate=86400, stale-if-error=86400

No, the stale-if-error directive is not needed because the feature is built into APO.

When Chrome DevTools is open, Chrome sends Cache-Control: no-cache by default. You can uncheck the Disable cache (while DevTools is open) setting and see that cf-cache-status: HIT and cf-apo-via: cache headers will be returned.

APO decides whether a request is eligible for HTML caching based on the request's Accept header and its URL path:

• If the Accept header includes text/html (with a quality value greater than zero), the request is treated as an HTML request and is eligible for caching.
• If the Accept header explicitly refuses HTML (Accept: text/html; q=0), the request is not cached as HTML.
• If the Accept header does not mention text/html — including Accept: */* or a missing Accept header — APO evaluates the URL path instead. Requests for non-static paths (such as a page or post) remain eligible for HTML caching, while requests for static file extensions do not.

Some testing tools send no Accept header. For these requests, APO uses the URL path as described above, so the cache result depends on the requested path and the other eligibility criteria. To reliably reproduce a browser-like HTML request, include -H 'accept: text/html' in your cURL command.

Yes, Google Fonts are also optimized when APO is activated. You can confirm the optimization by checking the font URLs. For example, the URL will change from https://fonts.gstatic.com/s/... to https://example.com/fonts.gstatic.com/s/... when the site loads. For proxied fonts, the cf-apo-via:proxy header is returned.

For more information on query parameters, see Query parameters and cached responses.

APO will skip URL font transformation when the content-security-policy response header is present but missing the values described below.

To fix the problem, the content-security-policy header value must allow for unsafe-inline on either the style-src or default-src directive. For example, Content-Security-Policy: style-src unsafe-inline;.

The header must allow for self on either the font-src or default-src directive. For example, Content-Security-Policy: font-src self;.

APO uses Cloudflare Workers internally to optimize content delivery, which results in Worker subrequests. These subrequests may appear in your zone logs (for example, via Logpush).

It is not uncommon for mature plugins to see no updates for longer periods than it takes to trigger the WordPress not tested warning. The warning is for notification purposes and is not an indication that a plugin no longer works. It is still maintained.