TTFB - Time to First Byte is still not under 100 after applying page rules full cache

I’ve changed my Cloudflare plan to PRO Plan and applied the page rules to cache everything to get the TTFB under 50. But, It’s still random and getting 50 - 300. I followed many tutorials and in all, it is showing that TTFB gets under 50 in global locations.

Here are my Page rules

Please help me to get TTFB under 50 for all the global locations.

You won’t be able to get all geographical locations under 100ms TTFB as TTFB depends on 2 aspects, the client location and server configuration and the target server’s location and server configuration. Either one of these has variations or changes between locations, then you’d have variances for TTFB.

For example a different TTFB test at Measure TTFB from 35 Locations - SpeedVitals will show different results too as their test client’s server configuration and location would differ too.

Proper way to comparisons between CF ‘cache everything’ page rule enabled vs disabled for tests and see the relative improvements in TTFB for those specific test client locations listed by KeyCDN performance tool.

2 Likes

You can use wget or curl command line commands to check the headers of HTTP response from your site. In those headers, you find diagnostics information if the page comes from Cloudflare cache, your server or how the page was cached or not.

Here is an example for our website:

[/tmp]% wget -S "https://tradingstrategy.ai"
--2022-02-04 12:10:05--  https://tradingstrategy.ai/
Resolving tradingstrategy.ai (tradingstrategy.ai)... 172.67.73.33, 104.26.6.210, 104.26.7.210
Connecting to tradingstrategy.ai (tradingstrategy.ai)|172.67.73.33|:443... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Date: Fri, 04 Feb 2022 11:10:05 GMT
  Content-Type: text/html
  Transfer-Encoding: chunked
  Connection: keep-alive
  cache-control: public, max-age=300
  link: </fonts3.css>; rel="preconnect", </_app/assets/start-6f5e0715.css>; rel="preconnect", </_app/assets/pages/__layout.svelte-f31b19cc.css>; rel="preconnect", </_app/assets/pages/index.svelte-84a34be8.css>; rel="preconnect"
  permissions-policy: interest-cohort=()
  vary: Accept-Encoding
  CF-Cache-Status: DYNAMIC
  Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
  Report-To: {"endpoints":[{"url":"https:\\/\\/a.nel.cloudflare.com\\/report\\/v3?s=YmYKP22FtuJShE2%2FD%2By91cB7rUjLO9U3NUa3bNTc3yvrY0H%2F%2FbuNYpC5%2Bw9WALvG562KkkuKuvFupBES4oD2cHtYiFTq2sb6%2FhiLtsf1iH4eYfJA2EfS0vI1RRLS26xp%2Bp5N6Q%3D%3D"}],"group":"cf-nel","max_age":604800}
  NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
  Server: cloudflare
  CF-RAY: 6d837353fb3669ee-MAD
  alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
Length: unspecified [text/html]
Saving to: ‘index.html’

Check this header:

CF-Cache-Status: DYNAMIC

Unless you get HIT it means Cloudflare did not cache the page. In this case, the page was cached.

Generally, it takes some additional tuning to make sure Cloudflare caches HTML responses, as this is not what most people want. Static media like CSS and JS is easier.

@eva2000 That’s not true for our website as our page is cached under CF, Please see the headers in the below test.

You shall note that it took 363.35 ms. I need to understand why it’s taking over 100 ms while the page is fully cached in Cloudflare.

Try without must-revalidate cache control directive or disable origin cache control on those requests and see if makes any difference. However, again there can be variations between runs as there are probably a single server on both ends doing the request and serving from Keycdn and Cloudflare’s end

@eva2000 I did it. but it’s the same.

Please note that KeyCDN is testing from their server location in Dallas and Cloudflare has their Data Center in Dallas as well.

So, Why does it take that much time? Also, It’s random every time.

I just need a logical explanation of this. If the client and Data Center are in the same location ( I know Dallas is big, but still it should not be random every time. )

I tested with KeyCDN Performance checker, Speed Vitals, and Many others.

It’s random as TTFB depends on 2 aspects, the client location and server configuration and the target server’s location and server configuration. Either one of these has variations or changes between locations, then you’d have variances for TTFB. Location being the same does not mean that the servers handling the request are the same within each location’s Data center on both Keycdn and Cloudflare’s side.

Have you tried testing with WebPageTest as they generally use more uniform servers on testing end and allow you to set the number of test runs and then plot them on a chart and/or compare all runs.

However if you still feel there’s an issue in a particular location, you can submit a support ticket with Cloudflare so they can check their side.