WebPerf Cloudflare Cloudflare Wordpress Plugin Automatic Platform Optimization

The official Cloudflare Wordpress plugin has been updated to 3.8.0 with the new release of their Automatic Platform Optimization one click setting aimed to do intelligent Wordpress dynamic full HTML page caching and purging. This should dramatically improve Wordpress dynamic HTML page's TTFB (Time To First Byte) metrics for most people. It costs $5/month for Cloudflare Free plan users and is included, at no additional cost, for Cloudflare Professional, Business, and Enterprise plans. No usage fees. Part 2 write up added for Cloudflare Wordpress plugin Automatic Platform Optimization to evaluate the effectiveness of caching configuration on repeat visits and visits with common query strings like ?fbclid.
comma

Automatic Platform Optimization (APO)

Take your WordPress site’s performance to the next level with Automatic Platform Optimizations (APO). APO allows Cloudflare to serve your entire WordPress site from its edge network ensuring consistent, fast performance for visitors no matter where they are. Find out more in our announcement blog.

Cloudflare official support article at Understanding Automatic Platform Optimization (APO) with WordPress

When using the plugin the following applies:

• HTML edge caching with 30 days TTL
• 30 seconds or faster cache invalidation
• Bypass HTML caching for logged in users
• Bypass HTML caching based on presence of WordPress specific cookies
• Decrease load on origin servers. If a request is fetched from Cloudflare CDN Cache we skip the request to the origin server.

The Wordpress plugin now shows a one click option to enable Automatic Platform Optimizations.



On the Wordpress plugin settings page you will need to disable Auto Purge Content On Update as that is handled by Automatic Platform Optimization setting now

Cloudflare APO Cache Response Headers Explained

The following is a list of Cloudflare Automatic Platform Optimization cf-apo-via response headers explained:

cf-apo-via:

• cache. Page is served from cache.
• KV. Page is served from KV.
• origin,bypass. Page is served from origin, request comes from subdomain.
• origin,cookie. Page is served from origin, cookie matched the list of bypassed cookies.
• origin,miss. Page is served from origin, both cache and KV didn’t have the resource.
• origin,no-cache. Page is served from origin, request contains “Cache-Control” header with value “no-cache” or “private”.
• origin,noget. Page is served from origin, request is not a GET.
• origin,qs. Page is served from origin, query string is not in the list of marketing query strings.
• origin,resnok. Page is served from origin, origin returned non 200 status, we cache requests with 200 status only.

Does Cloudflare Automatic Platform Optimization Replace Need For JS/CSS Optimization Wordpress Plugins?

Cloudflare Automatic Platform Optimization does not replace the need to optimize the delivery of your JS/CSS files by itself. Cloudflare Wordpress plugin has a separate setting Apply Recommended Cloudflare Settings For Wordpress which applies certain Cloudflare level optimizations which may optimize your JS/CSS files. When enabled they apply the following Cloudflare settings site zone wide (applies to every DNS proxied orange cloud record):

• Security level Medium
• Caching level Standard
• Auto Minify Enable Auto Minify for JS, CSS, and HTML
• Browser Cache TTL 4 hours
• Always Online On
• Development Mode Disabled
• IPV6 Compatibility Off
• WebSockets On
• IP Geolocation On
• Email Address Obfuscation On
• Server-side Excludes On
• Hotlink Protection Off
• Image optimization (Polish and Mirage) Off (unless on Pro or higher plan)
• Rocket Loader Off

You can see the Auto Minify for JS, CSS and HTML, browser cache and caching level are the Cloudflare settings which most like impact your CSS/JS file delivery.

Generally, I have my own settings for the above, so do not click Apply Recommended Cloudflare Settings For Wordpress and manually setup those settings at site global zone level and per subdomain host via Cloudflare page rules.

As such, to me 3rd party Wordpress plugins will optimize JS/CSS file delivery are still useful. I usually use Autoptimize Wordpress Plugin + Autoptimize Gzip companion Wordpress plugin to optimize Wordpress JS/CSS files and is also used in below page speed tests.

Current Wordpress Automatic Platform Optimization Limitations & Updates

More info has come to light on some of the current limitations for Cloudflare's Wordpress Automatic Platform Optimization features. For most up to date info on Cloudflare APO bookmark this link at Understanding Automatic Platform Optimization (APO) with WordPress

