Slow TTFB test

I added my test site to CF with the free plan.
When I test the time to first byte (TTFB) I get TTFB>100ms:


When I test TTFB with this CF website: https://www.computerhope.com/ I get TTFB=30-40ms.
I enabled:
  1. Auto Minify
  2. Brotli
    HTTP2 is also enabled by default.

How can I reduce the TTFB with CF?

Computerhope caches their home page HTML. But they don’t/can’t cache their forum and get the same TTFB as your site.

Cloudflare doesn’t cache HTML by default, and for good reason. It often really is DYNAMIC and can be a security risk if you do cache it.

I already cache HTML files.
My website has only static pages.
How can I reduce the TTFB to reach TTFB of 30-40msec?

Then your TTFB should be <100ms. What’s the URL of one of these cached HTML pages?

I looked again and it seems that the Auto Minify is checked for JS/CSS/HTML files.
Does that mean it caches html files? If not where do I set it to cache html files?
My domain is rapidtables2.com.

You’re already getting good TTFB from keycdn performance test for cities close to your origin at least. Geography will always play apart in TTFB as would the actual CF Edge server response time in relation to the testing server’s geography. The variance for a CF cached response would come down to distance to the test server’s location.

but looks like you don’t have CF caching as it’s a DYNAMIC bypass right now

Cloudflare cache certain static content https://support.cloudflare.com/hc/en-us/articles/200172516-Which-file-extensions-does-Cloudflare-cache-for-static-content- but not dynamic/static generated html itself by default (which is what WPT TTFB is testing for). But you can tell Cloudflare to cache dynamic/static generated html content to some extent depending on Cloudflare plan you’re on via cache everything page rule but have to be careful to only do this for static html content and not dynamic html content (otherwise you would cache private logged in user content).

1 Like

also looks like you have 2 layers of caching one from Cloudflare and one from Cloudfront but both are returning cache misses so hitting your origin for both as I see cf-cache-status DYNAMIC and x-cache Miss from cloudfront response headers

Oops… thanks.
I forgot to change the CNAME to S3.
But I think the cache miss should happen only on the first test and the second test should not have cache miss. Is this correct?

I added page rule for https://www.rapidtables2.com/* to cache level: cache everything, to cache HTML files too.
Now TTFB seems a little lower, but still much higher than 30-40ms.
Are there other ways to decrease the TTFB?
If I upgrade to pro or business plan will it reduce the TTFB?

Is there a reason you’re chasing lower numbers? You’re talking about a TTFB that’s already faster than the blink of an eye. If you’re serious about speeding up your site, you’d get rid of all the Google resources.

I just tried to load your site from my own browser (not a test site) and after ~10 seconds the Cloudflare error screen said it timed out in Hong Kong. I’m in Australia, so HK isn’t unusual, but the 10 seconds time out isn’t good.

Second try loaded very fast. And I’m seeing header response from both Cloudflare (hit) and Cloudfront (miss).

Cloudflare:
cache-control: max-age=14400
cf-cache-status: HIT
cf-cached-on: Sat, 24 Oct 2020 14:23:15 GMT

Cloudfront:
x-cache: Miss from cloudfront

The TTFB of my test site and computerhope.com are different.
Both work with CF.
The Google resources are necessary for displaying ads and to pay my bills :slight_smile:
Any idea how to eliminate the TTFB time gap?

Thanks, I changed the CNAME to S3 and it gave very high TTFB times.
When I changed back to Cloudfront, the TTFB seems to be back to normal…

What do you mean by “remove extra code”?
Will reducing page size reduce the TTFB?

The example website you posted (computerhope) is using Cloudflare as its domain registrar. That has to be worth a few ms faster speed tests.

Why? The domain registrar is not important to performance since the DNS is doing the job.

That is correct.

Running your site at sitemeer.com/#https://www.rapidtables2.com/ returns quite a few figures beyond ten seconds and timeouts

It seems your server does not like concurrent requests too much.

2 Likes

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.