Introduction to Dev Tools, v3

Network Performance & Network Waterfall

Jon Kuperman

Jon Kuperman

Introduction to Dev Tools, v3

Check out a free preview of the full Introduction to Dev Tools, v3 course

The "Network Performance & Network Waterfall" Lesson is part of the full, Introduction to Dev Tools, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Jon discusses the importance of page load time and its effect on user traffic. Network terminology, filtering requests, inspecting packets, how to watch an app load with screenshots, simulating network conditions, emulating offline mode, and discussing the network waterfall are also covered in this segment.


Transcript from the "Network Performance & Network Waterfall" Lesson

>> So this I have broken out into three sub chapters, because they're kind of three different ways of looking at performance. The first one that we'll cover is network performance. That's going to be like things coming over the network to from your servers to your users. The second section is going to be CPU performance.

So that's going to be like the page has loaded. And now the users doing stuff and how slow is that? And the third one is gonna be memory. And that one is also gonna be kinda on page load. But it's gonna be how much memory your app is allocating, do you have a memory leak, things like that.

So those would be the kinda three sections. So we start with network performance. One thing I always find really interesting Is every time some company does a study the metrics they come back on for how important page load is always kind of blows my mind. So I have like a couple of things that I was just able to find where it's like Walmart Amazon, finding that 1% increase in earnings for every 100 milliseconds that could shave off their webpage speed.

Is like, hugely substantial amount of money, just things going faster. And I think we all know it at a certain end when it gets really bad. You go to a website and it's like spinning and spinning and spinning, like I'll just go find a different website. But I'm always amazed that when you look at the aggregate, like how many users that you just lose, with even small like barely perceptible slowdowns Yahoo saw a 9% increase in traffic for every 400 milliseconds they improved.

That's like less than half a second. Huge increase. And Google's as it loses 20% of their traffic for every 100 milliseconds they take to load. That one makes a little bit more sense because you, you really expect Google to be instant like, you expect those to be Really, really fast because you're not there to stay here or there to go to another place. And then these just interesting numbers like in the one to three second range as your page is loading people up.

Probability of leaving goes up to like 32% as it extends to like one to five seconds. It's like 90% And then bounces just increased like over 100% more bounces as you go past that 5% five second range so you can really losing a lot. You can get a lot of this info if you use like Google Analytics or something you can see how many people bounce but, but it's a little bit harder to measure because Google Analytics like depending on where you put it in your script, People might even leave before it loads, right.

And so it's it's probably even worse than that. So that's kind of the importance of this network stuff. And I think it's always important to, to have a little bit of like empathy for your users. This is really common where like, you'll be at some big company, maybe and you're like in.

San Francisco in the United States on a brand new MacBook Pro. And you're like my site is really fast, right? Like it loads like right away and it's really good. And then, there's like so many places with worse internet connection and there's so many people on worse devices.

And then you start thinking about well what about people using it on mobile devices on worse internet connection? I mean, it really, it really can be a very different experience based on where you are. And I think even people living in like very modern high internet speed cities like if you take the train somewhere and you go in a tunnel and you lose your connection, like we all know That frustration right or you're like at an airport, and all of a sudden everything is crawling like.

So I think it's really important to not just test on, the maximum the best possible conditions, but to think about your user base. Again, with a good analytics tool, you can get a lot of this like, You actually have a lot of users in this region or that region.

And there's tons of stuff you can do, which is kind of what we're going to be covering So yeah, we're gonna kinda learn network terminology, and then what the Network tab can do. So if I go ahead and I open the Network tab here, we've sorta seen it once already.

And let me go ahead and click this cog and disable screenshots just for now because they take up a lot of room, and then I'll refresh the page. So Like we covered at the very beginning, you see like this list in order of every network request your app made.

