How to find and evaluate "best case" TTFB?

What is the proper way to determine “best case” Time-To-First-Byte? (TTFB)

And is this site’s time good, average, or poor?

Please share your knowledge and experience. I’ll give some examples from my own site below.

Connection Speed appears to make a big difference in TTFB, and WebPageTest offers a variety of connection options. Here are some example Connection Speed vs TTFB results for my site:

LTE (12 Mbps 70ms) : TTFB = 0.378
4G (9 Mbps 170ms) : TTFB = 0.782
Cable (5 Mbps 28ms) : TTFB = 0.207
3G-Fast (1.6 Mbps 150ms) : TTFB = 0.721

I had assumed that since they are listed from highest Mbps to lowest, that LTE would be the fastest TTFB and 3G-Fast would be slowest. But it is not working out that way. Any ideas on why not? Is it the second number (like 70ms) that determines TTFB differences for a page?

My best TTFB was 0.207 seconds on the Cable connection. Here is the link to that test:
https://www.webpagetest.org/result/210227_DiN9_f0ffe74816663da19fd23c8e3b58bfb2/1/details/#waterfall_view_step1

1) Should I consider 0.207 to be my site’s “best case” TTFB?
2) Is that time good, average, or bad?

About the components of TTFB… (DNS + Connect + SSL + HTML)
This picture shows my site’s TTFB with different connections:

Do the component times for DNS, Connect, SSL, and HTML look good, average or poor?

If it is hard to see on the picture, here are those times:
LTE : DNS = 69ms / Connect = 91ms / SSL = 101ms / HTML = 98ms
4G : DNS = 174ms / Connect = 188ms / SSL = 200ms / HTML = 188ms
Cable : DNS = 26ms / Connect = 47ms / SSL = 67ms / HTML = 57ms
3G-Fast : DNS = 149ms / Connect = 170ms / SSL = 201ms / HTML = 187ms

Thank you for helping!

Greg

Good questions @greg-baka!

TTFB is one of those metrics that people would say not to obsess over. It can certainly be “gamed” to meet a number and the some portion of it is outside your control (end users connection type + distance from origin). However, the intention is that it indicates how fast your infrastructure/server/software is - particularly for dynamically rendered websites using something like Wordpress or another CMS. If you have a slow server or slow CMS software, the TTFB will be higher. Often cheap shared hosting will have a higher TTFB, and so TTFB might be used as one of many quality signals for search engine ranking.

0.207 is a good TTFB by today’s standards - I believe the current Lighthouse recommendation is lower than 300ms for the “green” good range. Also the majority of your 207 ms is in DNS/Connect/TLS on your waterfall and not the majority in your server “waiting”. Overall, your waterfall in the linked test run below looks pretty good with a reasonable LCP and fully loaded time. I can tell you have been optimizing!!

On the other hand 700+ ms TTFB on your less optimal test runs is kind of long.

The only thing that concerns me in your image below is that while I would expect the DNS+Connect+TLS times to be faster on cable, the light blue “waiting” time between TLS and first byte written is also faster on cable on your screenshot below which is more a measurement of the server speed - so I’d want to know if your web server/CDN was more “warmed up” for this test round than the other test rounds. It may not be, it might just be “tcp slow start” - but I’d want to make sure you aren’t comparing a warmed up server test run against a cold server test run.

Also your test run does not detect a CDN - are you using one or not? I’m not advising for or against, just want to know. As your test runs will fluctuate differently depending on whether there are cold/warm CDN edge locations involved and the physical distance from the test location to your origin server.

As far as overall TTFB optimization goes, there are a lot of factors that go into that…

[size=large]Client Connection Type[/size]
First of all, the uncontrollable part you mentioned above: end users connection type. Mobile (cell phone) connections have an inherently higher latency - not necessarily slower bandwidth.

Network Latency is how long it takes for a request to get from your client device (like a cell phone) to your server and back - regardless of the size of that request (ideally measured with a small payload that fits in a single packet/chunk/frame, like a request smaller than 1kb).

Bandwidth is how long it takes for that connection to transfer a larger chunk of data (like a video) on a sustained connection regardless of how long it took to establish that socket. So once the socket is established how long does it take for the client to download a 5mb video.

On mobile networks the time it takes to establish a TCP socket will be longer than the same operation on a wired high speed connection (cable internet). And even on wired internet connections newer fibre optic connections may be a few ms faster than older DSL/Cable connections.