1. As at Jan 20, 2021 - Cloudflare plan to deprecate supporting CF APO without using the Cloudflare Wordpress plugin. So only way to enable CF APO in future is if you also install Cloudflare Wordpress plugin first.
2. December 8,, 2020 - Cloudflare Wordpress Plugin v3.8.7 as added Cache By Device Type key cache support - APO cache by device type allows you to cache content by device type. This allows all the benefits of Cloudflare's cache while targeting visitors with content appropriate to their device. Cloudflare evaluates the User-Agent header in the HTTP request to identify the device type. To enable caching by device type either navigate to dashboard's APO card or in Cloudflare for WordPress plugin version 3.8.7 or later. Once enabled, Cloudflare sends a CF-Device-Type HTTP header to your origin with a value of either mobile, tablet, desktop for every request to specify the visitor’s device type. If your origin responds with the appropriate content for that device type, Cloudflare caches the resource only for that specific device type.
3. November 27, 2020 - Cloudflare intends to deprecate Cloudflare Automatic Platform Optimization without Wordpress plugin support method and only support Cloudflare APO when using Cloudflare Wordpress plugin.
4. Unable to use API Token with Wordpress template for plugin. I have a CF support ticket which came to the conclusion the plugin is treating the API Token like the Global API Key and giving me the error 'Email address or API key invalid'. Using the Global API Key is okay though. Update as at Oct 22, 2020 the verdict is that the regex used to distinguish between API token and global key has a bug and next Cloudflare Wordpress plugin version should have a fix for it which would be v3.8.6. Update as at Jan 8, 2021 - there is no fix for this - API Tokens aren't guaranteed to work properly. So you may only be able to use CF global API Key.
5. Cloudflare Automatic Platform Optimization will only cache HTML pages which are requested with a HTTP Accept text/html header and via GET requests. This means some requests which do not use a HTTP Accept text/html header, will end up bypassing Cloudflare APO based cache. For example, Google Translate requests do no send Accept text/html headers. Nor does Google PageSpeed Insights service which doesn't send Accept text/headers.
6. Only a select few default Wordpress cookies are supported to determine Cloudflare CDN cache bypass for logged in Wordpress users (see here). So if you have 3rd party Wordpress plugins i.e. who have their own cookies, it won't work properly and you'd end up serving logged in Wordpress private info to the public via Cloudflare CDN cache! An update has added cookie support for Easy Digital Download (EDD) plugin.
7. Wordpress support and detection only works on domain's main zone apex i.e. main domain.com and doesn't work on subdomains (see here). Only remedy right now is if you have Cloudflare Enterprise plans, you can move a subdomain to it's own site zone as a separate site. Update November 20, 2020 Wordpress plugin update now supports subdomain Cloudflare APO when using Cloudflare Global API Key only i.e. with subdomain.domain.com. See instructions here. Cloudflare API Tokens only support domain apex i.e. domain.com.
8. As APO works on entire site zone, APO cache will also cache any non-Wordpress content on Wordpress site according to Cloudflare.
9. The main domain also needs to have a DNS A/AAAA record and can't be a CNAME record.
10. Real visitor IP address detection is lost when Wordpress Automatic Platform Optimizations are enabled. Update: Wordpress Cloudflare plugin issue is now fixed. Update your plugin and purge your Cloudflare cache.
11. Woocommerce large file downloads broken
12. Cloudflare Wordpress APO breaking Google Fonts. Update: Wordpress Cloudflare plugin issue is now fixed. Update your plugin and purge your Cloudflare cache.
13. Common tracker related query strings are not cached and bypass Cloudflare CDN cache. Update on Oct 10, CF reports next week they should support a group of common query string trackers - the same regex list I used for Cache Enabler query string caching.
    Code (Text):

    /^fbclid|ref|mc_(cid|eid)|utm_(source|medium|campaign|term|content|expid)|gclid|fb_(action_ids|action_types|source)|age-verified|ao_noptimize|usqp|cn-reloaded|_ga|_ke$/

    
    Full list is available at here.
14. Broken RSS feeds
15. As at Oct 21, 2020 there are no plans to add UI support for allowing users to add URLs to exclude from APO caching. Instead, users will need to add code to Wordpress to serve a specific header for the page/url you do not want APO to cache
    Code (Text):

    header( 'cf-edge-cache: no-cache' )

16. As at Oct 22, 2020 Google AMP pages are not properly supported. The ?amp query string is currently incorrectly cached. So you end up serving the same content on both ?amp and non-AMP cached pages.
17. November 6, 2020, Cloudflare APO now has integration support with Cloudflare Page Rules.

