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?
I wouldn’t expect a difference here, but haven’t tested yet. Can you reproduce if you deactivate Argo?
Argo disabled and cache everything enabled:
Slow first paint.
Very fast second paint.
Argo enabled and cache everything disable:
Fast first paint.
Fast second paint.
Enabled both Argo and cache everything:
Slow first paint.
Very fast second paint.
In short, when you enable both Argo and cache everything, they perform as in the disabled Argo option, yet you pay the additional cost.
Lets first define how you’re measuring TTFB? What tools and methods are you measuring TTFB from? TTFB is relative to the geographical distance between test server and test target.
If you’re using webpagetest.org - note that the summary table First Byte is not the same as TTFB for the actual request. Nice read at WebPerf - PageSpeed - Google Page Speed Insights and Google Core Web Vital metrics | Centmin Mod Community Support Forums
- 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.
Cloudflare Argo smart routing only improves one specific aspect of page speed and that is the server response time which is roughly TTFB. You can look at Google Analytic’s old non-v4 pagespeed reported Avg Server Response Time to track the change as I did with my CF Argo measurements I outlined at WebPerf - Cloudflare - PageSpeed - Cloudflare Argo Smart Routing In Action | Centmin Mod Community Support Forums.
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.
I am measuring the TTFB with tools.keycdn.com/performance.
Argo works fine. Cache everything works fine. But both together activated Argo stops working.
Argo disabled and cache everything enabled:
Slow first paint and slow TTFB.
Very fast second paint and very fast TTFB.
Argo enabled and cache everything disable:
Fast first paint and fast TTFB.
Fast second paint and fast TTFB.
Enabled both Argo and cache everything:
SLOW first paint and SLOW TTFB.
Very fast second paint and very fast TTFB.
In short, when you enable both Argo and cache everything, they perform as in the disabled Argo option, yet you pay the additional cost.
With the Keycdn test you linked to, here’s my Argo-enabled cache-everything “About” page on a Pro Plan. First, then Third access:
Now, do the test only with argo activated.
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.
Also try testing with other page speed tools I mentioned at WebPerf - PageSpeed - Google Page Speed Insights and Google Core Web Vital metrics | Centmin Mod Community Support Forums as KeyCDN test servers could also vary/change between tests too - I doubt they only have a single test server for each region. Best tool will be webpagetest.org
what does your Argo Origin performance numbers look like i.e. how many percentage of your requests are smart routed ?
Example
only with argo activated.
First:
Argo with cache everything:
First:
Previously, Argo and Cache everything ran fast in the first paint. Now, it doesn’t work.
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.
When I activate Argo and Cache everything, the percentages drop to 5%
In that case best to submit a CF support ticket to ask them to investigate. Though Argo stats only start rolling in for me ~36-48hrs after Argo is initially enabled.