So this aspect of the TTFB is beyond your control.

[size=large]Geographic distance between client and Origin[/size]
Another factor not mentioned above is the geographic distance between the client and origin server. Making a request between two endpoints in the same city is likely very very fast, making a request across the globe will inherently have more latency involved. If your business is inherently local, you can optimize for this by having your server located in or near the geographic area your business services (“Plumbing Services in {Insert City}” = host your website near or in this city for very fast average TTFB in the real world).

The purpose of using a CDN like CloudFlare is to hopefully level out your average TTFB around the globe by caching assets physically close to the clients at many local “POPs” (Points of Presence) or “edge locations”. However those local CDN edge locations will also have a slower TTFB for the first request for any given resource as it has to fetch from origin server before caching locally and serving multiple times.

[size=large]How to “game” TTFB[/size]
Some performance measurement tools measure the time from when a request was sent to the time the client receives the first physical byte on the tcp socket - which is going to be HTTP headers and other overhead, not “real content”.

Some other performance measurement tools measure the time from when a request was sent to the time the client receives the first byte that is part of the HTML Markup (ie: the opening “” tag). This more accurately measures the speed of your server vs measuring the speed of the network connection as it requires that your server has actually begun sending the client “real content”.

Some servers/software will prepare the entire HTTP response in memory on the server before “flushing” anything out the socket (a “buffered response”) - meaning the TTFB may be delayed until the entire response is ready to be sent.

Some servers will progressively flush chunks of the response while the server is processing. Often the HTTP headers can be sent sooner than the HTML body, and you can write out the HTML body progressively in chunks too.

This means you could game the system by writing your web server code to always respond quickly with HTTP headers and the first minimal piece of HTML content, even though you may take another full 1000ms to render the rest of the HTML content. While this may trick some testing tools, it won’t really improve the user experience if the total time taken to retrieve the HTML content is the same.

[size=large]Next steps for you[/size]
Your optimal test run is pretty good… but you said some of your other test runs were a fair bit worse.

To really understand the difference between your 207ms TTFB and 700+ms TTFB, I’d probably start with this:

[list]
[] Isolate each test run to make sure they are starting with an equally “warm” or “cold” server. The easiest way to do this right away is to run perhaps 5 iteration test run as a “throw away” first (some server software doesn’t cache requests in memory until after 3+ requests for the same asset), then run your real test runs next. Your server and any local CDN cache locations should be all warmed up and the tests would now be “comparing apples to apples”. Testing all client connection types against a cold server is harder to repeat reliably unless you can setup a “test/staging” copy of your website, where you are able to restart the server before each test to see the true worst case cold server TTFB.
[
] Decide if you are focusing on a local market or not. If not, consider using a CDN like Cloudflare. If you setup a test/staging copy of your site, you can always test it before applying to your production website. Cloudflare can increase TTFB on low traffic websites if most requests are always a backend requests to origin… so if you are a brand new site it is not always going to improve your real world user metrics even if it improves your test metrics.
[/list]

Hi Ben, Wow, this is helpful. (I am sending you a PM about doing a little consulting)

To try to answer some of your questions…

Location: We have a ecommerce store that only serves the entire Lower 48 US states. But our informational articles and guides get traffic from around the world.

Server: We do not use a CDN. We do use shared hosting at GreenGeeks.com who have servers in US, CA, and EU.

Site Code: It is a static HTML site that is responsive. Our pages and images rarely change. We do not use a CMS. We only use the “checkout” portion of our ecommerce provider. The pages are hand-coded static pages with BUY buttons that take people to the cart to complete their purchases. It takes a little longer to do site updates, but I can tweak each page independently.

Warm vs Cold server: I assume it was warm since I did a bunch of webpagetest.org runs before the TTFB tests I made the picture from. Isn’t a shared server always warm? :rolleyes:

I think that covers your questions up through the “Next Steps” section.

I have been doing a lot of speed optimization work, but I am starting to bang my head against the stuff I don’t really understand (like servers) and code I have minimal skill with (like JS).

Thanks again!

Greg

The second number in the connection configurations is the round-trip latency associated with the connection itself. The TTFB includes at least 3, sometimes 4 round trips (DNS, socket connect, TLS negotiation, the request itself).

WebPageTest calculates the target TTFB so that it allows for the connection setup and normal connection latency + up to 300ms of actual server processing time. Any longer and it starts to lose letter grades (one per 100ms).

1 Like