Time to First Byte (TTFB)

[00:00:00]
>> Todd Gardner: So where are we? We're still talking about measuring web performance. We've talked about Legacy Metrics, we've talked about the Core Web Vitals, we've talked about Waterfall Charts, and we've talked about Flame Charts. So now there's a few more metrics that are interesting that we should talk about.

[00:00:18]
And then we're gonna talk about capturing them, and the browser support for this stuff.
>> Todd Gardner: So more performance metrics, even more. We've already talked about five, six of them, but there's a few more that are interesting. First, the Time to First Byte TTFB, the one that breaks the three letter acronym rule.

[00:00:43]
The Time to First Byte is a super interesting metric, and it's a measurement of how quickly your host responds. This is the most opsi operational of all of the metrics. It is almost, it has nothing to do with your client side code. It has nothing to do with your HTML or your JavaScript or your CSS.

[00:01:05]
This is how fast can your host get bytes out in response to a request. So, if we look at a very simple waterfall chart, here is that the first thing that the browser does you go and ask for an Ht. You go and ask for a website, it makes a request, it starts shipping a document out.

[00:01:25]
Here's where TTFB lands, as soon as the first byte has been received from your host, that's TTFB. So largely this is measuring your server and network performance. How fast can you make that database call? How fast can you ship bytes across the wire? How fast can you get those things out?

[00:01:46]
Let's take a way more minute detail look at this because even though this has nothing to do with the client side of web performance. This is still a really important thing and there's lots of performance optimizations that we can do around them Time to First Byte. So, here's all of the different things involved.

[00:02:05]
So, when the user goes to a website, let's say they go to Google and they type in developer stickers. Developer stickers online is the first result, click on it. What is actually happening under the covers? Well first, start time is measured from the click, from the navigation from Google.

[00:02:24]
And then there might be n number of redirects that happen between, hey, you land on this analytics tracker and then you land on this URL and this URL redirects to this URL. All of those count, all of those are count against you. So, having a lot of redirects does hurt your performance.

[00:02:44]
So we count all of those redirects. And then there's a bunch of browser stuff that happens with service workers, which is out of scope of what we're gonna talk about today. And then it looks to see if you have a cache locally, and it takes a little time to do that.

[00:02:58]
And if none of those things are happening, then it does a DNS lookup. It says, all right, what is developer devstickers.shop? Where do I go to get that? And then it tries to establish a TCP connection to it, so it tries to talk to it, and then a request will start.

[00:03:15]
It'll be great I have a connection to their host. Then once the request has completed and we start receiving bytes from the response, that's TTFB. So we don't know everything. We don't have the entirety of the HTML document. We've gotten a response from the server, TTFB fires.
>> Todd Gardner: How fast does that need to be?

[00:03:45]
Now, Google publishes these sort of guidance on what it thinks it should be, but they don't hold each of this. TTFB is not an SEO effecting metric. It's not penalized for you, it's not a Core Web Vital, but they do still give you guidance for it. Because TTFB does affect other things namely TTFB affects your LCP.

[00:04:09]
If it takes a long time to get the first byte from the server, it's gonna take a long time to render the largest thing on the page. And so in general this should be less than 800 milliseconds. So less than a second for all of the redirects, all of the network hops, your server to do all of the database calls and all of the things it needs to do and get the bytes out to you, 800 milliseconds, which is really fast.

[00:04:34]
Public websites usually can't do database calls as part of rendering things to the user. Generally, it's gonna be really hard to hit that 800 millisecond limit. If you do a database call in response to a public website.