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]