Automatic Platform Optimization (APO) Webpagetests

To test Cloudflare Wordpress plugin's Automatic Platform Optimization, I am going to run 3x run Webpagetest.org 5Mbps cable speed Chrome page speed tests in three locations, Dulles, London and Sydney against my Wordpress blog at https://servermanager.guide/. The Webpagetest reported metrics are for the median result of the 3x runs.

My Wordpress blog was installed and setup as outlined at https://servermanager.guide/122/how-to-install-wordpress-on-centmin-mod-lemp-stack-guide/ using my Centmin Mod LEMP stack's Wordpress installer (centmin.sh menu option 22) with fastcgi_cache full HTML cache backend and then combined with Cloudflare Worker custom caching at the per route URL level for full HTML guest caching. My Wordpress blog has been heavily optimized for page speed given I am a self confessed page speed addict so the below comparison page speed results are comparing my heavily optimized Wordpress blog with Cloudflare Wordpress plugin's one click Automatic Platform Optimization button. You'll find that Cloudflare Wordpress plugin's one click Automatic Platform Optimization button does wonders for page speed for the average Wordpress user not well versed in page speed optimizations

Cloudflare Wordpress Automatic Platform Optimization basically utilises Cloudflare Workers Building Automatic Platform Optimization for WordPress using Cloudflare Workers so essentially below test is testing Cloudflare's Worker config versus my custom Cloudflare Worker caching config

My Wordpress blog using custom Cloudflare Worker caching's cache hit rate for 30 days

Webpagetest Summary Table

Summary table with specific detailed results further below. Webpagetest summary First Byte includes other metrics like DNS and SSL negotiationetc so isn't solely TTFB metric. For actual HTML document request's TTFB look into the details summary.



Example details summary for TTFB for HTML document request for Dulles before APO where

• DNS lookup: 27ms
• Initial Connection: 30ms
• SSL Negotiation: 49ms
• Time To First Byte: 62ms
• Content Download: 60ms

Before Cloudflare Wordpress plugin's Automatic Platform Optimization

Before Wordpress plugin's Automatic Platform Optimization Webpagetest median result with the HTML page's response headers displayed for Dulles, London and Sydney location tests.

After Cloudflare Wordpress plugin's Automatic Platform Optimization

After Wordpress plugin's Automatic Platform Optimization Webpagetest median result with the HTML page's response headers displayed for Dulles, London and Sydney location tests.

Before vs After Wordpress Automatic Platform Optimization

Now to compare the before and after Wordpress Automatic Platform Optimization Webpagetest results for various metrics

Video end load time for before versus after APO



The most interesting difference I noticed is with Wordpress Automatic Platform Optimization enabled is the size of HTML bytes being so much smaller when APO is enabled. Though the overall actual difference isn't that much different as the scale of the bar chart is with 100 byte increments.



Webpagetest Speedindex metric which measures perceived visual render times



TTFB



DOM Content Loaded Time



Google Core Web Vital metric for Largest Contentful Paint

---

Google Core Web Vital metric for Cumulative Layout Shift (CLS)

 

Google PageSpeed Insights Tests

Next is to compare Google PageSpeed Insights for before and after Cloudflare Wordpress plugin's Automatic Platform Optimizations. They're fairly close as my Wordpress blog is very heavily optimised already

The difference I can see is in the number of large layout shifts reported. Before APO both desktop and mobile results reported 3 large layout shifts while after APO reported 2 large layout shifts - so 1 less. And mobile total blocking time is less after APO at 30ms versus before APO at 60ms.

Before Cloudflare Automatic Platform Optimizations

After Cloudflare Automatic Platform Optimizations

 

FastOrSlow Tests

Next is to compare FastOrSlow profile times.

Before Cloudflare Automatic Platform Optimizations

After Cloudflare Automatic Platform Optimizations

 

KeyCDN Performance TTFB Test

Next is KeyCDN Performance TTFB tests across a number of geographical regions

Before APO

You can see the cf-cache-status = HIT due to my custom Cloudflare Worker full HTML caching I deployed along with custom response headers. The cf-edge-cache header is from Cloudflare Wordpress plugin though.

Code (Text):

cf-cache-status HIT
cf-cachetime 86400
cf-default-rule 1
cf-edge-cache cache,platform=wordpress
cf-req-country DE
cf-tls TLSv1.3

After APO