And the bigger the app, the more network requests you'll see, especially as there's like analytics and tracking code and ads and all these images and, everything's a network request. So you'll see the name of the request here. You will see the status, again this isn't like a web fundamentals class, but it dev tools kind of taps into everything, so, for those that know like network status is like 200 is okay, a 400 is usually like a client side error, 500 range is like a server side error, all these different things.

It's nice to see these, they'll actually go red when the error and error as well. The type that it is documents, stylesheets images all that the initiators kind of interesting because you can kind of get this waterfall view of like, okay your document came in that called a JavaScript file and that called a JavaScript file and you can kind of like watch it.

There's also a kind of a cool tip and trick which is you can hold Shift as you move around. And when you hold shift over an item, it'll turn everything that item called Red. And if that item was called by something, it'll turn that green. So you can see like this font here, the font was called by network dot html, that screen and it called two other files.

Those are rad. It's just kind of a neat way of like visualizing what happened. You can also see the size. And when this is cached, like if you use compression and caching, you'll see that on this as well, and you can see how long it took to load.

And then you get this really cool waterfall. So this is what happens when you hover over these here. You get this waterfall, And the waterfall like if you have a request that's taking a really long time, the waterfall can help you figure out where in the process that request is getting stuck.

And we'll cover that in a second because that's kind of a pretty in depth one. But it's also worth noting that if you right click on any of these, there's actually a lot more columns that you can add So you can add like the path, the URL, what domain they came from, you can add cookies that were set the priority of it all those kinds of things.

And again, just to give a bit of context here before we go into the waterfall terminology we've kind of seen like a script and or an HTML file, we'll call scripts we'll call CSS call images, all these things, but it's really important to know that on the browser level, you get like a certain number of requests, which is, I believe, either five or six depending on the browser that you can do at one time.

So if you tried to call like 20 images, it would send out six requests, you know, for the six first images. And then as they come down, then it would start filling like a queue basically where I would call the next images. So it's worth knowing right away that you can't just do unlimited requests.

And if you think about it, that's where we get this culture of like concatenating our JavaScript files or using CSS sprites instead of images. Because there's a performance gain to be had by having less total requests. So for those familiar with that, who have like bundled their JavaScript together or who have stuck images into a sprite or bundle their CSS, that's why it's because we're limited to the number of resources.

But the other thing that's really interesting is that Rather than just going down your HTML, and just like in queueing everything it sees like script, CSS, CSS, CSS, you know, going through, the browser's really smart, and it tries to figure out things that it thinks will be higher and lower priority.

And then it goes down a priority list which is like really great because otherwise. If you think about it, you could put like an image tag and then a CSS tag right after it and the CSS you need that styles your page and the images like I mean, it's you do need the image eventually, but it's usually more additive.

So what chrome will do is it has this whole system in place where it'll be like, I think these are the top priority. I think these are medium. I think these are lower priority. And that way you don't have to restructure your HTML in a weird way just to get things to load.

So you can actually right click here and you can do priority and it will add this new column. And it's kind of cool to play around with where you're like, like it views, my HTML obviously, and my CSS is the highest priority. Then it gets to this PNG here I've used that as low priority.

And then back down here, these font files that are needed to render high priority these two PNGs low JavaScript, medium. It's kind of interesting to see how the browser thinks about it. And it sort of makes sense where usually the HTML and the CSS are like the vital things, like get the site to display and then JavaScript is like.

Probably somewhat important, but usually it happens after the page load the JavaScript kicks in. And the images are like the lowest importance thing. It's just kind of an interesting thing to see. Does that make sense to everybody? That kind of six total requests at simultaneous requests and they're more advanced than you would think.

Cuz Chrome and Firefox and Edge all have a system to figure out what the priority order is. Let me know if you have any questions on that.
>> Is there a way to change their priority order? Because I remember you can defer scripts.
>> Yeah.
>> And the head does that.

What does that do to the priority order?
>> Yeah, so you can override it. You can You can make things like higher priority. Well, so there's a couple ways you can override it. Yeah, you can move things up to the head. So like Google Analytics will be like, for example, I want my JavaScript to be in the head please, which will make it a higher priority by itself.

