*NEW* Speed Up Webpage Loading 2021 - Part 6: Network Panel & Waterfall (DevTools) | Clyde Matthew | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

*NEW* Speed Up Webpage Loading 2021 - Part 6: Network Panel & Waterfall (DevTools)

teacher avatar Clyde Matthew, !false | funny, because its true

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

11 Lessons (39m)
    • 1. Course intro

    • 2. Network panel

    • 3. Network panel - waterfall intro

    • 4. Waterfall - more detail

    • 5. Response and request headers

    • 6. Time column and the waterfall

    • 7. Time bards - 3 things to watch out for

    • 8. Breaking up time

    • 9. Time phases explained

    • 10. What is a CDN

    • 11. Closing Comments

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class



What we cover in this particular class?

We will cover of ton of information in this entire series, but for Part 6 we are diving into how to view and analyze resources of a site (by resources I mean all assets fetched from a server, including html files, css files, js files and images). 

Identifying and resolving critical rendering path performance bottlenecks requires good knowledge of the common pitfalls. 

And a great way to see the pitfalls is knowing how to use DevTools to its full advantage, and specifically the Network Panel. 

This is why I'm going to spend a lot of time in this class teaching you about the Network Panel (used to find and solve network issues to optimize websites) and the waterfall chart (gives us a visual representation of how all the assets on your website load, including your CSS, JavaScript, HTML, images, plugins, and third party content).

For every resource, there is a time stack showing how long each part of the process has taken. For instance, the time a resource takes to load will be broken up into Queueing time, Stalled time, Request Sent time, TTFB and Content Downloaded time. 

A lot to cover, right. But stick with me because we're going to have a lot of fun. 

Lets get into it.  

What this entire series covers?

Why 1-second matters hugely?

A one-second delay in page load time yields:

  • 10% fewer page views
  • Less customer satisfaction
  • Loss in conversions

Aside from influencing ranking well with Google, a few extra seconds makes a big difference to viewer attention, interest, conversions and hence profit.

Understanding the Critical Rendering Path will enable you to become an awesome programmer. Take control through understanding. Delivering a fast web experience requires a lot of work by the browser. Most of this work is hidden from web developers: we write the markup, and a nice looking page comes out on the screen. But how exactly does the browser go from consuming our HTML, CSS, and JavaScript to rendered pixels on the screen? By understanding this, you will be able to write better code in order to boost your website traffic, know how to precision fix and tweak behaviour and performance, improve your market penetration and your margins. You’ll also gain an advantages over other developers who seem to just push the buttons without fully appreciating what is happening.

In this course you’ll learn about the Critical Rendering Path. This refers to the set of steps browsers must take to fetch and then convert HTML, CSS and JavaScript into living, breathing websites. From there, you’ll start exploring and experimenting with tools to measure performance. You’ll learn simple, yet very powerful strategies to deliver the first pixels to the screen as early as possible.

Knowledge of the CRP is incredibly useful for understanding how a site's performance can be improved. There are various stages to the CRP, such as constructing the DOM, constructing the CSSOM, running JavaScript, creating the Render Tree, generating the Layout and finally Painting pixels to the screen. As you can see, this Skillshare series covers a whole bunch of interesting material.

By the end of this Skillshare CRP Series, you'll be able to “speak” CRP by gaining an understanding of how to fetch data from a server and then get that data to your user as quickly as possible. We dig deeper in every lecture, learning about things like HTTP, TCP, data packets, render blocking resources, and a whole bunch more! This course has many bonus lectures which extend your knowledge base and test your skills.

Through practical examples, this course helps you understand the CRP piece by piece. And we use the latest and best features of JavaScript and browsers (like the new Fetch API) along the way so you can stay ahead of the pack.

Is this course for you?


It doesn't matter where you are in your web development journey. It's suitable for all levels.

Still unsure? If you fit in any of these categories then this course is perfect for you:

