The famous hop #6 
My guess, there was some issue with the routing at the German IXP, which only applied to German connections.
Yeah now TTFB again is at about 120ms-300ms
This is very very strange. But again I dont think this is related to “germany” as @sdayman tested against all this Cloudflare using Servers and also did get a very high TTFB.
Well, the tests above did show it was not an international issue, furthermore international routes via FRA did not appear to run into that issue either.
1 Like
Littel update:
from 16:00-20:00 TTFB goes up to about 700ms again
at about 10:00 its normal at 20ms-30ms
But: if I not use CloudFlare everything is at about 20ms-30ms again.
Just right now I do get a TTFB of 22ms. (on a page with
cf-cache-status: DYNAMIC!)
So I dont believe anymore that this is caused by my ISP as it would be the case all the time, not just from (exactly) 12:00-24:00 as it seems to be just working fine from 00:00-12:00.
I hope someone from CloudFlare (maybe @cloonan) maybe could investigate this or just forward it. At night it is just perfectly fast and as soon as the clock passes 12:00 I get responstimes (TTFB) from about 2 seconds and it takes to download some few kb big files about 300-500ms…
And on top: all sites not using CloudFlare are manwhile working perfectly fine.
@M4rt1n have you tried enabling CF origin health checks for to your origin one for static and one for dynamic content (php) and see order time whether or not latency times for connections from CF edge to your origin vary too ? That could rule out one segment of the slowest from CF edge to origins side.
Curious if at night time, you experience the same with my Wordpress blog which is on CF free plan at https://servermanager.guide/
Any clues in CF browser insight metrics on your CF Dashboard speed tab ? You can drill down by country level browser insights too
You are talking about “Authenticated Origin Pulls”?
They had been turned on. But now turned off for further testing.
ATM TTFB is pending between 30ms and 300ms… again very very strange.
TTFB between 60-90ms but much more stable.
I have not enabled CF Browser Insight as it load additional JS files.
#EDIT: ok not more stable now between 60-180ms
CF healthchecks at https://blog.cloudflare.com/new-tools-to-monitor-your-server-and-avoid-downtime/
and each entry reports round trip time for latency
Sorry I have not implemented this. I never saw this… quite shocking atm.
Could you recommend and settings for checking?
Just did another Check of my TTFB … so sad
How does your site look via webpagetest.org tests from geographic locations you are focused on ? I wrote a guide on using WPT at https://community.centminmod.com/threads/how-to-use-webpagetest-org-for-page-load-speed-testing.13859/
On WebPageTest it looks good! But depeds on which provider you chose. Then it varys in total about 200-300ms in loadtime.
Best Speedtest out of 3 with best provider:
Sometimes TTFB is just perfect and then some minutes later its at 150ms or even at some seconds
Yes as the speed can vary due the provider/tester’s server and network too.
Its most probably not related to the Server as I also tested a site which had “Cache Everything” which at the same time when the TTFB of the other site was high also had a high TTFB. And this page was delivered 100% from CloudFlare Edge Cache.
Then probably need to submit a CF support ticket to investigate. Tried using a VPN provider with location closest to your ISP and see how speed of site behind a VPN is ?
Yeah tried it, but seems to be the same. Same random spikes. TTFB dont even varies a lot between with and without VPN
Thanks I will open a support ticket
Wanted to add another thing I noticed today:
- my site again is very very slow (well nothing new anymore)
- dynamic content is not getting delivered faster then cached content…
Waterfall from site:
HTML is dynamic but favicon.ico is 100% static cached, by CloudFlare, so how can dynamic content be faster (when it have to hit my origin Server) then static content?
HTML Header:
FavIcon.ico Header:
Both delivered from same cf-ray.
FYI: just created a ticket 1891114
That is browser’s preloader at play. Depending on web browser i.e. Chrome, it will usually prioritize loading on assets which actually render the current page i.e. css, js, fonts. As favicon isn’t part of the pages rendering, it’s lazy loaded/deferred in priority and usually last and not important in what Google prioritizes in terms of page speed - metrics like first contentful paint, largest contentful paint for perceived visual render time.
I know this. But the waterfall does not consider this at all!
It just shows which file does get loaded when and even if a file gets loaded with “low priority” it gets loaded with fullspeed.
The priority does just affect the loading-order not the TTFB is any way so this is compeltely (to my understanding) not related to my problem.
Non of the things you emntioned are affecting the TTFB, or are they?
Also, this is the same page (posted here before) and chromes behavior did niot change:
Chrome version was the same, so how is this related to chrome?
Thats why I disagree on this:
Indeed, i was referring to when favicon got loaded not your TTFB.
Tried in Firefox and MS Edge browsers too ?
Has Cloudflare ticket support replied to your issues to see if it’s specific to your region/cf datacenters ?
How’s it look in comparison from your location for my wordpress blog on CF free plan at https://servermanager.guide/ ?
