I’ve been using cache everything along with Argo for a long time. The fact is it usually worked well until on the 24th of January. From that day onwards TTFBs dramatically increase whenever an html page is not stored in cache.
Does it mean I won’t be able to use cache everything + Argo anymore?
webpagetest.org for pagespeed testing - my guide at WebPerf - PageSpeed - How to use webpagetest.org for page load speed testing shows you how to use WPT and also enable Google Lighthouse v6 optional tests too. WPT documentation. Note that the 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 use Argo API analytics to dig into your per geographic region (CF datacenter) Argo requests to see where your Argo routing is going. If that traffic makeup changes i.e. more visitors from further away location, then it stands to reason your average Argo improvements to server response time/TTFB will increase (be slower).
example from my Argo analytics broken down by CF datacenter
Left side Cloudflare Argo stats from dashboard console vs right side my own Argo Analytics API query script to get Argo metrics on a per datacenter basis. As expected, the biggest benefit for Argo will be for visitors further away from your origin server’s geographic location. For me my origin is in US West Coast, so datacenters like SEA (Seattle) and LAX (Los Angles) will have lower % percentage improvement for server response time ~ 41.27% and 41.11% respectively. While datacenters further away like DME (Moscow) and DUB (Dubia) have much higher % percentage improvements for server response time ~ 67.07% and 75.75% respectively.
If you are tracking TTFB as per Google Analytics Avg Server Response time, then remember this is real world visitors so that is subject to relative geographic distance between your visitors and CF edge server (when you have cache everything enabled).
Note there are specific request patterns which may bypass ‘cache everything’ CDN caching rules by default so that the request has to reach all the way back to your origin request usually. i.e. query string based requests i.e. tracking query strings are one example which may bypass ‘cache everything’. Argo’s Tiered cache may help to shorten the path for ‘cache misses’ but still it wouldn’t be as fast as a cache hit.
Where is your origin server hosted geographically ?
got screenshots for those tests ? have you dug into the response header requests to see which CF datacenter rayid (cf-ray header) is served from and whether the request was a cf-cache-status hit or dynamic/miss ?
This is what I usually see for my Wordpress blog with Argo enabled and CF cache everything via CF Worker custom caching.
That would only be true if you CF CDN cache is populated and it’s normal for 1st requests for cache miss to have slow TTFB
is normal as first run may not have HTML in CF datacenter’s CDN Cache
not normal unless CF CDN cache is populated - expect non-CF CDN cache populated request to have a slow first time test and only 2nd populated CF CDN cache will be fast or about the same
normal as first run may not have HTML in CF datacenter’s CDN Cache
So what you are seeing for for Argo enabled + cache everything disable is not what I’d expect to be normal for fast 1st time request. I’d expect first request to be slower than subsequent requests or about the same if you do not have any origin side server caching in play.
But slow and fast are relative to the actual TTFB numbers and from your screenshots some regions are about the same like Amsterdam and London and improved on Bangalore so Argo + cache everything is working for those regions. If you hit the down arrow key, you will see response headers and check for cf-cache-status, cf-ray and age headers - the last age header will report how long the request has been in CF CDN cache for. Check the slow TTFB regions response headers to compare. It could be first request isn’t populated yet as CF CDN cache is on a per datacenter region basis. So it could just be that region for first request doesn’t have cached HTML page in that CF datacenters’ caches.