High TTFB waiting time - server side

I have been going on opening support tickets regarding the delay I’m experiencing with my site to display.

The last two improvements I did was enabling the site on Cloudflare and caching the static site with the Litespeed module. Even if they helped allot, specially after a second test when the cache is warm I still experience high waiting time on the first request from the server, when I haven’t tested or visited my site in some hours, but as well less than that.

The only thing I have been hearing from the support is that the everything is fine, and then they show me a metrics test where the site loads within 5 seconds and point out nothing is wrong. Usually they pick that result after a retest as I said when the cache is warm, even though I point out and even show them proof where the waiting time is 20 seconds.

Waiting time gets high because the server in these situations just allocates 1.5kb/sec to load a 15kb https html file request. And first byte goes up to 10 seconds before it start to render the sites resources, which it does a good and fast job on.

I don’t know what to do anymore, as I’m tired of this, but I don’t know if moving to a new hosting provider will do anything. I’m an a shared cloud plan with TMDhosting, Business Plan, which indeed has good hardware.

This is what I just wrote them in my last support ticket:

Hi,

According the admin at Litespeed they have pointed out that instead of no-cache I should either get a HIT or MISS, and not a no-cache. Is anything incorrect with the Litespeed setup, and does it indeed cache correctly?

no-cache: Screenshot by Lightshot

If you look at the initial HTML request the server is hardly giving any bandwitdh so the TTFB gets much higher than it should be. Even with Litespeed/Cloudflare enabled I can still get waiting times up to 20 seconds. Specially if I do a first time test when I get up in the morning as no one has hit the site. Once I do one test it will warm up the cache and I will get better waiting time values; under 5 seconds. Yet it doesn’t answer my question why sometimes server allocates 1.5kb bandwith for the first request that is 15kb in size. No wonder it will take 10+ seconds to initiate it.

HTML request: Screenshot by Lightshot

As you can see, my site resources are optimized and loading good, the culprit is the waiting time, why is there such a high waiting time from the server side? It doesn’t make sense to me and as I pointed out this sometimes makes the site take a need to wait 10-20 seconds before it starts to render on the screen.

Idle: Screenshot by Lightshot

Something appears badly broken in your hosting.

Take a look at time to serve asset #11 (I just picked one at random), which is insanely long.

Compare your serving speed to one of my random servers… serving your same image (I just scraped your image + dropped it into a directory).

Speed difference of hosting…

Yours: 1395ms (crazy slow)

Mine: 14ms (DNS subtracted… .36-.22 == .14ms)

This points to some sort of very serious hosting problem.

Likely some sort of problem related to running some sort of bandwidth shaping/limiting.

Turn anything like this off, as bandwidth manipulation rarely works as you expect…

And almost always destroys site throughput.

If there’s no bandwidth manipulation running, then likely your best bet is to change hosting.

If you’re running a high traffic money site, run on a dedicated server.

Hey Nico -

Please use caution with dfavor’s advice. His test was showing a single image only, so it can’t be compared with a full test which is loading many resources at the same time.

In looking at your waterfall, first thing would be to make sure you’re testing the https version of your site, as you can see the first response is a 301 redirect from http to https.

Secondly, I do agree that your TTFB on the main doc is slow. Cloudflare caches only resources by default, not pages. Have you set up the ‘page rules’ feature of theirs? If so, you should see sub 100 ms TTFB times - which comes at a cost of your site being slightly stale.