For some reason, I am not able to get a cache hit status with KeyCDN Performance tests with Automatic Platform Optimization enabled? Even after 20+ test runs the cf-cache-status is still reporting DYNAMIC = cache bypassed to hit origin!

Edit: @Brad393 chimed in to say that KeyCDN Performance test tests using a GET request with text/html mime type Accept rquest instead of a GET request with text/html mime type and that Cloudflare Wordpress APO CF Worker is coded to cache only on GET requests for text/html type requests. I confirmed this is the case via tests here and here. So don't use KeyCDN Performance test to check if Cloudflare Wordpress plugin's APO is working or not.

You can see the following response headers

Code (Text):

cf-cache-status DYNAMIC
cf-edge-cache cache,platform=wordpress
x-via speedwp/origin,bypass

 

GTMetrix Page Speed Tests

Next is GTMetrix Chrome 5Mbps tests from Dallas for Wordpress Automatic Platform Optimization before and after comparison. Here GTMetrix didn't have a problem with APO cf-cache-status HITs unlike with KeyCDN Performance test previously done.

Before APO

With HTML TTFB at 252ms

After APO

With HTML TTFB at 295ms



Side by side compare with before on left and after on right


Before on left and filmstrip on top and after on right and filmstrip on bottom

 

Strange, I'd make sure the plugin is working properly as there have been reports of teething issues

• Automatic Platform Optimization - Cannot detect WP or plugin
• Automatic Platform Optimization Enabled & I No Longer See Visitor IP?
• APO breaks Google fonts

 

@negative my quote above

Cloudflare's Wordpress plugin Automatic Platform Optimization will in theory beat all other Wordpress caching solutions other than you rolling out your own Cloudflare Worker based caching like I did in above tests. So you get a good bang for your buck at US$5/month for Cloudflare's Wordpress plugin Automatic Platform Optimization.

 

FYI, seems Cloudflare Wordpress Automatic Platform Optimization only has a limited set of Wordpress cookies that are supported to bypass Cloudflare CDN cache.

From APO Wordpress Incorrect Cart Items

So until that is sorted some Wordpress usage cases won't be supported with Cloudflare Wordpress Automatic Platform Optimization plugin. My own CF Worker cache implementation I added heaps of web app cookies to properly bypass CF CDN cache for various web apps i.e. Xenforo, vBulletin and Wordpress/Woocommerce etc.

 

Another limitation is that Cloudflare Wordpress Automated Platform Optimization will only work properly with Wordpress sites on apex domain i.e. domain.com and not on subdomain sites i.e. blog.domain.com Automatic Platform Optimization - Cannot detect WP or plugin ! That's is a big limitation !

and Automatic Platform Optimization - Cannot detect WP or plugin

Unfortunately being able to run subdomain on a separate Cloudflare account zone is a Cloudflare Enterprise plan feature.

 

Added part 2 write up for Cloudflare Wordpress plugin Automatic Platform Optimization to evaluate the effectiveness of caching configuration on repeat visits and visits with common query strings like ?fbclid WebPerf - Cloudflare - Cloudflare Automatic Platform Optimization for Wordpress Cache Effectiveness

 

Ah interesting observation will have to check that out!

Nah it's private so haven't shared it publicly.

my nginx 302 redirect doesn't redirect to main page it strips query string from url

So it URL is /page1?fbclid it will redirect to /page1 or if it's /post/title1/?fbclid it redirects to /post/title1/ to be cached

However my own CF worker cache just caches the query string as its own cache entry. So both post/title1/?fbclid and /post/title1/ are 2 separate cached entries

 

Then next best solution is to use Cloudflare + Centmin Mod Cache Enabler with query string caching on origin server side so that query string cache miss requests hit backend origin that caches them https://servermanager.guide/203/wordpress-cache-enabler-advanced-full-page-caching-guide/. This still reduces the load on PHP-FPM processes as Cache Enabler offload the request to be served from nginx level cache

 

Tested your theory with curl HEAD requests

for my CF Worker without APO

1st request of cache miss

Code (Text):

