WebPerf Cloudflare Cloudflare Automatic Platform Optimization for Wordpress Cache Effectiveness

Previous page speed comparison tests showed Cloudflare Automatic Platform Optimization for Wordpress's cache effectiveness when the Cloudflare CDN cache was already primed for the first visit in Webpagetest, GTMetrix, Google PageSpeed Insights and FastOrSlow. This time doing Webpagetests testing for cache effectiveness from first uncached visit and then repeat visits of the index page (2x) with cache populated and then 3x visits of index with common Facebook tracker query string ?fbclid. This will test both Cloudflare CDN and browser level caching effectiveness.

The order of Webpagetests done

Code (Text):

https://servermanager.guide/
https://servermanager.guide/
https://servermanager.guide/
https://servermanager.guide/?fbclid
https://servermanager.guide/?fbclid
https://servermanager.guide/?fbclid

---

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

With Versus Without Wordpress Automatic Platform Optimization

Summary table below. Note Webpagetest First Byte summary table isn't the same as a HTML documents actual request TTFB. The First Byte summary is a the total for Discovered + DNS + Connect + SSL + TTFB times. The First Byte is the time taken from navigationStart to the browser receiving the very first byte of data from the server. See Matt Hobb's explanation here.

You can see on repeat visits without APO the First Byte time is higher than with APO due to the first request without APO being the Google Analytics tracker javascript as browser caching on repeat visits would have removed the Wordpress blog index page request as it was served out of browser cache. While with APO, the repeat visits had lower First Byte due to always serving the Wordpress index page as there is no browser level caching. However, as you can see actual TTFB and other metrics like Start Render, FCP, Speedindex, LCP and total Document completion time are much better if browser level caching was implemented (in without APO).

• Below results will show the first index visit as uncached and repeat visits without APO shows that my own implementation also configures browser level caching so repeat visits are served from browser level cache so an index page request isn't shown. While Wordpress Automatic Platform Optimization does seem to implement browser level caching so repeat visits still serve an index page (from cache) over the network.
• Wordpress Automatic Platform Optimization also doesn't cache common query strings like Facebook tracker query string ?fbclid so all 3 visits. So query string request bypasses the Cloudflare CDN cache. However, my Wordpress's Nginx setup for PHP-FPM fastcgi_cache already takes care of query strings. It does a 302 redirect to the no query string version of index page which is CDN level cached.
  Code (Text):

  # strip gclid/fbclid query strings from urls via a
  # 302 redirect to url without the query strings
  if ($wpfcgi_ignorearg) {
    rewrite ^ $uri? redirect;
  }
  

  However, there is no browser level caching on the 302 target index url so the request shows up on repeat visits. My own implementation without APO, caches query string and also utilises browser level caching as the index page with query string request isn't shown.

without APO



With APO

Without Cloudflare Wordpress Automatic Platform Optimization

With Cloudflare Wordpress Automatic Platform Optimization

I hope that Cloudflare's Wordpress Automatic Platform Optimization adds browser level caching support as well for better repeat visitor page speed. Currently, APO still has a few limitations outlined in my previous write up that also need addressing as well.

 

With Cloudflare Wordpress Automatic Platform Optimization & Without Query String 302 Redirect

Previous post showed that my Wordpress's Nginx setup for PHP-FPM fastcgi_cache already takes care of query strings. It does a 302 redirect to the no query string version of index page which is CDN level cached.

Code (Text):

# strip gclid/fbclid query strings from urls via a
# 302 redirect to url without the query strings
if ($wpfcgi_ignorearg) {
  rewrite ^ $uri? redirect;
}

So next is to test Cloudflare Wordpress Automatic Platform Optimization without Query String 302 Redirect at PHP-FPM/Nginx backend level.

Results are below:

• Without 302 redirect, Wordpress APO query string requests for ?fbclid bypass cache and have cf-cache-status = DYNAMIC and you can see there is no improvements in repeat visits for TTFB. However, First Byte, FCP, LCP, CLS and Document complete were better. Page speed was better but under heavy concurrent traffic load, the query string based requests will all result in a cache miss and hit your origin backend server driving up your origin server's load.
• With the 302 redirect at Nginx level, query string requests will serve the 302 redirect at Nginx level so bypasses PHP-FPM so stress and load on PHP-FPM is avoided as Nginx can serve a 302 redirect using less server cpu/memory resources than PHP (PHP-FPM) can under heavy concurrent traffic user loads.

 

Cloudflare Wordpress Automatic Platform Optimization currently doesn't support common tracker related query strings and bypass Cloudflare CDN cache. However, 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$/