I also experience high TTFB since 2 days now. Never had this issue before. I experience it on 2 different servers with 2 different cloudflare accounts/ domains. So I was guessing it might have something to do with cloudflare. Or with OVH (where I host my sites via a VPS)
I am having the same issue and it’s not just on one server and one domain. It doesn’t feel fast as it used to be.
You do host your sites with a VPN?
Nevermind. Lets just test this and figure out where the real problem comes from and where it does not come from.
Please do set a static HTML file on your server and map a domain on your server which do NOT have anything to do with CloudFlare.
Now request the HTML file. As it is a HTML file it is static and the server will not have to process anything, so we are not measuring the server power.
Also as it is HTML CloudFlare will define it as dynamic and will not cache it, so it do get proxied all the time.
Now request that file (while using CloudFlare with proxy function) and make sure this file will not get delivered through the VPN buth through CloudFlare.
Post the result (TTFB) as screenshot and also post the full response header.
Then we can debug and inspect this.
For Webhosting this mostly do not make any sense but you are free to set your things up as you wish. But this makes your speed depend on so much more then just CloudFlare and your servers at OVH, but also on a thirth party service (VPN Service) which often do limit bandwith, ping and also are makeing your request have to travel way more then needed
I meant VPS
Ah. Now this makes a big difference
Ok but anyway, create a static HTML file and post the link to it on a domain which gets proxied so we can do tests and debug it
And please also post the Domains this “high TTFB” occurs.
If you ping 18.104.22.168 from your VPS what is the latency like?
Sounds like theres a network issue somewhere, you’re not the only one with this problem today it seems
Your best bet is making a support ticket, include every bit of diagnostic information, timestamps, traceroutes, etc
Post the ticket # in this thread too
Yes that was because I was going back and fourth between my registrar and cloudflare. it should be fixed now. But I still don’t understand why it takes 1 second to load a single image while it takes less than 150ms to load the entire page + images without cloudflare.
TLS handshake drama, or cloudflare has an overloaded peering link with OVH. There can always be subtle behind the scenes drama, that a hosting provider wants you to get a more expensive plan from them, vs added a CDN/reverse proxy. If you wireshark your traffic to cloudflare, does CF wait 100s of ms, then max speed dumps the image file to you? or are the packets equally spaced?
Weird things happen in Varnish/haproxy/nginix/apache with Gzip vs chunked encoding/MIME/download multipart (is this legal outside of emails?) vs Nagle’s algorithm vs keep-alive.
Since 2 April there is a latency increase (+100ms) between Cloudflare and OVH datacenters in europe except Poland. Please check carefully the 3rd graph on the OVH smokeping page: http://lil2-gra.smokeping.ovh.net/smokeping?target=ANYCAST.AS13335-3 . You’ll see clearly the problem. This should be fixed asap as it must be affecting all customers using CloudFlare and OVH together.
which OVH datacenters ? could be the impact of OVH datacenter fires and them rebuilding the network in Europe?
Probably it has nothing to do with the fire. It is impacting all european OVH datacenters in Europe and GB except Poland (WAW) (you can check the different datacenters in the smokeping page to see the impact).
We have been informed OVH found the issue and are investigating it, it is related with network routing. Maybe of some third party peering, but this issue seems not to be on Cloudflare side. Hopefully they’ll fix it soon.
The EU West latency problem seems fixed since 2:40 UTC.
I’m havng the same problems with godaddy/cloudflare. My server is on godaddy network (which should be one of the fastest hosting services). I did work on my programming but I still have long time of waiting before first byte…
This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.