*NEW* Speed Up Webpage Loading 2021 - Part 7: Optimizing the CRP & Site Audits | Clyde Matthew | Skillshare

Playback Speed

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

*NEW* Speed Up Webpage Loading 2021 - Part 7: Optimizing the CRP & Site Audits

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

15 Lessons (1h 3m)
    • 1. Class introduction

    • 2. Analyzing all network requests

    • 3. Network requests - overview

    • 4. How to analyze our simple page

    • 5. Size column (bonus lecture)

    • 6. Critical resources and server roundtrips

    • 7. Adding CSS and JS to our file

    • 8. Rendering our page

    • 9. JS and CSS effect on the Critical Rendering Path

    • 10. Inline JavaScript

    • 11. Async attribute

    • 12. Take a step back

    • 13. Lighthouse intro

    • 14. Lighthouse example


  • --
  • 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 7 we are going balls to wall - practical hands on examples of building pages together and analyzing its performance. 

Identifying and resolving critical rendering path performance bottlenecks requires good knowledge of the common pitfalls. So in this class we're going to build a simple web page together, starting with only HTML and then adding CSS and JavaScript. Along the way we will analyze the performance. 

Finally, I then talk about how to audit your site using Lighthouse. Lighthouse is an open-source, automated tool for improving the quality of web pages. You give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page did.

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. Class introduction: Welcome back My dear Skillshare students who we have come a very far away revenue. We have been through many different glosses all centered around this topic of critical rendering path. How to deliver, how to analyze and deliver a foster user experiences. A lot of resources that have to be fetched from a server, rendered by the browser in some way and in pixelated onto screen. And we've discussed this entire process, but up until now it's kinda largely been theoretical hasn't. And that's why in this class, I want to be purely practical. In fact, I want to start building web pages with you. And they don't want to start analyzing the COP. I want to dig deeper into which resources have been fetched. And of course, looking at the time, how long each resource is taken, and how to identify bottlenecks and how to fix them, and how to optimize a website, because you are not both know, an optimized site leads to greater conversion, better user experience, and effectively more dollars in your back pocket. And you know, as they say, all good things come to an end. So this is going to be the last class in the series for now. But really we've come a long way. You've come a long way. And I hope you followed me through all these classes because they all build upon each other. So here we go. Let's be practical. That's a lot of fun. And I'll see you medea students in the very first lecture are called white. I really can't. In fact, I'm going to go there right now to my PC and I'm going to stop, sign up. 2. Analyzing all network requests: All right, I think your final reading, we have come a long way and now I want us to start building in which sought to get it and use it's going to be very simple disposed example actually don't want to have any CSS, don't want to have any JavaScript. And I want you to just see how I start analyzing wave signs. And I know this is a simple science. We're not gonna go into complicated code in a recent full deck is you need to grasp the basics before you start analyzing more complex websites. And when you start building your own websites, you can start analyzing these things yourself, which is what this course is about, and trying to equip you in order to DH that point, would you feel comfortable analyzing your own websites? Hope you find this section we're going to be really going through in detail now. And what happens in the background we are going to be looking at if we set request, it goes through the files that come in, what the boss mean. We're going to be looking at the waterfall chart where we see gaps. I'm going to explain why they happen, the cetera, et cetera. So get a coffee waste mind. Oh, there it is. I also have a coffee. I have to kinda pump myself up as well. But I'm really excited for this section. So let's get into it right away. I'll see, you know, as I mentioned, Let's start with a very, very simple index.html file, no CSS, no JavaScript, and bear with me, I'm doing this for a very particular reason. We're going to start building it up. Again. I said at the beginning, it's creates a very, very simple HTML5 document. And let's just say the title is critical rendering path, no, CSS and JavaScript. So a very simple, we can have a paragraph tag that just says hello. We can have a span tag that just willed and we can have an image. Now, we can just put this image within our folder or we can go in and featured image in our case, I'm just going to do that. And I'm going to use Place image and the URL is just HTTPS image. Now we can also specify the size of the image we want. So let me do that. It's just specify size of RNN 640 by 480 in a can be any imagery. We can have alternative texture image placeholder, just good practice, I guess. And that's it. I told you it was going to be a super simple side. So this is let me just remove myself now because I want you to start seeing the neighborhood pal, and I don't want to be in the way. Let's now render our page. So there you go. Very simple, hello world. And then we've got this large image. Now let's just inspect all document. Let's go to the Network panel and you can see the network panel is blank and that is we have to reload, right? Remember, now if I just reloaded the page, normally this image would have already been cached in the browser. So what I wanna do is I want to hold down my mouse and I want to empty cache and implement a hard reload. So let's do that. And voila yeah, is outside that before we move on and before we start discussing what all of these things mean, what are these five files? You can see at the bottom that our scientists actually implemented five requests. What is this about? And while they 5 requests, if we go back to our code. Arrow quiz would you expect to see, well, the fish requests would be for the index.html file. And they not expect the request to be for an image. So I'll expect it to be too. I'll say 10. We can see that we've actually got five requests. Why? Well, let's start at the top so we can say our index.html request, that's absolutely fine. And if we hover over it, we can see that the request is enough CLP folder in next one dot HTML. So it makes sense. This is exactly we would expect it if we go back to code and I look at the folder structure, we've got a folder called CLP with NCLB, we've got index one, which is what we've randomly. So that's what that is. That's simple. We've also got this image tag. And you can see the source of that image tag is HTTPS place image.com, which is awesome because that's exactly what we specified in our code. What does this W case? What does that? Well, this is actually a WebSocket. This relate to the live server that we're using in order to display in real time. I'll wait page Oh, Clyde Hill, why do we even need Live Server? Why couldn't we just drop the file into this page and just work with it that way. Then we don't have to deal with the live server. And you're a 100 percent great. You don't have to use a live Zoom. But let me show you what a does to see you know, why I'm using the other two main reasons I use Live Server 1, ajax does not work with the file protocol, meaning that if you've got JavaScript in your code and that JavaScript is pitching files locally from your machine. Ajax will preclude you from doing so, which is why we use Live Server. This second reason I use Live Server is to implement live refreshes. Let me show you what I mean. So if I push this page to the side and we've got our code here, and just get rid of that. And I put that to the one side as well. If I go Hailar, Wally, rotten, and let's just, let's just move this here. And honest, save this file. I don't refresh my browser. I'll just say this far, look what happens. I've saved and bull. Hello, wanting is displayed now to screen. Cool, right? It just shows you that it's dynamic when on Save and any change the file happens, it automatically refreshes and reloads the browser and it just saves me time as a developer. And what happens in the usual way, but didn't use Live Server will let me show you. So we can actually view this index one file in our Explorer inheritance. All I have to do now is double-click on index one. But now this is served from my file directly. And how do we know that? We can see the protocols using is the file protocol that's not a server. Whereas if we go to a live server, we can see that it's actually serving from a server. But anyway, so now we're onto our file protocol. If I now mean this page, hello molly, to and as safe, what's going to happen? All just as I told you, nothing's going to happen when we using the file protocol for my machine, I shifted go into here and I have to refreeze only beam does it updates. But if we go to our live server, it's automatically updated. Gcc, I haven't even had to refresh. So that's one of the main reasons I use Live Server. Okay, let's get back to where we were led me with this because we don't want to use that. Approach. Me, just make this a bit bigger again. And now I just want to reload this page again. Because you'll see here we've actually lost at favicon request and epsilon explain more. So I'm just going to click on this refresh button and I'm going to Empty Cache and Hard Reload. Okay, so there we go. So we discussed index1 HTML. We discussed the fact that our website has to go and fetch that image. We then got onto this WAS this wheat socket, and we see that this relates to a live server. Well, how does the live server actually work? Live servers actually a Node app that serves your main directory. And as we've seen at watches for changes in your file. And as soon as a change has occurred in your file, it then scenes and message through a web socket directly to your browser, telling it to reload. How does this all work in ways the code coming from? Well, in order for live server to actually work, it has to inject code into your file. How do we find this extra code? Well, it has to be in our HTML, doesn't it presents what we serving it? So if we click on our HTML file and we click on the response, look at this. We've got the top section, which is our code. The day we've got this code injected by the live server. You can see that it's JavaScript. And the JavaScript establishes a WebSocket connection and it listens will change as we make in the file. It'll look to instruct the browser and refresh. Great, So let's remove this. And I think we've had enough talking about the WBS. You can just ignore that actually because that's all happening from our live server. It's not asked individually. We've then got this in G validates dot js file. And if I hover over there, we can see that it says, yeah, it's a Chrome extensions, so that's your first clue. It's an extension that I've actually added onto my Chrome browser. And I just happen to know there's a stroma all glory extinction is just a tool that allows you to debug Angular application. And I can even show you where it is. If I go into my Chrome settings, should be able to see extinction some way. Here we go. And the area is the strongest organ, extinction. Again. So again, you can ignore that for our purposes because we know in a validator j's is not us. It's coming from an extinction. And then we've got this final favicon dot ICO. What is that? Well, firstly, this is being done behind the scenes. We haven't implemented in your request or fabric on WIC. The browser does this automatically on every single website you visit. And what is it? Well, it's actually the law icon that's displayed to the left of the title of your website. Can you see at the very top, yeah, there's like a default wold Mac kind of icon. If we wanted our own one, all we would have to do is put a file, image file in our main directory called favicon. But ICO, if we hover over this civic 100 ICO, we can see that it's trying to fit a file from a main directory where it all begins, not even the CLP directory, one directory or folder, the main directory or a file called favicon dot ICO. So let me show you how that would work. If we go to our actual code editor. You can see I've got a favicon dot icon India, which is just an error. I can't just nothing special. But I've put it within the CLP folder. It needs to be in the main directory we'll serve as being served from. So if I just take this favicon icon out, let's move it. Now if we implement a Hard Reload, look what's going to happen now. Boom, we've actually got that cool little arrow in the top left corner. Can you see it? So that's what the federal funded ICO is. Who who have done a lot, haven't we and we haven't even got onto talking about the files in the current time elements and what the gaps mean and what the different ha, how we can improve this. But I wanted you to go through each single file because I don't want you to be intimidated by all these neat with replaced and you know, the first thing you might have seen when we land on this page is that do have five requests and you might have started feeling intimidated and that's why I wanted to bed for every single file with you. Just so starts making more intuitive and see. So I think this is long enough for this lecture. What I'm gonna do is I'm actually going to quit this. I'm going to shut down page and then the next lecture. What I want us to do is I want us to reload the simple website up and I want us to start looking at the different time elements of each file. And I want to start just wrapping your head around what I look at when I try and assist the critical rendering path. So I'll see you in the next lecture. 3. Network requests - overview: We've seen exactly what each request is in the network panel, the gradient radius system performance of this specific file, which is what we're gonna do not so Xiaomi on a coding editor, this is what we cut it up together. And let's just fire it up and then let's assist the performance of this. So now we're going to fire up our live server. And then we go to these, I'll hello, Juanita is our world and the image. This should speak the document. It's good to unmake drip tab. And yes, it's blank. We have to refresh and I'm going to long click the Refresh tab and I'm going to Empty Cache and Hard Reload also. So this is what I wanted us to look at. Take a look at what's happened. Let me actually expand this just a little bit more and have a lower what can you notice will firstly, we can see they were five requests. We know that the index file, the image file, we've got a live server which establishes a WebSocket connection. We've got the AMG validate, which is just our old Greeks danger and in Google Chrome, which is just personal to me. And then we've got this favicon dot ICO, which the browser makes a request automatically. So we know this, we went through this loss nature, but let's talk now looking at the performance. Let's look at our index file. Can you notice something about the size? Why? Why are the two different sizes? Remember the top size to 2.2 KB. That's the original file size. And the size below it is the one that has been compressed for you. And I haven't done any compression. We haven't defined all of that in the backend. Have we know that What's awesome is that all modern browsers, except the gzip encoding type from the server. So this means a kind of happens automatically. In fact, your browser has even put it in the request header that it accepts Jesus from the server. Don't believe me. Good. It was voiced tasty. So if we click on our file and we look at the haters and we go to the request hidden. We can actually see yet that you'll browse a is automatically inserted in except Jesus encoding top. Now there's a lot happening on this page. We've got this blue line, we've got a red line. We've got the whole bottom section. We've got different files and different things happening. I mean, if we zoom in on this index file, for example, you can see these different colors here. This white, gray, green, and blue. What all these mean? Well, let's jump over and let's discuss all of this. And let me just zoom. I'll chat game. You can see a very high level bird's eye view of your entire process. So let's jump into exactly what's happened yet. I'll see you now. 4. How to analyze our simple page: What can we say about our index 1 dot HTML file? And to remind you, this just has all HTML and an image. There's no CSS and there's no JavaScript. Let's just look at the waterfall for our index 1 dot HTML file. And before we discuss this in detail, what does colors mean? What is relatively simple? The white and the gray represent us waiting on the network and initiate the request. And the green and the blue or any other colors, debts the time spent waiting on server and processing. The bytes. All colors other than represent the length of time that the browser has to wait on the network without receiving any response bias. And what's its solid blocky day? What does that mean? Well, we've looked at this before. I'm a mess the content download. It basically shows the time to finish the DOM owed after the first response bias had been received by the browser. Yeah, I'll HTML download is tiny, brought literally 1.9 KB. So all we need is a single round trip to fix the full file, which is why that blue it'll tab is very small. So ordinarily out expected file to be very quick to fish and raise it to the screen. However, we can see here that it's taking 300 milliseconds out, expect us to take roughly about six milliseconds full thereabouts. So why has it taken? 300 will learn the reason I can think of novels that we running a live server, we implemented a Hard Reload Empty Cache and will they just takes time. But if I had to do it again, that probably would be a lot lot quicker. So here you can see three-quarters of all time was spent waiting on the network, implementing it Hard Reload. And the other quarter time was spent on the server response. And then what happens next? Do you remember? Well, when the HTML content becomes available, the browser has to pass the box. Her maybe convert into characters, two tokens, and then it pulls the DOM tree. And noticed that div to us conveniently or post the time for the DOM content loaded event at the bottom of the screen and you can see, yeah, it was 380 milliseconds. And 380 milliseconds also corresponds to that vertical blue line that we saw on the screen. So same thing. Before we end this lecture. There's just one question I want to ask you first and I want to see if you can get it before he did the onset. And that is what is that gap between the aim of the HTML DOM and the blue vertical line that DOM content loaded event. What does it time represent? And it's not a trick question. Think about a deck get is just the length of time it takes the browser to bold the DOM. That's right. And usually this process is very, very foster. The day you have a touch. Just wanted to point that out before we moved on to the next lecture. 5. Size column (bonus lecture): I know we've discussed this before, but I want to go over again the size column. In other words, I want you to understand you'll file sizes. Remainder b should be compressing your resources. And we do this to speed up the download time. And we know that to Brazil and compress them once they are received from the server. And luckily for us, we have the ability to view the uncompressed size of each resource. So yeah, we are just going to stack overflow.com and we can see the size column name. It's 23.9 KB on the top and 103 KB on the bottom. So we immediately know the size column shows two values, the top value and the bottom value. And we've seen this before, but just to remind you that top Valley shows the compressed file size that was sent over the network, and the bottom value shows the uncompressed file size. So in our example, the compressed file size is 23.9 KB. And I know we went through this in a lecture. I just wanted to reiterate it because understanding you'll file sizes in optimizing that as normally a very, very good starting point in order to speed up your page. 6. Critical resources and server roundtrips: What else can we discuss about the index 1 dot HTML file remainder, and we've got HTML in this fall and requesting an image. This Nursia season is no JavaScript. Well, one thing we haven't discussed yet is our image. Notice that our average did not block the DOM content loaded event. As it turns out, not all resources are critical to deliver a phosphate system paint. But this isn't all peace, love groovy because the image has blocked the load of int, that red vertical line has to wait until the image is fake. Why? Will remember that the onload event marks the point at which all resources that the page needs had been downloaded and processed. So at this point, the loadings in your browser, you know the little thing that goes round and round, they can stop spinning in the browser and in the red vertical line and the waterfall can display. And don't take this for granted. You've just learned a very advanced topic. But before we finish, I just want to drive the point home by painting a slightly different picture, but that shouldn't solidify what you've just learned. And it all begins with the browser having to initiate a request to go AND gate that HTML file and has to wait for that HTML file to arrive at as to the impulse that older DOM. And then finally it can render it to the screen. And we know when it is requesting that gate HTML file it is render blocking has to be rendered blocking. In other words, the browser has to receive that file in order for it to construct the DOM to display onto the screen, it makes scenes. So HTML mockup history render blocking, that's obvious. When that file has been received, the browser will stop parsing the file, rot, and then we'll get to that image tag. And then of course, it has to initiate another engage request for that image. We've just seen that image is a non-random blocking resource. So what that means is that it doesn't have to wait for that image to be returned. The browser can still construct the dominant. The time between t0 and t1 captures the network and server processing times in the base case. In other words, if the HTML file is small, just one network round-trip reaches the entire HTML document. And just due to the nature of how TCP transport protocols work, larger files may require more round trips. I hope this image on the screen is starting to make scenes do badly me not get ahead of myself. What we're trying to show you is that when that HTML file is received by the browser, it can stop bullying the DOM immediately. It doesn't have to wait for that image. And of course, when the Domus finished, it can render the page. And when the page has been rendered in the background, that image rule of being sheet return a response and that rendered page we updated the painting process will then occur again and are painted image to the screen. We are done. I hope this makes sense. I hope assigned to sink in. But let's now start getting more creative. Let's start adding CSS and JavaScript. I'll see you in the next lecture. 7. Adding CSS and JS to our file: How's it going? Good, as you can see, it has my coffee, keeps me going. Keep going. Most people can handle it, but it's nice to see you. Yeah, So well done. And you'll remember in the previous lecture, we looked at a very simple file. We innovate. It doesn't have any CSS, nor do we have JavaScript. But as you know, in practice, will need more than just HTML. Johnson saw wool him differently, need to add a style sheets and we also need to add JavaScript, full sudden interactivity. So why don't we add Buzz? What we're gonna do not but first, a quick sip of my coffee. That has a really good. Okay. So yeah, if you just look at our folder structure, you can see we've got our CLP folder just stands for critical rendering path, and we've got this favicon, but ICO, remember the browser makes an automatic requests to go and fetch a file from your absolute root directory and display it as UDL icon in the top left corner. That's what they fed appoint honest. Now, this just creates an index to file. I've already created just blank files already, just to save us time. But you can see nothing's in it and it's not coding. So let's create a very simple HTML5 document. And it's tied to that critical rendering path. But in this case, we're going to have CSAs plus an external JavaScript file. And why did we have it the same as last time? So we have Heller, we have a span tag that says wold. And let's include an image. And again, let's use placed image to request this image from. So it's HTTPS. We know this place image.com industries use the same size we did last time. So 640 pixels by 480 and it can be any Punjab. And for alternative text we can just say random. So here we go. This is kind of what we had last time. If we just read through this to the screen, we can see how old and Neizha picture nothing spatial. So now let's add a CSS. Links creates a link to a style sheet. So link tag and let's call our style sheet style.css, styles.css, and we'll have it in the same root directory as I'll CLP folder. If we open up our folder structure, we've got our style sheet that I've set up yet and cooled style. Let's just change this to styles because I used a plural. And here we go. Let's just add a few styles to the sides. And this isn't a course about a beautiful designed website. And I'm just trying to prove the critical rendering path performance and how we go about looking at it. So it is going to still look ugly, but at least we've got some CSS. Let's take our span, remember that in world and this, just hide it. So we'll take our span tag, we'll display, and we'll display none. And let's just make the color rate because what we're gonna do an our JavaScript file is I just want to redisplay it so you can see that the JavaScript is working. So that's our span tag. Let's now just working on image a little bit cool. Just make that display top of A blogger. And let's just put a margin at the top of two. And we'll do on, on the bottom as well. There you go. So you can really see this a bit more of a margin at the top and the bottom of this image. And lastly, let's just take our paragraph tag and let's make that the Calabria. They say hello is in blue. Very simple. Lost, but not least, I want to add JavaScript. Where do we add our JavaScript will remain with a mini places we can edit, but I'm just going to stick with web site 101 and put it at the very bottom. And let's include a source attribute and refrence app.js. And if we look in our folder structure, we've got a ab.js, but nothing's in there. So let's just quickly draw some JavaScript. First thing I wanna do is I want to access Alice span tag. And I want to exist browsers in the bolt document get elements by tag name. We want to access the span. And of course, static returns a node list, which is why we have to access the first item in that array. Now we've got all span for my MBA and I'll style sheet. We hit us. Let's display type as none. But in the app.js, I'm wanting to display. So here I'm actually getting that span element and the now and change the DOM taste of the span. How do we do this? Well, it's relatively simple. All we're doing is we're going to access the span tag. We're going to change this in the HTML property. And then we can just say, I've been changed by JavaScript. And remember, JavaScript can not only manipulate the DOM, but it can also manipulate the CSAs on how do we do this? Well, it's very simple at once again, and we've seen this before in the course. We exist to span element. We access knowledge style property and we can change its display property to in line. Now if I push Save the head, I've been changed by JavaScript. How awesome is this? And we've just did this purely by using JavaScript. And if we actually go to our index file, we can see how span has the word world, which we've overwritten by our JavaScript. And because we're having so much fun, let's just quickly add an element in JavaScript to this dome. So how would we go about doing that? Well, let's just have a welcome message like welcome one knee. And you can imagine we have a formula with the use of fools in the name and all that, but just the all lists don't get too complicated. So I'm going to define a variable called name, and we're just going to say that name B10. And then we can say display text. That's what we want to show on the screen. We're going to use template literals and we're going to say welcome. And then we're going to use the person's name. Okay, so very simple. Awesome. So now we have our welcome message and how we need somebody to display in a drought. Now stop being put anyway. So we haven't stored in JavaScript in these variables, but they are not being put in way on the screen. So let's create an element to put this into. How do we go about doing that? That's right. We are going to use the browsers in Bolton document object again and on Nate is a method called create elements spearing intuitive. So let's call our new div tag, new div. And we're going to access the document object and we're going to create an element. And let's just create a data element. Unless new div element, we want to include that display text, right? That's where we want to put it into. Sound. We can actually just access it, takes content property and make that equal to display text. And just to show that we can now also manipulate the CSS. Again, we can just access this new div. We can access it style property, and we can change its color. And let's just change this color to green. Now if we save this, you can see it's still not updating our rained and page. Why is that? Can you figure it out? Well, if we even inspect this document, let me show you. And we'd go to the elements here. You can see we don't have that data proc, we don't have that new does that div element that we've created that's not attached to the dominant. Makes sense because we haven't put it anyway. So that's what we have to do now. So the loss pot is having to take our document and a pain this new div to it. And it's super simple. We get the x's out document. Then we want to access our body element, which is weight loss. Html is inserted into. And then we're just going to paint a child and we're going to paint on newly created div. And if I save it, there you go. Boom Chaka, aka, we've got welcome Wally in green. And if we inspect this document, how awesome Zed, we've got our new div, Rochester. 8. Rendering our page: Okay, So now take a step back or on, let me just open up our website. Let me get down Network tab and let me do an Empty Cache and Hard Reload. Wise owl picture not working. I've lost internet connection hollow. Let me just reconnect. Okay, he's got Internet NA so let me try that again. Empty Cache and Hard Reload. They knew they could use a little dog. I actually funny enough that a Deshawn to be seeing on the sausage dog. I had those growing up in Zimbabwe. How cool is that? I used to love him. Anyway. And so he has our site is fully loaded on the screen. And just notice a few things. I mean, firstly, we've got now four main file requests, so you can ignore the WebSocket and the NG validate and a favicon for now, just ignore because we've got now for request, I mean index two styles, that image and our app.js file. And just have a brief look at these file requests. And we'll look at these three that kinda of five at pretty similar times on day. Have a look at those laws. Have a look at our DOM content loaded a faint, have a look at our load of eight. Did it sink in a little bit? And now I just want to hit over to the other screen and I want to talk about this in a bit more detail. 9. JS and CSS effect on the Critical Rendering Path: Let's look more closely at this index to dot HTML file. To remind you, we've got our HTML. We've got Deb reference to an image. But now we've also added a CSS file and a colt and external JavaScript file. Okay, so that's our index.html. And if I just take that screenshot we were looking at and place it on the screen. You can see that adding the CSS and JavaScript has added two extra file requests to our waterfall. We can see that the browser scenes, these three requests that dot CSS, the image and the JavaScript file at about the same time. Last, unlike our plain HTML example that we saw previously, we now also need to fetch and pause the CSS file to construct the CSS. And because of the JavaScript file, we know that the DOM content loaded a vein, has to be blocked and told that JavaScript file is executed. And we also know in order for the JavaScript file to be executed, the CSS DOM has to be fully constructed. Okay, but we know this. So let's just display the in time may quick request process. What happens? Well, we know the very first thing that happens is that your browser has to request this HTML file that it's the starting point of your entire arena process. Html has been fetched a response the same bed to the browser. And neck is the point in time where the browser can start building the DOM. So up until the request, which I've denoted here by T Zara, from that point all the way to T1, the browser just has to wait. There's a big gap in the waterfall. And that gap is just the time it takes for the browser to actually go and fetch and parse that HTML file. When it receives that file, that's when the DOM can start being bold. We know this, we've seen it. And now I just want to talk about the CSE is embed before we add JavaScript. So let's look at now how that works. Well, we know that at very similar times, if not exactly the same time, request is sent by the browser to go and finish a CSS file and an image file. But he has the interesting difference with the CSS file. We know that the browser has to wait for a response in order for the CSAs to be bold. So now we've got the render tree having to wait not only for the DOM to finish, but not also has to wait for the CSS on to finish. The good news is that once the DOM is bolt and the CSS almost bolt, then we know that the render tree is finished and the rendered page can be displayed to the screen and in the background as we saw in the previous lecture, the gate image of waste doesn't block the random process. So in the background, the browser can wait for that response. When it receives an image, it can then display it to the rendered page. Does that make sense? So then let me ask you this, looking at the diagram in front of you, how many critical resources do you think? That's the one question. Another question I want to ask is, how many round trips decent the browser needs to make it to the server in order to just render them minimum content to the screen. Okay, so let's answer the first question. How many critical resources are there? Let's take a step back. The browser has to request the HTML file first drive. So is that HTML file critical? Will, of course it's critical. Because without the HTML file in the first place, how the DOM navigate constructed. And without the DOM, you can never get to the render tree. So yes, the HTML is a critical resource. What about the CSS file? We'll yes, we need both the HTML and the CSS to construct their industry. So as a result, both the HTML and CSS critical resources. What about the imagery? Will know we've seen already that the DOM content loaded a vein can be fired before the image is even fetched. We even saw now examples at the page paint was done, right? The render tree was partially constructed. The folder image tag was fetched from the server. To answer the question, we've got to critical resources, HTML and CSS. What about the roundtrips? Well, the CCC can only be fetched off to the browser geeks the HTML document. Why? Well, think about it. The browser doesn't know all the files that you have in your code, in your mock-up. It's only going to figure that out once it's fixed at mockup in the first place. So it's first round trip is going to be to fix the index file. It's then going to discover a reference to CCS file. And when Ned us discovered another request is vital for the server to go and fix that dot CSS file. So two or more round trips or acquired in order to deliver those critical resources makes sense. Now what I want us to do is I want us to add JavaScript because we've totally ignored a moment, so let's do that. So again, let's start at the beginning, your browser makes a request to go and fix that HTML file. Winner responses issued, the DOM can start being constructed. The browser has to wait between t0 and t1. It just has to wait. What happens next? Correct? The browser fires off three GET requests. One fallacies is fall one for the JavaScript and one for the imagery. We know that that get JavaScript request is possible locking. So it's going to block the construction of the DOM and bear in mind. Yeah. I'm not talking about adding async and defer. I'm talking about the default scenario that blocks the parser. When the CSS file response has been given to the browser, we know the CSS can be bold and JavaScript has to wait for the CSS on to be finalized before it can execute. So once that CSS almost bolt JavaScript can then be run, which is denoted here by T3. And as soon as that's happened, the good news is that the DOM can continue to be constructed at go-go go time. And of course off the JavaScript is run. The DOM can finish being constructed, which means the render tree can be finalized and the rendered page can be finished. And of course, we still have this good image of waste running in the background. And when net responses received, the browser can then update the rendered page. Now let me ask you two questions. Again. One, how many critical resources are acquired now in order to construct the render tree, end to how many round trips to the server at a minimum, does the browser need to make? We need both the HTML and the CSS to construct the render tree. So as a result, we know that both HTML and CSS resources are critical in order to deliver the render tree. But now we also have JavaScript and we know that JavaScript is blocking, so the DOM cannot be fully constructed and told that JavaScript is executed. And for that reason, that file has to be a critical resource. So we've got three critical resources. How many round trips? Well, we can see that the first round trip has to be to fix that HTML file. And then as we saw on the very first screenshot, but the CSS and the JavaScript requests are initiated at about the same time. So the browser gets the HTML and discovers both resources, and it initiates both requests. So it's quite interesting, even though we have three GET requests, two of them are fetched at the same time within one round trip, depending on the size, of course. So outside that we need at least two or more round trips at a minimum. At the moment, you'd agree with edit an external JavaScript file. But what about if we add an inline JavaScript file? Do you think that would make any difference? Let's have a look. 10. Inline JavaScript: Okay, so how does inline JavaScript SDK, all of this, let me just hide myself so you can see the DOM content loaded and unloaded veins and on. You can see here the dom content owner took 1.7 seconds a load of in toxics point to and she seems very long. Let me just let me just hard reload this again. There you go. That's a lot better. So yeah, the DOM content loaded event took 200 milliseconds again and we enter weights almost four seconds for that image to be fully fetched from the server. Now, what happens if we use inline JavaScript? So let's go back to our Visual Studio code. All I wanna do now is I want to take the source gentle soul spectrum out. We can then go to our JavaScript file and copy and paste, copy and paste. And we're going to save. So let's go back to websites. When I'm abroad, this automatically refreshed from our live server. That's why you've seen 280 milliseconds, but we know that almost took was at full seconds, almost full sequence 3.7 seconds, somebody about the butt. Now let's refresh this and hard reload. And this is the very interesting thing that I wanted to get across. Now, this is inline JavaScript. So we can see first eat at one lease resources have to be fetched from the server, right? We've only got our CSS file now and I'll image. But look at the DOM content loaded event. It hasn't really been impacted at all. As we saw we making one Nice request, but both are onload and up DOM content loaded times are effectively the same. Why? Will we know that it doesn't matter where the JavaScript is in line or external, because as soon as the browser hits the script tag, it has two that's tried. It has to go through all the construction of the DOM and it has to wait until the CSS on is also first constructed before it can execute itself. And another thing is that in our previous example, we saw that the browser downloads both the CSS file and the jaws could fall in parallel, remember, at five of those requests at the same time. And they finished downloading at about the same time. So that's why in this instance, in lining the JavaScript code doesn't help us much that we've seen in this course. That they'll several strategies that we can use to make out page render foster. What about adding async? So external file, what will lead to, well, let's give it a try. 11. Async attribute: Her eDonkey, let's get back into it. So what I wanna do continuing from our previous example is let's just get rid of all this JavaScript with this just looks really messy. And let's add our source attribute, Beck India, which references that file. Again, wanna go to our website, yeah, and just take note that the DOM content loaded event is about 200 milliseconds. Okay, thereabouts. Now, all we wanting to do is we wanting to add async, right? What's going to happen now? Let's save and let's go back to our site and look at that DOM content loaded event. You all later. Quick has an answer. It's only now a 112 milliseconds. Amazing your eyes. And just jump to the other screen. That just a few other things I want to mention about this. We've now amended our index dot HTML file to include HTML, the reference to the image and external CSS file. But now we've added the async attribute TO external JavaScript. What did we just see? One, the DOM content loaded event fires shortly after the HTML minus cost. And why does this happen? Will, because we've used the async attribute the browser knows not to block on the JavaScript file. Day for the CCS on can be built in parallel to the dominant. And what does this look like? Well, it's going to look very similar to our previous example, the town we know everything can be done in parallel, which just shortens the time frame. We know request to seem to go and fetch that HTML file up until the point that is fetched the browser to assess, to wait, it has to snooze. When that responses received, the DOM can stop being bolt. The browser then fires 32 requests pretty much in parallel to fix the CSS, the JavaScript in the image. But the browser now reads that async keyword and it knows that it doesn't have to pause the DOM. Remember, when we looked at the previous example at this point in time, the dome was blobs, but now it's not blocked. Css ohm, and the DOM can be bolt in parallel, which is why the DOM content loaded and zinc can be fired at this point in time. And eventually the JavaScript file will be executed and the final rendered page can be displayed to the screen. And of course the image is still day. Then in the background, it can be searched when it's fetched, the browser can update the render tree. So going back to our two questions, how many critical resources all in harmony and roundtrips at a minimum are required in order to fetch and execute those critical resources. Well, we've seen that the script is no longer possible locking. So it's not part of the critical rendering path because they are no other critical scripts. The CSS doesn't need to block the DOM content loaded event. And y is the DOM content loaded with ain't important to remind you we've been through this before, but the sooner the DOM content loaded of in finance, the sooner the application logic can begin executing. So as a result, optimized page is now back to, to critical resources, HTML and CSS, with a minimum critical path length of two round trips. We have done a lot nano hope you are having fun and well done for getting this far. 12. Take a step back: Hey, hey, we've come a long way. So now I just want to give a high-level summary of what we've learned. As we know, this entire course has been predominantly around the critical rendering path, which is the process of displaying a webpage and taking a step back remain bat. The main function of a browser is to present the resource you choose. What do I mean by resource? Will a file like HTML, JavaScript, CSS, an image, a JPEG, et cetera, et cetera. And we now understand the phases in which resources are gathered over the network. We've literally started right at the beginning with making an ajax call. We then phage that file. We manipulated at content within, displayed it to the screen. And we've gone through the whole process of how that occurs in the background. So equipped with this knowledge, we can now fix load issues and improve our user experience by having fast loading websites. Before we discuss how we optimize the critical rendering path, we just need to understand what it is. We need to optimize Pangea. I've broken it down to deliver, fostering that we need to minimize three things. And I want to emphasize the word minimize. You'll never remove these things. We just want to try and reduce them as much as possible. One, we need to minimize the number of critical resources, such as HTML, CSS, and JavaScript. And don't get intimidated by these fancy words. Critical resource. Remember, a critical resource is just a file that could block the initial rendering of the page. The few of these resources, they are the least weight for the browser, the CPU, and other resources that make sense, right? We need to minimize Server trips and paths. Ie, how many trips to the server do we need? The critical path link or the number of server trips and pause is a function of the dependency graph between the critical resources and the bite sizes, and we've seen it, some resource downloads can be initiated off the previous resource has been processed. And the larger the resource, the more round trips it takes to download. And of course, we want to minimize the number of critical bites. Take a the size of your files. Remember the fewer critical bytes the browser has to download. The foster it can process content and render it visible on the screen. And how do we do this? Well, to reduce the number of bytes, we can reduce the number of resources. So we can either eliminate them, but often we can't really do that. So you just make them non-critical. And we can ensure that we minimize the transfer size over the network by compressing an optimizing each resource. Cool, I heard this makes scenes. So those are the three high-level things we always want to minimize. When we went to improve our critical rendering path. We want to reduce the number of critical resources. We want to reduce the amount of server trips. And of course, we want our file sizes to be as low as possible. So that's what we want. But how do we get there? Well of outlined a few steps to take to optimize your critical rendering path. And they should be very intuitive by now. One, the starting point has to be analyzing your critical path. And we've been through examples of this where we had to look at the number of critical resources, the Pott linked, we looked at the sizes of our files, what requests are being made. This is the starting point to go through. All those files, would go through all those requests. And we reduced the number of critical resources. Sometimes we want to add defer until JavaScript files, sometimes async, sometimes we can remove certain files. That step number two, step number three, we want to reduce our critical bias, our file sizes to reduce the dominant, tonic. And oftentimes we just use compression. And the most important thing when delivering a website a user is that first paint, which brings us on to step number 4. And that is we want to improve the order of resource downloads. In other words, we want to optimize the order in which the remaining critical resources are loaded. So we want to download all critical assets as early as possible to shorten the critical path length. And as you can see, there's not much to us. And we've been through all of these sticks together. Yes, we used a very simple example, but you need to start there. And once you start coding your own websites, it's going to feel so much more alive and so much more intuitive. So I hope you've learned a lot, but we're not quite done yet. I'll see you now. 13. Lighthouse intro: Okay, so well done for getting this far seriously. That's so awesome. Ended up until now we've kind of, we've kinda of hectare way through analyzing our website. And I did this for a very specific reason. And it is in order to understand, in order to truly master something, I really am a believer in having to understand the basics. You've gotta go back to the fundamentals, which is what we've been doing this whole time. We've been analyzing our own science from scratch. We started off looking a lot at the performance penalty in div Chrome tools, and then we switch to the next panel when we started analyzing each resource. And it's been awesome. But they are more efficient ways of doing this. In fact, we've got tools available to us that literally help us analyze the critical rendering path. One of these tools as ordered like us. So let's jump in and see what that's about. What is the audit light OS will at its most simple as just a free automated tool that analyzes your critical rendering path. So ordered lighthouse approach runs automated tests and then it generates a report on the pages COP or critical rendering path performance. This approach provides quick and easy high-level overview of the CLP performance on a particular page loaded in your browser and allowing you to rapidly test, iterate and improve your pages performance. So in general, a good approach is to use Lighthouse to just identify at least obvious CLP optimization opportunities. Okay, Clyde, I get it. It's an awesome tool that hardware accesses. While they a few ways you can access this tool, you can use Lighthouse and Def tools which we in undo. You can also use it in the command line or even as a node module. So in many ways to skin a GET but not enough talk, let's jump into lighthouse and see how it works. 14. Lighthouse example: Okay, so let's look at this ordered lighthouse and I'm just going to use our previous fall. We had Yao index.html and nu. Remember we just have an image that we fetching from Place image. We have our style sheet, and we have our simple app.js file. Okay, so let's fire up our live server. And here we go. Nothing new. So how do we access this audit lattice will firstly, let us access our div tools. And surprise, surprise. You have to click on this audit tab in order to get to this functionality. So let's do that quickly come audits. And the first thing we see has just a list of sittings. For example, we can specify what device we want this report to be analyzed on. All mimic. We've then got what ordered to once I'm just going to click on everything so you can kind of see what report gets produced. And then you can implement throttling. Basically if you just simulate a slower fossil record, all we have to do now is we have to run this audit and then we just have to wait for the report. Let's do that now. Here we go. This is your first White House report with what does this all mean? Again? Well firstly, at the very top here you can see we've got this performance matrix. This is the overall skull that your site has received. Obviously the higher number, the beta. Yeah, we've got a very optimized site because there's not much happening. Let's be honest. But you need to understand the processes and what alders, which I'm going to go through in this lecture and this matrix section provides a quantitative analysis of your site. In other words, just an objective analysis of your site because they assign numbers to everything. For example, the first contain full page, tells you when content is first painted to the screen. Very intuitive, right? Whereas the time to interactive, that tells you when the page is ready for user interactivity. For example, in all your JavaScript is loaded and ready. So for example, when the user clicks a button, it needs to do something. So this is very intuitive. I don't really want to be talking through everything because having really, it really is obvious. But let's just scroll down on see what else is in here. What's quite cool is that you've got these frames, so you can kinda see the whole process it just took to load, which is quite cool at what points? Here you can see we can probably optimize that image quite a lot, but here we're using Place image. So we haven't really optimize that process at all. And then when we scroll down, we get to an opportunities section. And opportunity section is giving you tips on how you can improve your page performance. This is quite interesting and we already identified the image looking above here that the image takes awhile. Opportunities actually says, We need to serve images in next thing, formats and efficiently encode our images. We know we haven't done any of this because we just using Place Image, we're using a third party website to grab it from. We have no control over that. And then what you can even do is you can even open up the tab. Even gives you hints. So image formats like JPEG 2000 eggs on women often provide better compression than PNG or JPEG, which means foster downwards and least daughter consumption. And you can read more about it and we can try and optimize images and compress them in different ways. That's opportunity section. If we go down now we've got diagnostic section. And this just gives us more information about the performance page. And what's interesting is we can see that the critical request dips or pauses to ethno. Remember we discussed this one of the lectures. We said that they were X amount of critical resources and a minimum of two critical path features from a server. This is quite interesting. And then what does this post orders will add? Just shows you what your site has done very well. So you can open that up and you can see it, and you can look at this and see what your site is doing curriculum as quite interesting. And then I really don't want to go through this in detail because it really is intuitive as you can tell, tells you some of the best practices. We not using HTTP 2, which we could use. It even costs into depth, Yeah, Bob, SEO, search engine optimization, which is cost isn't about. So very, very intuitive. See how awesome this tool is. It gives you a high level summary of the critical path and it's a good place to start. You know, we did heck away on our own by looking at the network and performance tabs. But this Rayleigh in practicality point of view is the way to go and it's at least a very good starting point when you're analyzing your site. So there you have it. I hope you've learned a lot and she know it just performed. Move on. There's something I want to mention. We did discuss images. And if I scroll down here, and opportunity in this particular very simple example is to actually optimize our images. How do we do that? Well, firstly, optimizing an image helps us reduce load time, which improves performance of the restaurant. And the sizes of the image themselves. Also important if a uses on her mobile phone and the width of the screens on 500 pixels, there's not point in ascending the user an image that has pixels of 1.5 thousand in width. Obviously, this would be a waste of performance. So how do we go about resizing images and optimizing these images? Well, if it's a very small sites, you can do it manually, but it's just not practical for larger websites. So how do we do it? Well, the most simple is to resize images during your bold process when you're building your website. But as I mentioned, that can be a bit tedious. Second moral approach is during the bold process, we can define image sizes using the source set attribute. Thirdly, we can use the CDA may, but what a CDN was content delivery network. We can use a CDN that dynamically features a file on the fly based on the user's screen size. So we can actually request the size dynamically from a CD. And another thing we can do is that we can reduce file size. And that's what this opportunity sections even telling us on the ordered Lighthouse report, it says Serve images in next-gen formats. So in effect, all you would need to do is take our image that we have on our server and we have to run it through a program. And in their program can reduce the file size. It can compress it to a very small size. I just wanted to mention that and I was just about to finish installation of what you know what let me just named Jeannette in relation to images. But anyway, this is a very good starting point and I hope now you can appreciate the level of detail we've gone into. And then how complicated it actually is and what the browser's doing in the background to render content to page. I hope you've had fun. But as I keep saying, Well, not quite done yet with this course. So I'll see you in the next lecture. 15. YOU ARE FINISHED!: But five miles away. While then my dear, dear students, well then for finishing this losses, the end, in fact, well done for finishing the highest series with me. We have covered a serious amount of information and as you know, our topics of all seated around that the critical rendering path. We know that every time a user visits your website, round trips have to be made on that user's device to your server and his browser. And it's our job as developers to make those roundtrips as quick and seamless as possible. And we've learned that there's a lot happening in the browser. The browser engine has to process information. It has to construct the DOM, the CSS on the render tree, then has to go through a layout process and only then can it start painting pixels on a browser bird. What am I talking about? You already know all of this, don't you? And in this last class we looked at how to bold very simple sites. And as we went along, how to ordered performance, It's been a very practical class, hasn't spent a lot of fun. We started just with HTML. We started adding things like CSS and JavaScript. And we know that when you start adding more teal file, it can block the rendering process. And this is why we've spent a lot of time figuring out how to streamline the entire process, how to use attributes like Async will differ. And of course, how to assess performance by looking at the Dave console, by looking at waterfalls, by looking at the time charts, by looking at the network tab, by looking at lighthouse order. I mean, seriously, we keep go on and on and on about how much we've learned. But really also hope at the same time you've had a lot of fun because we need to enjoy what we do. Like a short, two short. So anyway, thank you so much for sticking with me in this class through all my classes. And I really, really do hope to see you in another future. Gloss, keep while my students stay safe and I'll see you hopefully soon. Bye.