curl -I https://servermanager.guide/
HTTP/2 200
date: Tue, 06 Oct 2020 12:39:12 GMT
content-type: text/html; charset=UTF-8
set-cookie: __cfduid=d1275e8e291443dcd4e1aa169b74b69721601987952; expires=Thu, 05-Nov-20 12:39:12 GMT; path=/; domain=.servermanager.guide; HttpOnly; SameSite=Lax; Secure
cf-ray: 5ddf719c2e79ecf2-YUL
cache-control: public, max-age=86400, stale-while-revalidate=60
expires: Wed, 07 Oct 2020 12:39:12 GMT
link: <https://servermanager.guide/wp-json/>; rel="https://api.w.org/"
strict-transport-security: max-age=31536000; includeSubdomains;
vary: Accept-Encoding
cf-cache-status: MISS
cf-cachetime: 86400
cf-default-rule: 1
cf-req-country: CA
cf-request-id: 059f85559c0000ecf2228b3200000001
cf-tls: TLSv1.3
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
permissions-policy: accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()
referrer-policy: strict-origin-when-cross-origin
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-powered-by: centminmod
x-xss-protection: 1; mode=block
server: cloudflare
alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400

2nd request cache hit

Code (Text):

curl -I https://servermanager.guide/
HTTP/2 200
date: Tue, 06 Oct 2020 12:39:15 GMT
content-type: text/html; charset=UTF-8
set-cookie: __cfduid=d713e273e7d847ea611e9af19cff83e171601987955; expires=Thu, 05-Nov-20 12:39:15 GMT; path=/; domain=.servermanager.guide; HttpOnly; SameSite=Lax; Secure
cf-ray: 5ddf71af5b1dca67-YUL
age: 3
cache-control: public, max-age=86400, stale-while-revalidate=60
expires: Wed, 07 Oct 2020 12:39:15 GMT
link: <https://servermanager.guide/wp-json/>; rel="https://api.w.org/"
strict-transport-security: max-age=31536000; includeSubdomains;
vary: Accept-Encoding
cf-cache-status: HIT
cf-cachetime: 86400
cf-default-rule: 1
cf-req-country: CA
cf-request-id: 059f85619a0000ca671a97a200000001
cf-tls: TLSv1.3
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
permissions-policy: accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()
referrer-policy: strict-origin-when-cross-origin
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-powered-by: centminmod
x-xss-protection: 1; mode=block
server: cloudflare
alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400

now test Cloudflare Wordpress APO curl HEAD request does indeed show cache bypass to origin via cf-cache-status = DYNAMIC and with x-via: speedwp/origin,bypass

Code (Text):

curl -I https://servermanager.guide/
HTTP/2 200
date: Tue, 06 Oct 2020 12:40:10 GMT
content-type: text/html; charset=UTF-8
set-cookie: __cfduid=db914218c7549190b8c409b3ae4b5ee5e1601988010; expires=Thu, 05-Nov-20 12:40:10 GMT; path=/; domain=.servermanager.guide; HttpOnly; SameSite=Lax; Secure
cf-ray: 5ddf7309cab5ecfe-YUL
link: <https://servermanager.guide/wp-json/>; rel="https://api.w.org/"
strict-transport-security: max-age=31536000; includeSubdomains;
vary: Accept-Encoding
cf-cache-status: DYNAMIC
cf-edge-cache: cache,platform=wordpress
cf-request-id: 059f863a180000ecfe45a23200000001
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
permissions-policy: accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()
referrer-policy: strict-origin-when-cross-origin
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-powered-by: centminmod
x-via: speedwp/origin,bypass
x-xss-protection: 1; mode=block
server: cloudflare
alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400

Then tested Cloudflare Wordpress APO with curl GET request and still doesn't cache as it seems Cloudflare APO Worker only will cache it Accept: text/html is in the request

Code (Text):

curl -skD - -H "Accept-Encoding:gzip" https://servermanager.guide -o /dev/null
HTTP/2 200
date: Tue, 06 Oct 2020 12:44:48 GMT
content-type: text/html; charset=UTF-8
set-cookie: __cfduid=d0de6f414481c878228bb59385dec06c51601988288; expires=Thu, 05-Nov-20 12:44:48 GMT; path=/; domain=.servermanager.guide; HttpOnly; SameSite=Lax; Secure
cf-ray: 5ddf79d06dd3ca47-YUL
content-encoding: gzip
link: <https://servermanager.guide/wp-json/>; rel="https://api.w.org/"
strict-transport-security: max-age=31536000; includeSubdomains;
vary: Accept-Encoding
cf-cache-status: DYNAMIC
cf-edge-cache: cache,platform=wordpress
cf-request-id: 059f8a763c0000ca47f2b46200000001
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
permissions-policy: accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()
referrer-policy: strict-origin-when-cross-origin
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-powered-by: centminmod
x-via: speedwp/origin,bypass
x-xss-protection: 1; mode=block
server: cloudflare
alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400