You can also do things like you can like preload images, you can be like, this one's really important. And then you can Yeah, exactly on the on the other side, you can defer and that says this is less important, right? So yeah, so you can go in and you can either preload or defer.

And you can also move things around in the structure so that they're, you know, higher up or whatever. And that and that will override these. Yep. So the waterfall is interesting, because I feel like it's largely ignored. And then one day you'll have a thing like this happens to me all the time at work will be like, Hey, Why is this taking so long?

And I'll be like, it's this call this API call. And then my boss will be like, well okay, but [LAUGH] Whose fault is that? Right? Not that my bosses mean, but they'll be like, well, what's the problem? Is the problem like the response is too big, is the problem that the service is too slow or that we're too slow or, So this can be really interesting.

So it provides this really nice colour coded timeline for things that can really help you dive in. And when you're making a ticket, especially if you're like a front end engineer making a ticket for a service engineer, it can help a lot and be really impressive. Again, like one of the themes of this is like Dev Tools helps you cheat a little bit.

They can be really impressive where you're like, Hey, this is a DNS issue or like, Hey, this is an SSL issue. They're like, Whoa, How did you know that? It's like I'm really cool, so what I've done here, if we close the dev tools, I've sort of broken down the waterfall in order and the colours used here are the same colors that Chrome dev tools uses.

So, the first colors you'll see which is at the top are white and grey and those are queueing installed. Queuing is exactly what we just talked about. Either there's higher priority stuff, or it's the same priority, but we've already hit our 6 total connections. So I gotta wait.

Or and this is very rare. The browser is doing some work and just needs a second, that's fine too. And so then they'll show is stalled the entire time that they're stuck queuing so you can see how long they waited. Then the next three are kinda green and orange.

Those are like setup things happening. One is DNS lookup. So we all know that we request like But that's not a computer's address, right. That's a domain name. So it has to go to the DNS service and find what server to actually reroute to. So if that's slow, that's something going on with DNS routing, not not our company.

Then it sets up the initial connection, right? So the TCP connection SSL connection, there could be a problem in there. If you're using a ServiceWorker. Like if you have a progressive web app, you can see another orange bar for ServiceWorker setup like it's being bootstrapped. And then purple ServiceWorker has been set up, it's starting to respond.

Now green is an interesting one green and blue are like the data has gotten on the server and it's coming to you finally, green is waiting time to first byte which is a metric that a lot of sites use to mark performance of their services, which is you know, I say give me foo.png, and then my computer, Chrome, will mark when I get the very first byte of data, the very first packet of data comes over.

I can use that to kind of gauge how quick my connection between the server and the client are. And then content download is how long it takes for all the rest of the bytes to get over. This one's interesting because this can be largely a client issue, right?

If I have a JavaScript file that's like 100 kilobytes, it's going to take a very different time to download In that San Francisco, you know, high speed internet connection than it is if you're on the train, and you're going through a tunnel or something like that. But it can be really nice to kind of categorize things like the white and gray means that too many requests, right?

And we're just the browser's just stuck. Not even working on those requests, yet. So you can kinda concatenate your scripts, image sprites, all that cool stuff. The green and orange is like stuffs being set up on the service side. So maybe there's like a hiccup with the DNS registry or the SSL some Something like that.

The waiting time to first byte is slow. It's a service issue. So you can go to your service, you can be like, hey, time to first byte is really slow. Maybe it's a database problem. Maybe the servers are overwhelmed or they're just slow, something like that. And when content download becomes an issue, you can't just blame the user.

So you'd have to figure out what you can do to make the content smaller, right? If people are just you know, waiting and this is something that we see Lot of especially in this like modern world where it's so easy to go shopping for new JavaScript libraries, you just keep adding them to your code base.

You know, you're like, I need a calculator app and I need this. I need that or whatever the things get really big and you'll see large content download times.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now