Student #1: You want to dabble in the world of programming: learning the fundamentals of HTTP, AJAX, Data Packets and Rendering will allow you to extend this knowledge to any language

Student #2: You want to gain a solid understanding of web performance

Student #3: You want to start using backend frameworks like Node.js, which are heavily dependent on having a deeper knowledge about how to make AJAX requests, manipulate the response and then deliver it to the screen

Student #4: You know what the Critical Rendering Path is, but have little knowledge about how it works behind the scenes, and how to practically implement it in your code

Student #5: You have taken other courses in web development but just don’t feel like you’ve grasped it


Meet Your Teacher

Teacher Profile Image

Clyde Matthew

!false | funny, because its true


Ideas are a dime a dozen. The hard part is execution. Unfortunately, most people never carry tasks to completion.


I've worn many hats in my career …  As a result, I have an ability to view all sides of a coin, something that is becoming crucial in our tech-savvy world.  


My experience and a few words:


·        I’ve had to learn things the hard way (aka: hard slog)

·        I want to teach people what I’ve learnt, with the hope of making a meaningful impact (cliché, but true)

·        No one is a master of everything. But at the same time... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Course intro: Welcome back my Skillshare students. I'll be having as much fun in this entire series is IM. We've done a few classes now, haven't we? But this class is going to be phenomenal. It's going to be really interesting because up until now in previous classes we've been looking at network requests. We've been looking at the CRP critical rendering path, but at high level. So now I want to dig deeper and specifically, I want to start analyzing the resources on every single page we visit. And in order to do that, we're gonna be using the Network tab and in a pre-test is very interesting because not only does it tell us the resources that had been fished for that particular page. It also gives us a lot of information about every single resource. And we can use this to identify bottlenecks. So in this class we're looking at the network tab. We're going to be looking at different sites. I'm going to be looking at just the simple Google site. Then I'm going to go on to more complicated website. We're going to look at the resources that are downloaded. They were going to be looking at what we can see in the Network tab. And one of the most important things in the Network tab is the time column or the waterfall column. Because that really comes down to how are resources loaded. And we're going to be digging deep into that as well. We're going to be looking at what queuing is. We're going to be looking at what THE FBS lot, I know. Weird, weird, weird. So what I'm trying to say is we're going to be learning a ton of useful information in this class. It is for everyone. If you've never seen this the fault, no problem. If you have been an experienced developer, this will only help you. So it's going to be a relatively short class, but a very, very interesting one. Nevertheless, are getting fun, hobby, staying motivated. And I'll see you in the first lecture. 2. Network panel: It's important to understand the phases in which resources are gathered over the network. And up until this point, we've kind of seen phases at a very high level. We have spoken about it. For example, we've seen that a CSS files loaded before, a JavaScript file in the external one file was loaded before the external too far, but we haven't gone into detail on a specific file individually. Heavy. We've just kind of looked at it from a high level point of view. But it's important to understand it at a more detailed level because this is the foundation for fixing load issues for making your site better and faster. All network requests are considered a resource. And because these resources are retrieved over the network, resources have distinct lifecycles expressed in terms of resource timing. Okay, that's cool, but how do I assess all this? Will the starting point is with the network panel within Chrome dev tools are men, but how do you access this network panel? But turns out it's very, very simple. We've seen on numerous occasions how we access our devtools by inspecting the page. All we have to do now is instead of clicking performance, we click on the Network tab. How simple as that. So, so simple. And why do we want to look at the network panel? Will the networks view allows you to see the network requests that make up each page load within a single uses session. You can use this network penalty, investigate the causes of slow pages, and identify things that slow your web page down. And lastly, I just want you to be away when we talk about requests. We just mean the line-by-line calls for the files that build a webpage. So I don't want us to get confused. I just want us to sit back as take the slowly and let's understand every minute detail of what happens behind the scenes. I'll see you in the next lecture. 3. Network panel - waterfall intro: Enough talk. Let's get into it. Let's see what this neat trick panel is all about. So let's inspect our document. And it's good to the network panel, okay, and all I wanna do now is I want to visit a simple site list, just even visit google.com. So here we go. You can see things are loading on our screen. Let me just remove myself because I might be in the way hand, Adios. And you can see on our screen, let me just scroll up to the top. You can see we've got all our files handles really cause we can see every single resource that has been fetched for this page. It's not that meaning because it's a very simple, simple page. But you can see here as our index file, we click on that. You can actually access anything you want. You can see the whole HTML file. And you can go through file by file and you can see what it is. But what's interesting with this is that you can see on the top right, we've got what's known as a waterfall. What is this waterfall? Why is the waterfall chart so useful for us? Well, because the waterfall chart visualizes the loading process, we get to see what was loaded, in what order, the duration and the details of the request are also shown to us with different Bar Links showing us how long each kind of process took two completely load and execute. So all of this data aids in US debugging our page. And it also helps us assess and understand our page in more detail. I know can seem very daunting and can't seem much information on. Don't worry. Piece by piece. Really go slow and look at each element honors liquid panel that you just saw. And finally, don't panic kleeks. Rather have final ergodic coffee. Sit back and let's now just dissect distinguished panel in a little bit more detail at a very high level, the new active again. I'll see you now. 4. Waterfall - more detail: All right, so let's look at the waterfall in more detail. But let's take a site that is a little bit more complicated than Google, and we can literally use any site. I'm just going to use Microsoft.com because that's just the first thing that came into my mind. So let's go to microsoft.com and then start analyzing this waterfall. But first let me remove myself because you had been able to see everything when I'm in the way. And let us visit microsoft dot com. Let's inspect our document and let's go to the Network panel. Okay, so the first thing you'll notice is that it's empty. And the reason is is that we have to refresh our page in order for the naked penalty, analyze every single resource request. So let's do that. Here we go. And you can see a whole lot of files are being loaded as we speak. Okay? The one thing I want you to notice is this blue and red line. The blue line is DOM content loaded event, and the red line is when the load of ink has been fired. And there's a scroll here to the top. And there are few things we can notice yet. Don't get overwhelmed. Those good we're gonna go through very, very slowly what all of these things mean? What are the few things I can point out to start off with? Well, firstly, you'll notice that even after the dawn in the CSS has been fully loaded, that is the HTML, the JavaScript files or CSS files have all been downloaded. The stall documents being downloaded from the server. And in our example, this talk, 31.14 seconds. You can see that at the bottom, right. And that's because there's a whole lot of other files and processes happening in the background. But as a user, we had no idea this was all occurring and hope it's time to sink in. Now why we use async, start using different onload events because as a user, when we just went to go and visit microsoft.com now we saw that page almost displayed to us instantly didn't win. But look at what's happening in the background and what's cool is this bottom section here that shows you very important matrix that tells you when your whole entire site finished loading all the resources, which here we can see it took 31 seconds. We've also got things like the DOM content loaded of ink, which took 806 milliseconds. We've got the load of int, which didn't happen that far after. Okay. So it's making seen so far, right. And hope enough being intimidated, I hope it's just simple. And it is when you start breaking each thing done one by one, you'll see it's not that difficult. Okay, what else can we look at? Well, on the very left, we've got the file names and the format of this noise change right now we've expanded it so we can kind of easily identifier for to JavaScript, CSS file HTML. We can see the blue, open and close kind of brackets they are, or HTML, CSS, JavaScript, CSS. You know, it's, it's all intuitive. If you wanted condensed, you can click on this button. And in a, we can just uncheck, Use Large rows and then it'll just contains everything. But for our purposes, let's just keep it on so we can see. Very lovely. Oops, I've just shut tab salami. This is reloaded. Remember we have to reload to see it. I like using this large icon format because then we can see easily what file type it is. Okay, so what is this name will, that's the filename, and it's the name of the file resource that's being loaded by the web browser. And in the waterfall chart it's prefixed by the HTTP method. Usually a good method or a post method. You generally don't have to worry about this. And you can see if we scroll down, we literally just get gates or posts or care for every single file. The other interesting thing with this name column is dead hovering over the file name will reveal the full path to the file. So if we hover over, you can see the full path to every single file. Interesting, right? And when you're browsing through this list, try and focus on the file extinctions. For example, dot JPG and dot PNG files will be ImageResource. Dot CSS will be stylesheets, ab.js will be JavaScript and so on and so forth. So just keep your eyes peeled or neck when you start scrolling down, you can see here all the a's VG files. These are images. Also, you must keep your eyes peeled for keywords in the filenames because they will help you decipher what they are. For instance, sudden FAR. But if you are using a Wordpress site, you might recognize the name of a plug-in you've installed. Will the name of a theme you're using, for example. Okay, so that's the file name. And like I said, you kind of read the file name with the method together. Then the next column is what is the status column? It's the response status. And the HTTP response status is made up of a status code and an optional human-readable message. For example, you often see 404 not found. The response status is returned from the server. So just remember that that comes from the server. And it tells the browser whether the request was successful or not. And beyond the screen, I'll just put a quick summary of the most popular status codes. You'll see 100 status codes or informational. And they rarely seen Yana waterfall chart. You know, if we scroll down, we actually only seeing two hundreds. So we've actually seen, we've seen no errors, nothing else than to a 100. So 100s of very rare to see, but they are just informational status codes to hundreds or successful status codes, which basically tells us surprise, surprise that the request was successful. 300 status curves or redirection. It just means the request was at some point redirected and three or one is the most common. We've also got 400 status codes, and those are normally client eras in that there was an era in the request itself. So either the file wasn't fine, you've got unauthorized access, you forbidden, et cetera, et cetera. And then we've got the 500's status codes, and those are server era codes. So the service failed to handle the request. The most common of 500 errors, which are internal server error is 503 service and available eras, et cetera, et cetera. And then we've got the size column. Well, intuitively, as the name suggests, this refers to the transferred size of the file or resource. The total combined file size of all your requests make up the total page size. And of course, the lower this amount is, the lighter your pages to download and therefore Foster. So if you see large file sizes, particularly when it comes to images and videos, you should always prioritize fixing these first before going into other areas of the waterfall because it's an obvious problem to fix. And you can see at the bottom are resources on this side all add up to 1.5 megabytes. So that's not that matches it now, which is why it was so quick. And just one more thing. You can see the Under the size column, we've got two sizes. We got the one at the top. Let's look at this first index file. We've got 35 kilobytes and we got a 149 kilobytes shown below. What is that about? Well, it's actually quite easy. The top number is the size of the file that was actually transferred over the network to this browser. And the bottom numbers, the full decompressed size of the file. So it's kind of showing you what the size of file would be if he hadn't compressed it. Okay, now we're getting on to the most important column and that is this time break down. This column is where the waterfall chart breaks down the Pacific duration time required to load each request. And this is way we are going to spend most of our time in the waterfall chart. But anyway, before we start on us, a quick word on response and request headers. 5. Response and request headers: As I mentioned before, we get into the most important aspect of the waterfall chart and that is analyzing the time spent on each resource has Tanisha equity, the request and response headers. So clicking on any request for any resource will reveal the request response headers. Let me show you what I mean. So let's click on this index HTML file. That's quite simple, right? And they regard, he has the request response headers, and these contain a wealth of information with regards to how your resources are being served. We can go through request-response details in more detail later. For now, here are some key items to note. In each section. The most important tab is this header section. And we can collapse all of these. And you can see it's just three general tabs, General response headers, and request headers. Well, what are the request headers? The request headers are the HTTP headers that the browser sends to the server. For a beginner, this nothing really actionable in the request is one thing though, to watch our Ford's HTTP two, which is denoted by lowercase request header names and semi-colons. But don't stress, I'm gonna get into HTTP to my bonus lectures coming up. So there's request headers, response headers, or those headers that the service scenes back as a response and sometimes key in diagnosing performance issues. In basic terms, these response headers denote what configuration, settings or attributes that request was served with. With the response headers. You can Terman whether or not the resource was compressed, whether it was cached with it was served via CDN, whether preserved via HTTP two, and with it internally redirected. And they are many other things we can determine from it. So if I call, you can see, yeah, for example on the screen, content encoding type is a G zip file. So we know this has been compressed. We can see the content link, the content type, the date, etc, etc. It's quite also, is a wealth of information in here. And you can obviously preview what the page looks like. You can look at the actual raw data response and see what that looks like and go through it. So there's a lot of information we have. So that's the request and response headers. But like I mentioned, the most important thing in the waterfall chart is that's right. It's this time, column and net. Here's what we're going to start talking about Mao. I'll see you in the next lecture. 6. Time column and the waterfall: Now it's time to talk about the time column and the time it takes for each resource to be fetched and executed from the server. This is what it comes down to in improving the critical rendering path. Cool. So there are two main ways we can view the time of a resource. One, we can hover over that resource. So let me just zoom in here. Let's just look at R Index.html file. You can just hover over it. And in this, I think I'm just in the way, let me remove myself. And you can see here that this is the time broken down into different aspects. And we're gonna be looking at these in upcoming lectures. Don't get too intimidated yet. So that's a one way we can look at time. The other way is you can click on the resource and you can click on this timing tab here on the top right. And you can see it displays the time to exactly the same as what we saw with the other popup. But I want you to look at this carefully. Look at all these little resources very, very carefully. And if we move along network calling stack, look at all these resources being loaded. Take note of what it looks like. And you got it. You need to show you something pretty. 7. Time bards - 3 things to watch out for: What I wanted to show you is that with network requests, you're going to be seeing a lot of different things, but I want to break down the three most common things you're gonna see. You're gonna see stacked requests. And if I just draw this up for you, we know that the timeline goes from left to right in terms of milliseconds. And this is what a stepped request looks like when balls or stat. And by that I just mean a line on the left-hand side. This just means that the requests started at the same time. It's common for browsers to have multiple open connections to receive requests in batches. So you may see that your waterfall chart looks like a set of states as you scroll down the view. And that's what we saw before. The second most common thing you're going to see are long requests when Basel along and by long I just mean in length from left to right. This means that the request took longer. So it's intuitive, right? That a common mistake is to see a big long bar in your timeline and think Jesus is taking a long time, but bear in mind that long bar is only relative to the other bars near it. Semi exceeds. The timeline adjusts as you scroll down. So long bar that you see early on in your list of requests may not be as nefarious as it seems. Okay, but we're going to be seeing this later. Don't worry, just bear in mind that a longer bar does mean that relatively deck resource took a longer time to request. And last but not least, also see gaps. And when they are long gaps of space between bars, this just means that no requests were taking place at that time. Why? Will remember we've been through JavaScript blocks, DOM. So often cases it's usually because JavaScript or some other process was happening on the page. And that's why there's a gap. And this concludes the lecture. I just wanted you to understand some of the things you're gonna be seeing very often. Because otherwise you're going to be looking at these things and you're gonna be scratching your head and pulling out your hair. And I don't want that. I want it to be very intuitive and very simple. Great. I'll see you in the next lecture. 8. Breaking up time: Well, there are surprise you by being the side of the screen. Maybe, maybe not anyway, remember when we looked at the timing of a particular resource by hovering over us, Nokia, what do all these things mean? We've got queuing, we've got stalled, we've got waiting, TTA AFB, TTF-1, TT FB. We've got content downloaded, we've got all these different timing aspects, but it can seem very daunting. And what does the screen colored bar and what's the blue? What do these mean? Don't stress of gut your bag. We're going to look into this right now. Let me show you. 9. Time phases explained: You can see in the background, I've just drawn something up that our hope is very intuitive to explain what all these time phases mean. So sit back, grab a coffee and enjoy. Let's get into it. There are many different time phases that we just saw in that pop up. But I just want to break down the most common ones that are going to cause the most issues for you. And the most common time phase you're gonna see is queuing, meaning that your request is put in a queue. It has to wait, it has to wait in a line. And as I mentioned, this is the most common issue and there are a few reasons that our request could be delayed at this stage. What are these reasons? Law? Number one, it's postponed by the render engine. In other words, the request was postponed by the rendering engine because it's considered to be of low importance than other critical resources, such as your CSS style sheet or your JS file. This often happens with images on your page. And what's another reason why your request might be put into the queue, might be put on hold? Well, sometimes the request is put on hold in order for the browser to wait for a TCP socket that is currently unavailable. But that is about a free app. And I remember we went through the whole process. I think it was in section two where we discussed how the browser request to server out has to open up a connection nowadays to transfer data over protocols. This is what I'm talking about. Sometimes the browser has to wait for a socket open up in order to actually freely use it. And another reason is that sometimes the Q indicates that too many resources are being retrieved from a single server or domain on HTTP one or 1.1, Chrome enforces a maximum of six TCP connections per host. So if you've got a lot of files and these all used up, you will actually have to put that resource into a queue in order for this TCP connection to open up. Make sense, right? What else does the cute indicate to us? We'll request being cued can sometimes indicate that the time is being spent on making desk cache entries. But typically this is not a very big problem because usually this is super fast. So the question we are asking is, how do we fix a long queuing problem? Well, the easiest solution is to remove order for unnecessary requests so they're critical requests can download earlier dir. But you can also implement domain sharding. This is a bit more complicated. A basically means making multiple subdomains on your application to serve resources from. We then split the resources being served evenly among the subdomains. But this fixed is not that great because the fixed for HTTP one Connections does not apply to HTTP two connections. This is an important point if you are using HTTP two do not domain shot because it works against how HTTP two is mean to work, or why is this the case? Well, with HTTP two, there's a single TCP connection. The server that X has a multiplexed connection. So what does means is that with HTTP two, there is not that limit of six TCP connections for any given site. And what's awesome is that multiple resources can be seen through that one connection. But that's if we using HTTP two, ok, so don't use domain sharding with HTTP two. If you're a bit confused, don't stress, I'm going to be talking a little bit more about HTTP two and our bonus sections coming up. Ok, let's continue the lecture. Ok, so that has queuing. You're gonna see a lot of queuing, a lot of your resources, stacking up queuing. What about stalled or blocking? Well, sometimes you request can be waiting for any of the reasons described for queuing plus any time spent in proxy negotiation like man. But what is proxy negotiation and how is this different dequeuing? To me, it seems so similar to cuing. So what differentiates stalled and blocking versus QE? Are you confused? Well, so as I and so are a lot of people who, Okay, well, the answer to this comes down to the developers at chromium. What is chromium? Chromium has just Google's open source web browser Project. It's a fully functional browser on a dime, and it supplies a lot of the code for the Google Chrome browser. If you go onto the chromium developers website, any search Willis, who took me awhile because I was actually pulling out my hair, trying to figure out the difference. And you can see that the developers say that there is actually no significant difference between our stored enqueuing ranges. Okay, it all comes down to this proxy negotiation. So if you're waiting for a soccer to become available, then they call it stalled. If some proxy negotiation happened and they just call it cueing if no proxy, your SSL work was required and that's the only difference. So I view queuing and stored and blocking as very similar things when you start seeing these on the on that time bomb. Quick cut. I just don't want you to get lost in all the detail. Sometimes we stand so close to the wall, we can't see the painting. So take a step back because I understand what it is we're trying to do. Remember, we're looking at each resource on our website and we tried to decipher the amount of time it takes for that resource to be fetched from the server and also executed. And that's what we're doing here. We're just breaking up the different time components at that's taken. And we try to figure out how to optimize each step. That's all we're doing. So yeah, just wanted to quickly cut there just so we don't get lost and confused. It's continuous. Remember we saw Waiting better. Ttf-1. What was TT FB? What is it and what is content download? What do those mean? We'll just look at equity. Gtf be just stands for time to first byte. Basically it's the amount of time the browser needs to wait to start receiving data from the server after making an initial request. So during this time, TT FB, the server does would ever work, is required to return the request resource. Well, what does it look like? Remember, we saw these bars. Tt FB is represented by that long green bar. It basically captures the time taken of a roundtrip to the server. Did you know in a typical API request, this is where the majority of latency occurs. And for this reason, this is usually the step that developers have the most control over optimizing. But remember we mentioned these also a content loaded aspect of the time. What does that will contin download is the amount of time it takes to receive all the bytes from the server. After receiving the first byte. Remember that green is the time it takes to receive the first byte. Make scenes. Blue is the time it takes to receive all the bytes. And this is quite an interesting distinction with the green bar. Ok, we tried to optimize the point in time that the browser receives the very first byte from the server. But what about the blue bar? The content down at? What about that? Or latency here is mostly dependent on network connection speed. But obviously optimizing for smaller resources were reduced time in the step as well. But just bear in mind, a lot of their blue will come down to the network connection at weren't come down to actually your front end or your code on the browser. Okay, so how do we fix a slow time to first byte? Remember, the server response time measures how long it takes to load the necessary HTML to begin rendering the page from your server. So a slow TTA FB means that the request spends a long time waiting to receive the first byte from the server. But how do we fix it? Well, in order to fix it, we need to identify what can cause it. And the two main causes. One, you can have a slow network connection between your browser and the server into you can just have a slow server and enough already, how do we fix it? Well, firstly, you must cut out as much network as possible. One idea could be to host your website locally and see if there's still a big TT FB. If this fails. So if the TT FB is still large, then your site needs to be optimized for response speed. This could mean optimizing database queries, implementing a cache for certain portions of content on modifying your web server configuration. There are many reasons a backend can be slow. So you don't have to do your own research into your software and figure out what is not meeting your performance budget, okay, so up until this point, what you've done is you've cut out your network as much as possible, right? And you hosted your website locally to see if there's still a big TT FB. You noticed our men, the installer TT FB. And that's where we've got a optimizer database queries and implement caching, et cetera, et cetera. But it's quite an issue. But what about if you take it off your network, you host your website locally, and then it fixes your TT FB problem. So that works. What happens then? Well, then the issue is the network between your browser and the server. And unfortunately there's not a whole bunch of touch points between clients and servers. So the easiest solution is just to host recites somewhere else and see if that improves the TT FB. What about a slow content to hammered? Remember that the TT FB is the time it takes for your browser to receive the first byte from the server. Your content download is then the amount of time it takes to receive all the bytes from insert. There are two main causes for a slow content Dharma. Either your connection between the client and the server is slow or there's just too much content being damaged. So to fix the problem, just consider hosting your content on a CDN. And we're gonna be getting into what this is later or changing hosting providers. Basically, we just want to seeing fewer bytes by optimizing your requests. We are cruising through this and we are just about done. What are some other time phases that we need to be aware of? All these quite a few. We've got DNAs, lookup, initial connection and SSR, and these are kind of self-explanatory. They just show the time spent in these respective parts of the request lifestyle. Requests st is another thing you'll see an S, the amount of time it takes the browser to transmit the request to the server. So this step is usually super-duper quick, since it represents only the amount of time it takes a browser to dispatch the request, which is usually very, very fast. Okay, I really hope this is going to help you. It's been fun for me to put it together and to try and break it down as simply as I can unearth, cancel, overwhelming, but don't penny, you'll get to know these things over the course of your career and you don't have to fully understand everything on day one. But for now, at least when you start looking at these things, you'll have a basic idea what they mean. And it's fun. And I'll see you in the next lecture. 10. What is a CDN : What happens when we get a large blue bar on it that it looks horrible, right? And remember, this means that the content downloaded has taken a long time. And one of the ways we mentioned to fix this in the lecture was what? That's right. We see that we can use a CDN if you have high volumes of traffic coming to your site or you expect them to be high volumes coming to a science Damon heading CDA. And this isn't the way to go to make your website untouchable. But most people don't understand what a CD and they don't understand what impact it can have on the sides. But even if you don't want to use a CDN for your specific side, no matter what you do or what content you're consuming, could chances are that you'll find a CDN behind every character of text, behind every pixel of an image, and every movie frame that gets delivered to your PC, your phone. So what exactly is a CDN? And while they used? Well, in order to understand why they used, we first have to understand the problem they solve. Sign up The me, show you what problem they solve. Well, firstly, what is a CD in? It just stands for content delivery network. And at its most basic level, it's just a server that delivers your website's content for you. But it's not your original server. As we'll see, it's actually a third party proxy server, but we're going to be getting into that. Let me not jump ahead. Understand the CDN behalf to start with the term latency. Latency is that annoying delay that occurs from when you request a web page to the moment it's displayed to you. And this delay, this latency, it's affected by a number of factors. And many of those factors are specific to a given webpage. But in all cases, the delay duration is impacted by the physical distance between you and that website's hosting server. And this means that physical distance is important when we try and reduce our latency. And of course this is with a CDN comes into the picture. As we will see, CDNs mission is to virtually reduce that physical distance. And by doing this, it's goal is to improve the site rendering speed and performance. So how do I like to think of a CDN? So let's say you've got an end-user and this end users in South Africa and just take an assumption and his origin server. So his main server that he serves on his website content is located somewhere in Europe. You'd agree with me that when someone accesses that website, a request has to be saved to the origin server all the way across the world to Europe. And let's say that whole ROM trip takes two seconds. Now this is without a CDN. Let's now introduce a CDN into the picture how that work. Well, firstly, there will be a CDN server, let's say it's North Africa. And now what happens? Well, now in an aim, Judah wants to visit a website in South Africa. The request doesn't have to go all the way to Europe. That request can go directly to the CDN server. And that round trip my take 1 second and just bear in mind in the background what happens previously as etcd and server will actually send a request to the origin server and it will cache that website's page on its own server. Does it make sense? That's kind of how I view a CDN working. You can think of a CDN as a whole system of interconnected web servers scattered all over the world, where the geographical proximity to the user is the main criteria in delivering cached web content to that particular user. So yes, we need use a CDN. Your content is distributed all over the world to different web service. And we've seen that this is done just so wherever the user is requesting a page from the shortest physical distance can be used in order to deliver that content to the user. And a short-term physical distance means that this lace lost in a daughter packed. It just reduces your latency and timeouts. Awesome. And this is why people use CDNs. But CDNs can come with problems. They're not always advantageous. For example, if you have a local websites and you've got users logging on in one particular town or area. You don't necessarily want to CD and you don't really want your content scattered all over the globe. In that case, you'll be happy to sit one server in the location is closest to the users. But this is not a course about CDNs, isn't? Maybe actually it's quite a good idea. Maybe I should do what CD8, but for now I just wanted you to get a high level summary as to what a CDN is because we did mentioned in a previous lecture that one of the ways to optimize your content downloaded event, remember that blue block. One way to reduce it is to use a CDN. So I hope you found this useful and I hope you are enjoying this course. I'll see you in the next lecture. 11. Closing Comments: On second thoughts, I think we should stop here. I know it's a relatively short class that you've seen the Network tab now detail. And I really want to save the last class for something really exciting and that is on one just to get super, super practical. In fact, in the final class of this entire series aren't just a top bolding, read pages together and analyzing those pages as we add more and more CO2. So it's going to be super, super epic, the final class, the next class. Thank you so much for sticking with me. I hope you've enjoyed this one. I know I have audios.