Then test curl GET request with Accept: text/html request in headers and yes Worker APO CF Worker caching works with cf-cache-status: HIT

Code (Text):

curl -skD - -H "Accept-Encoding:gzip" -H "Accept: text/html" https://servermanager.guide -o /dev/null
HTTP/2 200
date: Tue, 06 Oct 2020 12:46:11 GMT
content-type: text/html; charset=UTF-8
set-cookie: __cfduid=d35e01a47ee4c044c0107fca7c58eed351601988371; expires=Thu, 05-Nov-20 12:46:11 GMT; path=/; domain=.servermanager.guide; HttpOnly; SameSite=Lax; Secure
cf-ray: 5ddf7bdadbfdecf6-YUL
age: 364
link: <https://servermanager.guide/wp-json/>; rel="https://api.w.org/"
strict-transport-security: max-age=31536000; includeSubdomains;
vary: Accept-Encoding
cf-cache-status: HIT
cf-edge-cache: cache,platform=wordpress
cf-request-id: 059f8bbcc60000ecf645188200000001
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
permissions-policy: accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()
referrer-policy: strict-origin-when-cross-origin
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-powered-by: centminmod
x-xss-protection: 1; mode=block
server: cloudflare
content-encoding: gzip
alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400

Or KeyCDN performance tool does use GET request just not passing text/html ACCEPT request as well ?

 

Did a quick h2load HTTP/2 HTTPS benchmark for both configs and it's pretty close!

Without APO - my own CF Worker cache + fastcgi_cache cache backend PHP-FPM

Code (Text):

h2load -t4 -c250 -n5000 -m60 -H "Accept-Encoding:gzip" -H "Accept: text/html" https://servermanager.guide
starting benchmark...
spawning thread #0: 63 total client(s). 1250 total requests
spawning thread #1: 63 total client(s). 1250 total requests
spawning thread #2: 62 total client(s). 1250 total requests
spawning thread #3: 62 total client(s). 1250 total requests
TLS Protocol: TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Server Temp Key: X25519 253 bits
Application protocol: h2
progress: 10% done
progress: 20% done
progress: 30% done
progress: 40% done
progress: 50% done
progress: 60% done
progress: 70% done
progress: 80% done
progress: 90% done
progress: 100% done
finished in 3.17s, 1577.40 req/s, 55.27MB/s
requests: 5000 total, 5000 started, 5000 done, 5000 succeeded, 0 failed, 0 errored, 0 timeout
status codes: 5000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 175.20MB (183713496) total, 704.16KB (721060) headers (space savings 87.29%), 174.18MB (182639302) data
                     min         max         mean         sd        +/- sd
time for request:    28.31ms       1.92s    499.41ms    355.46ms    78.60%
time for connect:    19.39ms       3.03s    896.36ms    778.99ms    47.60%
time to 1st byte:    41.64ms       3.06s    982.32ms    776.32ms    50.40%
req/s           :       6.08       74.97       21.65       17.75    82.00%

Cloudflare Wordpress Automatic Platform Optimization enabled

Code (Text):

h2load -t4 -c250 -n5000 -m60 -H "Accept-Encoding:gzip" -H "Accept: text/html" https://servermanager.guide
starting benchmark...
spawning thread #0: 63 total client(s). 1250 total requests
spawning thread #1: 63 total client(s). 1250 total requests
spawning thread #2: 62 total client(s). 1250 total requests
spawning thread #3: 62 total client(s). 1250 total requests
TLS Protocol: TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Server Temp Key: X25519 253 bits
Application protocol: h2
progress: 10% done
progress: 20% done
progress: 30% done
progress: 40% done
progress: 50% done
progress: 60% done
progress: 70% done
progress: 80% done
progress: 90% done
progress: 100% done
finished in 3.44s, 1453.08 req/s, 50.15MB/s
requests: 5000 total, 5000 started, 5000 done, 5000 succeeded, 0 failed, 0 errored, 0 timeout
status codes: 5000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 172.55MB (180934533) total, 639.97KB (655332) headers (space savings 87.52%), 171.21MB (179521661) data
                     min         max         mean         sd        +/- sd
time for request:    32.36ms       1.81s    459.89ms    325.14ms    77.78%
time for connect:    19.58ms       3.03s       1.06s    943.35ms    42.40%
time to 1st byte:    40.97ms       3.10s       1.12s    935.44ms    44.80%
req/s           :       5.60       88.89       21.79       19.04    82.00%