Baseline Time to First Byte

[00:00:00]
>> Todd Gardner: The first metric in the sequence is Time to First Byte. If Time to First Byte is slow, how do we make that faster? So remember, Time to First Byte is how quickly your host responds to the request, and Time to First Byte doesn't exist in isolation. Time to First Byte is part of FCP, which is part of LCP.

[00:00:20]
So even if you're trying to make LCP faster, even if that's your ultimate goal, if your TTFB, if your Time to First Byte is slow, that's a big contributing factor, and it's gonna make everything else faster along the way, which is why we're starting here. So let's figure out where we are at right now with Time to First Byte.

[00:00:44]
So I'm going to go to, I have deployed devstickers to this URL. I've put it in Amsterdam because we're in Minneapolis right now and I want to make sure that we see real geographic network lag. So I've put this on a DigitalOcean box in Amsterdam, and it's at eu.devstickers.shop on port 3000.

[00:01:08]
Oop, and we'll just go out there, turn on Chrome Throttling, and check the performance profile of what we get. So I've gone to eu.devstickers.shop, port 3000. And In my Chrome tools, I'm gonna go into Network, and I'm going to set my network throttling to the USA Coffee Shop WiFi, which, as you might recall, is set to 10 megabits down, 4 megabits up, 50 milliseconds.

[00:01:38]
Which is slightly faster than the global average mobile connection, but not a whole lot. All right, so we're on eu.devstickers.shop. We have the USA Coffee Shop WiFi, we have a six second slowdown. And now we're gonna hit the little Recycle button and it's going to reload this page.

[00:01:58]
And it's gonna generate a full trace of how exactly things are right now.
>> Todd Gardner: Which is quite slow.
>> Todd Gardner: Loading profile, great, perfect. So here's what we got for this load. Now, this load goes from zero time origin all the way to about 24 seconds, it's everything that needed to happen in place.

[00:02:41]
Now, we can also always reference back to this, because all these performance profiles are kept over the life cycle of Chrome, so you can reference back to things and see how things are going. Now, where we're at right now is that all of the metrics kinda stack up right here, we can see that there's this Timings row in the performance profile.

[00:03:01]
And so here's where we're gonna look at, FCP, LCP, First Paint, those sort of things. But the Time to First Byte is gonna happen sometime way, way back here, way back here while it was loading. Somewhere around 1.9 seconds, is what I would look at from here. Now, for some reason, it chooses not to show it here all the time, but thankfully, we have our web vitals extension installed, and so it also dumped all that information out into the console.

[00:03:38]
So here I see that our Time to First Byte was 1.775 seconds, which is pretty bad. But I mean, not entirely surprising, given a totally unoptimized site hosted in Amsterdam that we're accessing from Minneapolis with all of these slowdowns in place. So that's where we're starting with our baseline before we start improving anything.

[00:04:00]
So let's start figuring out some things that we can make better. So do you need to worry about this? Check your RUM data or your CrUX data for what your p75 is. Here's your Google targets for what this thing should be. Maybe you should be faster than this, depending on what your users want.

[00:04:19]
Most likely you shouldn't be worse than this, unless you're a private site that holds your users hostage.