*NEW* Speed Up Webpage Loading 2021 - Part 5: Render blocking resources | Clyde Matthew | Skillshare

Playback Speed

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

*NEW* Speed Up Webpage Loading 2021 - Part 5: Render blocking resources

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

24 Lessons (1h 47m)
    • 1. Class introduction

    • 2. Render blocking resources - introduction

    • 3. Solving CSS rendering with media queries

    • 4. Media type query - proof is in the pudding

    • 5. How do browsers render a page

    • 6. JavaScript and the DOM

    • 7. Order of your code matters - part 1

    • 8. Order of your code matters - part 2

    • 9. JavaScript and CSSOM

    • 10. JavaScript has to wait for the CSSOM

    • 11. Step back

    • 12. Where can you place your JavaScript code

    • 13. 12 placing JS at the bottom of the page

    • 14. Async

    • 15. Async vs bottom

    • 16. Defer

    • 17. Custom event - part 1

    • 18. Custom event - part 2

    • 19. 18 async vs defer vs custom

    • 20. Preload

    • 21. Recap - where can you place JS code

    • 22. Putting it all together

    • 23. Speculative Parser

    • 24. Outro

  • --
  • 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 5 we're going to speak about render blocking resources and how this effects the Critical Rendering Path. 

You can think of render blocking resources as static files (fonts, HTML, CSS, and JavaScript), that are vital to the process of rendering a web page.

In my previous class, we saw that the critical rendering path requires both the DOM and the CSSOM to construct the render tree. This creates an important performance implication, because both HTML and CSS are render blocking resources. The HTML is obvious, since without the DOM we would not have anything to render, but the CSS requirement may be less obvious. 

But why is knowing about render blocking resources important?

It's important because when the browser encounters a render blocking resource, it stops downloading the rest of the resources until these critical files are processed. Our goal as developers is to shorten this time as much as possible. 

If you reduce the number of render blocking resources, you can shorten the Critical Rendering Path and reduce page load times, thus improving the user experience and search engine optimization.

Bottom line: in this class I will talk about render blocking resources and more importantly, how to optimize your site to speed up the Critical Rendering Path process. 

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, students. I hope you're having fun. This is yet another class, but this class is gonna be, it's gonna be fascinating because we're gonna be talking about Winder blocking resources. In other words, those resources that block the rendering process, some information on a webpage, you would agree with me is super crucial. And it's so crucial in fact that the browser understands that it has to wait in order to display information at all to the user. What kind of information is this will, for example, CSS is render blocking by default, as we'll see in a lecture, there are certain ways there are some things we can do in order to tell the browser not to wait for the entire CSS file to be loaded, for example, then we've got JavaScript. And JavaScript is a piece of aside. And we're gonna be looking at some attributes we can place on the script tag in order to kind of improve the performance of our site. Attributes like async defer Wheeler heard executes. It's going to be really epic. We're also going to be looking at where you can place your JavaScript code in order to improve the site performance. So that's what this class is gonna cover. There's a lot of information, a lot of useful information in this class. It's really going to help you understand what a render blocking resource is and how we can start dealing with those to improve site performance. In the next loss, we actually going to be looking at how to audit the site and how to optimize a website. So this isn't about auditing a site as such, but it's giving you the fundamentals and knowledge in order to actually audit a size. So really, really crucial to this point, we've already heap sorry, coffee. After this point, we've already learned about the DOM, the CSS on the render tree painting process or let me say the layout process and in the painting process. So we've come a long way super proud of you having as much fun as I am in these classes. And I'll see you in the very first lecture where we start talking about CSS as a render blocking results. Look at this beautiful view. Look at it. Beautiful rock epsilon digits, xenon. 2. Render blocking resources - introduction: Key to understanding how to improve your code and your site's performance is understanding rendered blocking resources. By default, CSS is treated as a render blocking resource. But what I mean by render blocking, what does it mean? Will very simplistic dir just means that the browser weren't render, weren't process any content until the CSS arm is constructed. But almost means that the entire process is put on hold until the CSS OMB has been fully constructed at the CSS style sheets have been read through by the browser, and a whole tree has been constructed on the back of that until that's done. Everything else is put on pause. Because of this, you should always just make sure you keep your CSS and deliver it as quickly as possible to the browser. So that's why we use media types and queries to unblock rendering. In the previous sections, we saw that in the construction of the render tree, that the critical rendering path requires both the DOM and CSS on to construct the render tree. Remember, that requires these two things, and this has one very important implication and that is drumroll. Html and CSS or render blocking resources. It may seem obvious that HTML was render blocking because without the DOM there'll be nothing to display. But it might not be that obvious in relation to the SSS. Okay, but what does this all mean? Well, let's look at the case first. If CSS is not render blocking. So let's just say that the browser takes your content, your HTML file, and at the space around the screen very quickly and it doesn't even wait for the CSE is too low. Well, this is what the site is gonna look like. It's going to look terrible. Yucky. Which is why it's good to actually have render blocking resources. Sometimes you wanted as a develop, right? You want to have a nice side that's displayed to users full of content in the CSS. All done. Cool. That was a very high level summary of what a render blocking resource is. But now let's dive into this further. And just in case you're wondering, how do we actually see a website that doesn't have any CSS? Well, turns out it is super simple. Let's have a look. Let's just go to some random website. I don't know. Maybe got Stack Overflow. So yeah, we are we are on Stack Overflow. And what if CSS wasn't green the blocking, what would this look like? All you can quickly just go to the div tools so we can expect this page. And usually the CSS is always kept within the head section. I'll zoom in there for you so you can see usually the CSS is within the head section. And if we open this up here, we can see here the link H ref takes is this isn't really CSS, but if we keep scrolling down, we should be able to find CSS. I'm way. And then we go, we've attacked, takes Less CSS. So the point I'm trying to make is that if we delete this entire head tag, there we go, we get rid of all the CSS. And that's why it looks a complete miss. The degas. Just in case you're wondering how I actually did that. 99. 3. Solving CSS rendering with media queries: We've just seen that by default, CSS is a render blocking resource. And this makes sense, right? Because otherwise the site is going to load and it's gonna look AGI. So you want the render tree to wait until the CASIS is fully been rendered and downloaded, makes it. But of course, with every rule, there is an exception. What if we want some CAC styles to only be used under certain conditions? What kind of conditions will, for example, when the page is being printed or being viewed on a certain screen size would be nice if we didn't have to block rendering on these resources. And the good news is that this is media queries come into the picture. So what is a media query? Well, at its heart, a media query consists of a media type and a rule that Chicks for some condition or conditions. But what does this mean? It's looking at an example where we had our link task style.css file. In our previous example, we didn't provide a media type or query. So what does it mean, will that means this stylesheet, the CSS will apply in all cases. That is to say it is always render blocking. So that's our simple base case example. But now let's go a bit further. Now lit at a media query and lit stated the condition applies in all. What can you notice from this code in front of you? Well, firstly, notice the word media. By using media queries, we can tailor our presentation to specific use cases, such as Display versus print, and also to add dynamic conditions such as changes in screen orientation, resize events and even more. Just remain that by using the keyword media with telling the browser to assess when the style sheet should apply. And what else can you notice? It's rights. Secondly, our condition here is sit to what? To all. All is the default type. So if you don't specify any type, implicitly said to all hints are first link relief that I just showed you before, this one and this one are actually equivalent. These two that we've just seen are equivalent to each other. They are both render blocking. But let's keep going. Let's look at another example now. So yeah, let's just have a link to our portrait dot CSS file. And yeah, let's add a media query with the condition of orientation portrait. This is a dynamic media query and it's evaluated when the page is first loaded. So depending on the orientation of the device while the page is first loading, portrait dot css may or may not be Render blocking. Let's look at another example now. The print condition. The print condition is only applied when the pages being surprise, surprise printed. So it's not green. The blocking when the page is first loaded in the browser, this media type of prompt doesn't affect the layout or the changing of fonts and so on and so forth when it's viewed on a device. And the care, so it makes sense that the browser doesn't need to block the rendering of the page for this portrait dot CSS file when the page is first loaded. Finally, what about this last stylesheet link? Will This is providing immediate query which is executed by the browser. And if the condition matches, the browser will block rendering into the style sheet is downloaded and processed. So here we've defined a condition that the minimum width of the device of the viewport has to be 30 m. And if that is true, then the browser will block the rendering. If it's not true, rendering won't be blocked. So this whole media query here may or may not be rendered blocking. Cu, well done, cuz I think this is trying to make sense. Let's just quickly recap what we've led. One, by default, CSS is a render blocking resource. We know this media queries and allow us to mark some CSS files as non-random blocking. And all this means is at when declaring your stylesheet assets, okay, all the CSS files pay very close attention to the media queries because they greatly impact your critical rendering path performance. And before this lecture ends, I just want to drive a few more points. I am because not many people fully understand what it means to be Render blocking. The most obvious is that render blocking means the browser pauses the initial, and this is the keyword I want you to just be stuck on an initial render blocking means the browser pauses the initial rendering of the entire page until it finishes processing that particular resource. And this is what I want you to get in all cases. And regardless of the about, the browser still has to download every single CSS file. It's just that with non-blocking resources, the browser still has to download the resource, but it can just do so later after the page has loaded. And this is what gives you an awesome user experience because the whole site is loaded, looks nice. And in the background, files are still being downloaded, but you and I have no idea let me visiting the website. Heavy. Got it. I hope so. And I'm sure you do. So let's move on. I'll see you now. 4. Media type query - proof is in the pudding: Media type queries, as we've seen, can define whether you want CSS to be random blocking or not. To say we don't want CSS to be Render blocking. Let me prove to you how media queries can solve this problem. So we are going to be quickly coding up a very simple example. We are then going to be looking at the performance tab and the Network tab on digital's just so we can prove the concept that it actually does work as expected. That's beginning. As always, our starting point is a blank file. So let's create our HTML template. The title can just be at a no media query. And in our body, all I want is a paragraph tag, and let's just have some lorem ipsum, some random text. The only other thing I want to do is let's just styled as paragraph and let's make it blue. So we'll just add an inline style sheet here just for the sake of simplicity. And we'll just have the color of this paragraph tag being blue. Okay, and if we look at this online, there we go. We just have blue Lorem ipsum text. So far so good. But now let's say we want to add immediate query that is only applicable when the user wants to print the page. So whether they in print preview, whether they went to print, then we need to apply different styles. And this is often the case on websites because, you know, you don't want big images and fleshy content when it comes to printing, you just want the crux of it. How would we go about doing that and what does this do to the critical rendering path? Let's find out. So the first thing we need to do is obviously include on link tag and we wanting our rift be the print CSS file. But in this case we want to add a media type of print. What do we want in our print dot CSS file? Will again, it's just a blank file. Now, I'm going to just change this paragraph color to red, just so we can have a contrast and you can know it's working bat, let's assume this CSS file was massive. So what I'm gonna do is I'm just going to copy and paste this. Copy and paste it again. The effect of compounding. And let's assume it's massive. Our file is cool. It I don't have 43,590 lines long. And in our case, of course, we're not doing anything extravagant, but the browser still has to pass each line of the CSS. Because I want to prove a point before I head over to the console and review the site in action and we look at the performance tab and network tab, what would you expect to happen? Just take a step back. We've added a media query that should only apply when the user is in print preview as a Develop out, expect this media print CSS file, this print dot CSS file to only load once the full render trees being constructed and the painting process has happened. In other words, I don't expect that to be passed and downloaded off to the page has been fully loaded. Let's see if this is the case. Let's head over to the browser. Okay, so here is our website. He has are Lorem ipsum text. Firstly, you probably thinking Will has this print media query worth? Well, we can check, we can just go to our print preview and we can see it's in red text. So we know that our print dot css file is working and it's only working when we are in print, preview, and reprint the site. So that's all good or well, we know what's going on. But now leads Look at the critical rendering path. Let's inspect our page. Let's go to the performance tab. And we've been through this, we know it's going on now. We just gotta wait to num, num. And here we go. Let's zoom in on the area of importance. And let's look at our event log and remember what we would expect to happen yet. Who firstly, limiters remove myself so you can actually see behind me, what would you expect to happen? Will we said we've edited immediate query, we've edited media type of print. So that means that we should be able to see the paint. And only then should the file be downloaded from the server, images zoom in a bit. And if we scroll down and please take note of the times this has happened in, has the paint the painters happened at a 131 milliseconds. We remember that. Now if we go down, we've got this receive response, received daughter. See response. Here we go. It's actually just below the painting process. And if I zoom out slightly, you can see here that we've received response now from the print dot CSS file by point I'm trying to make is that the CSS file that has only happened after the painting process. Since the one thing I wanted to show you, another thing I want to show is in this network tab. If we zoom in again on the area that's important to us. This is refresh the page. Yeah, we go. What do you notice? Well, the one thing I noticed is that DOM content loaded if eight has fired before the print ab.js file has been fully downloaded. That's what I wanted to show you here. That blue line happens before printed dot CSS is fully downloaded. Ok, great. But now let me prove this concept here. So let's go back to our coding editor and let's remove this print type. Now we've got no media query. What do you expect to happen now? Let's write out expect now this CSS file to be rendered blocking and see if that is the case. So let's go back to our site and let's refresh the page and it's clear everything. Let's refresh. The first thing we notice is that now the paragraph has read it Maxine's because it's placed after the first style of blue. So that intuitively makes sense. The second thing I noticed with Dylan, the nitwit Tab is what? Lets write the DOM content loaded event fires after the print dot CSS file has been downloaded. Now it has to wait. And if we go the performance damp, it's clear everything and it's assist this again. It's weight dom, dom, dom. And here we go out. Expect now the print dot CSS file to have occurred before the pentavalent. So let's find the paint of int. Yeah, we go and remember I asked you to take note of previous time of the painted in. What was it? That's right. And now this paint of inters taken 206 milliseconds, so we know it's taken a longer time to actually render this continent task screen. And if we look at activities that happened prior to this paint of end, we should find, I'll print file. And there it is, finished loading not printed dot CSS file. And this is the point I'm trying to make Previously, we could differ their process to after painting. Now because we didn't have immediate type, it has blocked greenery. Cuz I hope this is making scenes are happy, feeling more intuitive about this and her getting fat. I'll see you in the next lecture. 5. How do browsers render a page: Before we start jumping into JavaScript, I just want to give you a quick recap. Taking a step back, we've got the DOM and we've got the CSS on. And we know the DOM parsers, HTML, all the CSS on, parses, CSS. And let's just have a timeline. We start at time 0 and we go all the way down to the render tree. Because remember the render trees, the goal, that's what's going to happen once the DOM and CSS on or completed and combined. And we know when it comes to the DOM, bytes have to be converted into characters, which are converted into tokens, into nodes, which forms the DOM. But now the render tree is not formed at this point, is it? Now? Because when the parsing process happens on the DOM, parser will find a link tag to a CSS file. And when that happens, your browser has to finish that CSS file. And of course the bytes get converted characters, converted tokens to nodes, to the CSS on. And then the layout and the painting process can happen. And early Dain does the render tree it created. It makes complete sense, right? We know that the render tree must be constructed before a successful paint can happen. And this means that both your HTML and your CSS render blocking resources. So the story is that you should get your HTML and your CSS to the client, to the browser as fast as possible. But we know this, this is just a quick recap. We need to now understand how JavaScript fits into the picture. 6. JavaScript and the DOM: The moment we have all been waiting for waders, JavaScript fit in with or not. You are a JavaScript programmer. Most webpages have HTML, CSS, and JavaScript. And that's why we need to understand how JavaScript fits into the whole critical rendering path process. We know that JavaScript can modify the style and the content of a page. And of course, the style relates to the CSS on the content relates to the try the DOM. Let's look at a simple case first, I don't want to jump into complicated JavaScript just yet, a harness to just take a step back. Let's create a very simple HTML page. We've got a head section and we've got a body section. That's it. And the body section just contains hello world. So very simple patch, nothing too fancy. We know that the bytes that can be converted to characters, two tokens to nodes, and the DOM is constructed, we know that. And we also know when the browser hits this link tag and references that style.css file, that a request is made to fetch the style.css and a CSS on process can begin. And this is important that I want to drive home both the CSS and the DOM happen asynchronously. And as logical rights, doesn't that make scenes, both the DOM and CSS are being created, but one doesn't have to wait for the other. Remember, we've always been saying throughout this whole time that these two structures are completely independent. So that's a starting point. Wrap your head around that. And now let's look at JavaScript. We've got our DOM, and we've got our JavaScript JS file. And this JavaScript file does nothing. And initially, right, we know this. So if we look at our HTML example here, PaaS is gonna go through line by line. It's going to pass DOCTYPE HTML. That's going to then pass the UTF-8 encoding type, converting those bytes into characters. It's gonna continue to pass line by line and make scenes. When you pass it in, hits that link to your styles.css file. The CSS on process is going to begin make scenes, but then the DOM is gonna continue going. It's going to then hit the script tag. Boom. And what's going to happen now? Well now the DOM is going to be paused. That means there is normal parsing, that means there is no more DOM construction. It's paused, that's put on hold. Your parser JavaScript engine as England interpretive js file. In our case, it's going to be executed. Alert highs gonna be shown to the screen. And only then can the DOM construction continue. Go through each line and pass the document and the bytes. We converted the characters to token to nodes and the DOM could finally be rendered. So as I'm sure you can already tell, JavaScript is render blocking and it makes sense that blocks the rendering of the DOM. Because in many instances, our JavaScript can actually alter the DOM and it can even alter the CSS on that, more on how JavaScript that fixed the CSS on. Next. 7. Order of your code matters - part 1: We've just been talking about how JavaScript and the DOM interact, how they relate to each other. And we saw that when the parcel goes through your file in it hits that script tag that the DOM has posed and just bear in mind, this isn't entirely true. This is the traditional way that the browser process used to work. But before we get into the New Age way of how browsers interact with JavaScript, you need to understand this. This is the traditional way. This is what wastage to happen. Deconstruction process of the DOM literally used to stop. And now browsers, if implemented new techniques such as pre loading or speculative parsing, we are going to be getting into these things later. So don't worry, just understand that tradition. This is what the browser needs to do. Just do hit that script tag and everything else used to be on hold. But now I want to prove this to you. So let's take a JavaScript file and I want to show you how the placement of your script really does matter. Let me just get my chair and you can see we put a blank Visual Studio Code editor in front of us. So let's start coding. First thing I wanna do is create an index file. So let's do that index.html and it's going to be a very simple example here. Let's just call it JavaScript verse the DOM. And in our body, I want three headings. And let's just have the H1 tag. Does have an H2 tag, and this is going to be changed by JavaScript. So I want this to be changed by external one dot js. We're gonna have this file shortly. And let's have authored AD. And let's say this is going to be changed by external to dot js. And so far so good. But now I just want to add JavaScript. I want to add specifically five scripts and three of which I want to be inlined. And two of those I want to have as an external JavaScript file. So let's do that. Let's create our first inline script. And yeah, I just want us to console, log in line one. I'll next script. I want this to reference. I'll earn file. So let's just call it external one dot js. And of course we don't have it yet. So let's quickly create an external 1.jpg file in this file or don't want us to do will remember in the index file. Let me go back to it. Yeah, we had that H2 header. We want that H2 he needed to be changed by the external one js file. So let's do that. Let's just change the color as an example. So the first thing we have to do is find out H2 tag. So we'd let H2 and we used the browsers in Bolt document get elements by tag name method. And we want to find out h two. And remember this returns a node list. So we need to access the first item in the array to get the first H2 tag in our document. And then later just, let's change the CSA's, let's just change the CCS. So we're keeping it very simple. We access our H2 element within exceeds its style property. And we just want to change its color to, let's say read. And to complete our process, we just went to a console log to the screen. So let's console log external one. So there you go. These are external one js file. Let's go back to our index.html and finish this off. I'm wanting to have another inline script channel. And again, let's console log in line two. And now I want to have our lost external script file. So let's do a script source attribute and we'll name that external to dot js. And yes, we don't have it. So we've got to create our external to dot js file. Let's go back to our index file. What do we want this file to do? We'll look at our H3 header. We want that to be changed by this external two dot js file. So let's do exactly the same thing. Let's access now our h3 tag, late H3 equal and we using the browsers in Bolt document.getElementsByTagName method. Yes, we want to access our h three header. Remember it returns a node list. That's why we need to excess the first item in the array. And we want to change the CSAs. So let's access data, it style property, and we want to change its color and its changes color to blue. And finish it off. Let's console log on. So log external to. There we go. I know I'm going quick, but this is very simple and I just want to prove a point. So we're going back to our index file. And right now, the last thing I wanna do is add one more inline script. And that's just going to console log in line. And there we have. It has a very simple HTML page with five scripts. What do you think is going to happen? So I want you to pause the video now. Well, you know what, I'll actually finish the video. All right, yeah. Think about it and just try and figure out what the console log is gonna look like, in what order and what's going to happen. I'll see you in the next lecture. 8. Order of your code matters - part 2: Could you figure it out? I'm sure you probably did. Actually, it wasn't a trick question. So let's just look quickly. Limitless thought MATLAB server. And here we go. The first thing we notice is that the H2 header has been changed by the external one file, it's red. We know that. And the third hidden change by external to John Jay's has word, the colors now blue. So that's positive. But what would you expect to happen in the console? Will, if I go back to our coding inhibitor firstly, remember what we spoke about when we see it, how the JavaScript interacts with the DOM, right? We said that when the parser hits a script tag, the DOM construction as paused SAR expect when it hits this first script tag that everything below it would be put on pools. And at the console log in line one would be output to the screen. When that's finished execution not expect the next script tag to be head, which is a reference to the external one dot JS file. The external one js file will then be executed and console log external one would be output to the screen and so on and so forth. The possible then hit the next script tag in line to be consoled. It'll then hit the external two dot js file. And that would be console log to the screen. And then finally, the parser will get to the final script and console log in line two to the screen. So that's what I would expect to see. And let's see if that happened to. Let's inspect our document and go to the console in line one, external, one inline to, external to an inline to, oh sorry, that should actually be in line three. And if we save this and go back to our console, clear everything and refresh the ego to exactly as we would expect. But now this is what I mean when I say that the DOM construction as paused, what if we took our external to dot js and replaced it above the h3 tag. Remember there are external to file, what it does are external to file to remind you, let's go into it. It accesses the h3 tag and then we change its color to blue. That's what this file does. If we place it above the h3 tag, what what's going to happen? All the parcel would have hit H1, would have hit H2. Now it would have hit this script tag. And remember DOM construction as paused. So that means by the time the script tag is hit, it hasn't yet passed that h3 tag hazard. So when we have our H3 reference here, it's not going to find it because we haven't yet reached at the parser, has not yet loaded it into the DOM, and that's proven. So let's save this, go back to our site. And can you notice what's happened now? Will that change by external? Today's is not blue anymore wizard that H3 hidden, but still black, which means it hasn't had any effect. We even see an uncaught type error in our console. It sees that the JavaScript parser cannot read the property style of undefined. And it even gives us a reference to a file. We click on that. We can see that it doesn't understand what that statement means. Because how are we accessing H3 when h3 doesn't yet exist? Goal, I hope you are understanding this. There's just one more thing I want to get across a net is you'd agree with me that this external tool file is executed before the DOM has passed h3 tag, right, vaccines, but let's prove it. So let's go the Performance tab. Let's reload and record the process. Let's wait. And there we go. Zoom in on the area of importance and let's look at the event log. And a remedy event log just shows us the chronological order of the process it's happened. And if we scroll down here, this is the interesting thing I wanna show you. We've got our valuate script that occurred in a 111 milliseconds from the start of our reload. But if you go down after that happened, do we only get to this parse HTML portion? In this parse HTML is the DOM continuing at parsing process, let me just remove myself quickly cause I do wanna show you something. If you look and let me just zoom in a little bit. And what I want to show you is if you look at the top right, we can see that the parser is at line 11. And if we follow this link, we can see we are at the H2 tag. The point I'm trying to make as by the time the parser hits the H2 tag, if we go back to the performance, the script is already tried to run. It's tried to evaluate the script. And a Hopi understanding the gravity of what you've just learned here, we've literally just proved that that script is executed before your process even reached the h3 tag. This is phenomenal hobby enjoying that. I hope that starting to sink in now, as I mentioned before, does get a little bit more complicated than this because it doesn't just run sequentially. Everything doesn't just run sequentially. You can even see if we're looking at this performance event log, we can see that there's a whole lot of processes, is whole lot of calls happening. At the same time your JavaScript files are being fetched. So I'm going to get into that shortly, but the concept still applies today in that the position of your script matters is important because the DOM stool can't execute other scripts into your first script is fully executed. And if you place it too soon in the DOM, you don't wouldn't event time. I passed the elements below it before this is executed. So it's a very long-winded way of saying that the location of your scripts do still matter even in today's environment. I hope you enjoyed it and I'll see you in the next lecture. 9. JavaScript and CSSOM: We've seen a JavaScript blocks the rendering of the DOM, but how does it relate to CSS? Well, that's what we're going to look at now. Again, myths just create a very simple HTML document. Starting at the beginning, we've got our dot CSS file. We also had our ab.js file. And this JS file does nothing. And initially, we know this, we've seen this. And let's just start with our simple HTML document. We know the POS is gonna go through line by line and remember when we didn't have the CSA's, what happened. Let's write a JavaScript file was executed and it blocked the DOM. Remember that? But what happens now will, now we've got something different because we have a reference to a styles.css file. And when that happens, the JavaScript execution has to wait and told the CSS on Israeli. And it's kind of also make sense because the JavaScript file can affect the CSA styles. Needs to make sure that the CSS is entirely available to it. When that call to the CSS file is made, we know that vital committed characters to token to nodes, to the CSS on and only when that is fully completed can a JavaScript file continued to execute. Does this make sense? I hope served, but let's start getting into examples to start looking at how this all fits together and hope you'll join us. I just Oliver stuff. I'll see you now. 10. JavaScript has to wait for the CSSOM: Okay, hope you having fun, enjoying it. But now we mentioned that JavaScript has to wait in order for the ceases to be constructed before can be executed. That I want to prove this to you because you mustn't just take my word for it. I love seeing things in action. I love seeing it in a practical way. So instead of coding, very boring code with you, C, Yeah, and Visual Studio occurred, I've just got a very simple HTML document. What do we have? All? We've got two things. We've got a link H ref to our styles.css file, and then we've got our script tag. So I'll JavaScript file. And what do we want to prove? What we want to prove that that JavaScript file, that app.js is not going to be executing in parallel with that styles.css file. Ok, cool, well let me show you what a star looks like. It's a very simple style sheets. It's actually a lot of it's redundant. I'm just wanting it to take time. So I want to prove something to you. So I've just literally changing this paragraph elements to the color blue. So lambda, and it's a style sheet and you can see gets 226 thousand lines. And what does my app.js file do? Well, that's also a very, very simple. I'm just going to console log something to the console. Every simple file. Let's see what this looks like. So there's a lovely lorem ipsum in blue. But now let's inspect our document. Let's see what's going to be happening in the background. So let's inspect its good to the performance tab because we've been dealing with this currently. And let's reload this document and report the prices. So let's wait. Maybe God, there's pretty quick, right? And now this is what I want to show you. I want to show you this this year PVC hat. Can you see how your app.js file had to wait that whole amount of time and had to wait for that styles.css file to be fully executed for it would execute itself. And this is just proving the concept that the order of your code matters, not any debt. That also that when you have a script file and a CSS file, descriptors placed below that file does have to wait for the ceases to be constructed before it can fire. Script. Makes sense. This was a very quick lecture to prove a very simple concept, but very important. I'll see you soon. 11. Step back: All right, we know that it all starts at HTML, where your engine starts parsing your HTML code line by line. And when your JavaScript parser hits that JavaScript script tag, what happened? They tried the DOM is paused until JavaScript is done. And this demonstrates a one very important property. Our script is executed at the exact point where it is inserted in the document. And when the HTML parser encounters the scripted has to pause the process of constructing the DOM, and it yields control over to the JavaScript engine. Only after the JavaScript engine finishes does the browser then pick up where it left off and resume the DOM construction. And this concept that the JavaScript engine has to finish executing that script before the browser can continue. We'll, you'd expect that to happen in an external script tag as well as inline JavaScript, right? And it's great. It's just the case with external JavaScript. The browser has to do more work because the browser has to either feature that JavaScript file from local disk, from cache, or from the server. And this can add tens to hundreds of thousands of milliseconds. Critical rendering path. Cool, we've got, you know, this already probably getting bored. Let me jump into the computer and its continued senile. But now we've got another dependency, don't we? We've got CSS. When your engine starts parsing that CSAs, we've seen that JavaScript is paused until a CSS on is entirely done. And this just illustrates that the placing of your JavaScript code matters. It's very, very important. Before we move on just a few more points, I want to mention one, JavaScript can query and modify the DOM and CSS on. We know this. And because of this, JavaScript introduces a lot of new dependencies between the DOM, the CSS, and JavaScript execution. And this can cause the browser significant delays in processing and rendering the page on the screen enter large degree optimizing the critical rendering path, which is what this course is about. Debt refers to understanding and optimizing the dependencies between HTML, CSS, and JavaScript. I hope this is starting to make sense. So we know that by default, all JavaScript is possible blocking. And this applies whether we reference in external script. All right, our JavaScript directly in our code in line, as I've just mentioned, with an external file, even more time is required. So by default, all JavaScript as possible blocking. But the big question is, drumroll. How do we solve this? What if we don't want javascript to be parser blocking? What can we do? Well, that is a very good question and we're going to find out now. 12. Where can you place your JavaScript code: Let's now understand how to eliminate unnecessary JavaScript from affecting the critical rendering path. Remember what our goal is. Our goal is to deliver above the fold content as quickly as possible to the user. Just remember that that's our goal. So if we only need JavaScript further down our page below the fold, below what the user can see. Then we don't want those resources taking up critical rendering path of form and space. Do we know, unlike CSS, the browser doesn't need to download and parse all JavaScript resources to render the page. So it's not technically a required step. Although most modern websites do XD require JavaScript for above the fold experience, bats when your browser hits a script tag, the page rendering process is paused and it's paused until after the JavaScript is executed. And the reason the page rendering is pause as because JavaScript has the power to manipulate the DOM and CSS on. We've been through this, we notice that let's look at this visually. We know that your browser starts parsing your HTML and what happens when it hits a script tag that try, the parser has to go and fetch that JavaScript file. That then has to also execute that JavaScript file. And during that whole process, the parser is paused. We've seen at an only after execution of JavaScript, does your HTML parser continue. And once that is finished, the DOM content loaded event occurs. Okay, so what are we going to be doing? Well, we're going to be looking at ways of how to improve our critical rendering path performance. And when we look at these ways, you need to try and think, well, what is we optimize? So let's think about it. What are we trying to optimize? Well, there's many different metrics we can look at. That. The one that I think we should look at when testing these different methods is the first meaningful paint. That is the first thing that we want our users to see when they land on the page, that can kind of be what we consider the first meaningful paint. So it's almost like we want that to happen as quickly as possible. So let's go through these different methods. That's code up examples. And then while we doing it, let's keep a track of time that it's taken for us to reach these critical rendering path milestones. For example, the first painting, I'll also include the DOM content loaded event because there's this interesting. And then let's also put the load event any, so we can kind of just compete types across these different methods. And I just want to say, you know, there's not one solution fits all Kino. And a lot of people just want a quick fix. If there was a quick fix will be brilliant because a winemaker can just be applied to everything. But it's just like if someone comes to you and says, was, can you bought me a beautiful website? It's always relative these boys different aspects to a website. And you can have a shopping website, you can have a automobile website and never booking system, a chatroom. It just my answer is to that person. Well, it depends on kinda what side you want. And it's the same here without optimizing code, it depends what you want you could do to pins up beg your JavaScript files are how many scripts you have, how many images on the resources, etc, etc. So we're just gonna go through a very simple example, but it'll at least get you thinking about the protests and hardware goes. So hope you enjoy it. Or does get into our first line across enough. 13. 12 placing JS at the bottom of the page: All right, so the question we had in the last lecture was, how do we solve this problem? How do we stop JavaScript from blocking the rendering process? Malaria? Few ways. Let's start at the most simple and obvious. If you've ever taken a Web Design 101 course, this is going to be very familiar to you. We just placed links to external scripts at the bottom of our HTML body. And placing links at the bottom of your page is very similar, if not identical, to what you would get if you actually listened for the DOM content loaded event and only ran your JavaScript, then I'll show you more what I mean later. While placing JavaScript resources at the bottom of the HTML remains a standard best practice. This method by itself can be suboptimal for eliminating Grindr blocking scripts from the critical path. Why is this? Remember what it is we're trying to do here. We try to display content above the fold as quickly as possible. So when the user lands on your website, he sees, boom, exactly what you wanted to see. And everything below the fold below the screen, it can kind of happened in the background without the user even knowing before he scrolls down on the page where there were these finger on a phone or scroll bars, the mass, right? That's what we're trying to achieve. But placing our JavaScript at the bottom of our file still means that we have to wait for that to be executed before the final render can occur. You know, and sometimes you want that, sometimes you want to pause the re-entry process for very critical JavaScript resources, and in that case, continued to put your jobs profiles at the bottom. It is good in that instance. But sometimes for non-critical resources that can wait. Why not delayed the execution? So immediately the music and see that rendered content on the screen and in the background before even scrolls. You can then continue to build your site. Cool. Hope it's making sense to you now. So like I said, every step of the way I want us to start assessing performance at three major milestones in the critical rendering path process. One, I want to assess where the DOM content loaded event fires. Two, I want us to look at with the First Meaningful Paint occurs. And three, I want us to look at the onload event, okay, which is when all the resources have been fetched and executed and done and fired. Now, you remember in one of our previous examples, we had this code in the background that I don't want to recode everything just to recap, it's very, very simple HTML file here. We've just got a header tags. Then we've got our script tags. Again, we've got our first inline scripts and console log in line one. We then have an external script. To remind delicious liquid. That is, we just change the H2 color style to read. That's all we do. And then we console log external one to the screen. So that's our external one script. Them got another inline script and then we've got a fourth script tank, again referencing an external file. And this external file just changes the h3 tag and we change its color to blue. And within just console log to the screen external to simple nothing where, I mean, we've been through this example, we know what it's all about. And then we've got our final inline script, which just console logs in line three. Simple. So this is our default approach where we place our JavaScript at the bottom of the page. And let's just now get those time of it. Do you remember how to do it? And we'll maybe pause the video, think about, I hope you gave it a good girl, that it's due together. So let's fire up our site. Now we go make scenes. The first thing I can see is that our external files have worked correctly. And if we go back to our code, what would we expect to see in the console? Well, the first thing is if we know that the JavaScript execution happens synchronously. So in the browser hits the first script tag, everything else is forced in line one should be console log to the screen and then hits our external one dot js file. And then it opposes everything below it and it will console log external one to the screen are possible. Then hit the next script tag, which is just console logging in line too little, then hit the external two dot js file. And finally, the possible hit the lost script tag, which just console logs in line three to the screen. Sorry, expect the solution to be one. That's right in line one, external, one in line to external to an airline three. So if we go here and we inspect our document, and we go to the console in line one, external, one inline to, external to an inline three. So this is all making seems. Now to get those time metrics, let's go the Performance tab and let's start profiling this process. So let's do that. And there we go. What I wanna do now is I want to go into the event log. And what's really cool is we've got this filter, so we don't have to go and scroll down every way we can just go cool orders the DOM content loaded event. And we can see that happens at a 167 milliseconds. Have you got that? A 167.9 milliseconds. That's how long it took to fire the DOM content loaded event. Remember that number? Now, the meaningful paint. Well, again, it's really handy because we can just write paint on the screen. I want the dead tech will, if you click on this paint activity, you can see in the right-hand side of the page that it actually gives you a display of what they paint. That will I'm actually in a way, so let me just remove myself Cookie. Ok, maybe you can see that better now. Sort the right part of the screen and zoom in a little bit. Can you see it? So that's not the paint we went because no color has been changed. They hazard. What about the next one? The next one is only executed the very first external one, JavaScript file. So it's still not quite what we want. Gone to the last paint. We can see that that's exactly what we want the user to see. We wanted to see the black header, one tag, we want the header to, to be changed to red and the head of three to blue. So how long did that take? 200.4 milliseconds. Okay, remember that number? And lastly, I want us to look at the load event. Let me just zoom are challenging and you can see if we look at our main tab, you can kind of see the load event happened at roughly just before 300 milliseconds because there are a lot of load events that happened. Bear in mind that this isn't the final load. When we folder for this, the lots of event loads that are happening like window JavaScript file gets executed when you're pastas finished all the fun stuff. So the one that we are interested in is this event load here at 281.4 milliseconds. I mean, just lift it up so you can see here. Can you see it there? Let me just do this and then make the smaller lift us up and then you can see it. There you go. There's the event load at 281.4 milliseconds and we got that. Cool. 14. Async: And next we have async. Async was introduced by HTML5 that actually came after differ, which we're gonna see next. But I want to first talk about async. Remember that our JavaScript files are synchronous. Will the async attribute a signals to the browser to load JavaScript asynchronously, basically is telling the browser to fetch the script when resources become available, as opposed to just pausing the HTML parsing, completing this, now look at what this looks like. Our HTML parser begins parsing our file line by line. This is the cool thing with async and doesn't pause the parsing when the file is being fetched. The browser can do this with additional resources in the background. From previous examples, you would have seen that when the browser hits that script tag, it blocks the browser from doing its day. In other words, it stops the browser from becoming responsive and usable. So by adding this async attribute, we avoid this problem altogether. The browser can still run separate processes in the background, like fetching files. We're gonna see the Shortly Sadat's async. Let's get back into it. That's only during the execution phase that the possible completely stop n ones that execution is finished. Obviously you can continue parsing document and in the DOM content loaded event can fire. Although this casualness in running your code seems pretty awesome, you must realize that two scripts marked as Async will not always run in order. So what this means is that you could have a case where several scripts mark with Async will run in an order that's different than what they were specified in your markup. The only guarantee we have when we mark our JavaScript files with async is that they will start running at some mysterious point before the load event gets fired. So bear in mind some of these async scripts can actually be executed before the DOM content loaded event fires, and also after the DOM content loaded event fires. This is an important point to grasp. Now I want us to look at async, and let's just start at exactly the same page that we had before. But now we're not placing JavaScript at the bottom, are we? So now we're using the async attribute and the H1 header. We can just say this is using the async. And using async is incredibly simple. All you have to do is add an attribute called boomer mom, async. Very intuitive, right? So all we have to do is get our external script tags and we need to add the word async and the ego, the signals to the browser that it must fisheries resources in the background, preload them. So in our code is ready to execute them. Dod. It's all that async does. And remember it can start at any time for when the user first starts parsing your HTML all the way to the load event. Okay, this is what async does. So let's see what would you expect to happen here. Let's find out. Let's load our page. And what's awesome is that our external one jobs profile has worked because the Heading two tags read and are external to files work because the h3 tag is blue. So that's very cool. Now before we expect our console log, i want you to think about what you'd expect to happen. So let's go back to our farm. What would you expect to happen? Will remember what the async does. The async is for non-critical scripts. We're trying to improve our CRP prices are critical rendering path process. And adding this async attribute tells the browser can fetch the files in the background. And when it has a capacity, it can execute those files. So you have no control on exactly when it's going to be executed. But yeah, it will place these as lower priority than the other scripts in your document, for example. And you see the inline scripts. The console log in line one and console log in line two, and console log in line three will, because we've added async, I would expect those inline console logs to be displayed first. And only after that Stan will the async scripts get executed. Let's see if that occurred. Irgun, right? Otherwise it's going to be awkward. Awkward. So let's inspect the document. And let's go to the console in line one, inline to inline three, and an external one and external to exactly what I was just expecting. So this debt all working as expected. Now let's assist the performance again. And again. Let's start profiling and reloading the page. Let's wait. And yeah, we got the resume and on the area of importance. And now we can start searching for those events, right? We can go into event log and we can look for the DOM content loaded event. And how long has it taken? Now, let's write a 154.3 milliseconds. And what about our paint? Well, let's look at our paint. The second paint here. And again, you can't see it because I'm in no way limits removed myself. They go, you can see that the second painters, the one that has both the red and the blue ticks. So we know all our JavaScript has been executed. Well, how long has it taken? Let's take 225.4 milliseconds. Remember this number? And the last one that we want to look at is the load event. And here we can see that it's taken 273 milliseconds to 73.8 milliseconds. And honors just being cut off on the screen there little bit. But you just have to trust me that that's exactly what it is. So again, remember this number. 15. Async vs bottom: Awesome. So now we have our first comparison. Sir, let's just look at the bottom placement again. To remember, we split it up into DOM content loaded, Meaningful Paint and load event. And these are the values we got in milliseconds. Now we've just done async and as just populate the values were bom, bom. What do you notice? Yeah. Well, firstly, the meaningful painters actually taken slightly longer with async, which is quite interesting. It just shows you that there's never one right or wrong way to do something. But of course there's other things running in the background or not page at the wave soffits and a live server that we haven't even written ourselves, which causes other effects. What's interesting is that under the default approach that bottom placement, JavaScript asynchronous. And this means the DOM construction is paused whenever it hits a script tag. So it makes sense that the DOM content loaded a faintest, therefore delayed because it has to wait. Asynchronous. Other hand tells the browser to treat JavaScript as asynchronous. Our aim with async is to get a fast load as we are premised, leaving it up to the engine to go and fetch that JavaScript file in the background and then executed when it's needs to be executed. And we see that at the end of the day, that load event happens a little bit quicker than the bottom placement default approach. 16. Defer: And now let's get on to defer. The defer attribute is a bit different than async. Remember with Async, we said that we don't have a guarantee that they will be run in the order that we've defined in our markup. Differ is different at guarantees that the order in which we specified in our document will be run accordingly. But the interesting thing with defers that they also only get executed at the end just a few moments before the DOM content loaded event gets fired. Again. Let's visually see what this looks like. We've got our parser that starts parsing our HTML document. Our JavaScript file can be fetched in the background, so it doesn't affect our parsing. And just before the DOM content loaded, event fires are JavaScript file is executed. It doesn't make sense. I hope so. We're getting through it. They with me get a coffee, keep going. Now we're on to defer. We've seen the bottom of the page. We've seen async. Now, don't differ. How does this work? Well, let's just quickly go back to Zach same file, our starting point. Let's change this to differ now, because now we're going to be using differ. This is using the defer attribute. And again, how do we use it? Well, they tried, we just replace async with defer. It's literally that easy. Nothing else to it. What would you expect to happen to our console logs? Let's write our expect exact same thing as when we used asynchronous. That is, remember differ waits for the entire DOM to be loaded and then it fires those scripts. Just the four DOM content loaded event happened. Yeah, you're going to get to the first inline script that's going to execute your parser. The in is going to go to the second script tag and it's gonna see, oh differ, this can wait. That thing gonna go to the next script tag and it's going to see in line two, is gonna go to the next script tag and see, oh, differ, I can wait. And then it's going to hit the other script tag console log in line three. And then it's going to execute the previous scripts encountered. It's gonna say cool afterward it, but now need to execute their PSAT expect in line one, line two, line three, external line, external to be console logged in that order. The tip that happened. So let's fire up our server. Cool. Okay, so it's a nice relief when you see Europe, at least the colors working because then you know your script files are being loaded correctly. So we can see H2 is read, the h3 heading is blue. And let's inspect our console just to see that it is what we expected in London in 1903. External one external to awesome. That is, that is really, really good and it's what we would expect. Now let's assist the performance gain must just say set, we got await. And here we go. Let's zoom in on the area of important. And again, let's look at the DOM content loaded event. We can see that that happened at a 195.4 milliseconds. Remember that number, please? The next thing we want to look at is a trot. I'll paint and limit removed myself. And you can see that it's this second paint that has finished executing. Both our JavaScript files and the red and the blue are displayed to the user. So that's the one we want and that has a 193.1 milliseconds. And lastly, we can find the learn innovate. And again, the load event has happened at around the 300 millisecond mock, in our instance is exactly 314.5 milliseconds. 17. Custom event - part 1: Okay, so we've seen async and defer and they're relatively easy to implement, right? And the good solutions for extra stuff on your site reimbursed for the stuff below the fold, like social sharing buttons or personalized sidebar, a social news feed, for example. But these extra functions on your website don't necessarily break the primary user experience. It's good to use async and defer in those situations. But sometimes you want a bit more flexibility. Sometimes you, as a designer, as a programmer, you know exactly when you want your code to fire. And in that case, we can create our own custom event listeners. For example, we can add our own JavaScript function with an onload event. Let's see what this looks like. We are almost at the end is only another one after this and then we'd done. So please bear with me. We've gone through placing JavaScript at the bottom. We then looked at Async, we then looked at the third. And now I want us to look at a custom event listener that you and I can create. And we do this if our code is very peculiar in some manner, we want to really be in control of when their JavaScript gets executed against how do we do it? Well, we're not going to be using the for how we're going to be using our own custom event listener and our H1 hitting also needs to change. This is using a custom load event. So how do we do this? We'll first illustrate moved for this, remove this differ. And I wanna make this an extreme example. So what I'm gonna do is I'm going to take our external one script tag and I'm going to move it. I'm gonna move it all the way to the top before our H1 tag. And I'm not too concerned about performance here, comparing it to the erased, I wanna get rid of these inline scripts. Okay? So we've reduced our page to something very, very simple. We've got our external one JavaScript file. And then we've got our DOM, our HTML, and then we've got our final script tag which References External to cap, how does work? But how do we add our own custom of interest and will? Firstly, you don't have to, there's no attribute. It's not like putting the for where we just used the word the fertile async. The word async, there is no word called custom or anything like that. But we have to do is we have to attach an event listener to our window object if we want to listen to the load of angel to our document object if we want to listen to the the DOM content loaded debate. So let's go into our external one. But JS file, this is our standard far that we've had all along. I haven't changed a thing yet, but that is about to change. So let's access a window object. And if you don't know what this is, please do my JavaScript complete grandmaster cost that goes into detail about the hierarchy of how your page works, what the window object is, what the document object is, et cetera, et cetera. If you do know what it is, great, let's continue on this window object. We can attach an event listener. And funny enough, the inbuilt name for it is addEventListener. The first argument of this function will just meet it is the actual event we want to listen for. In our case, we want to listen to the load event, and then we want to execute this function. Let's call that function. And I'm going to be using the new arrow syntax. Again, if you don't know what these are, please see my grandma Stir cause and what I'm gonna do is I'm in a place all our code within this function. And now we have it. It's literally the simple. So all this is saying, just to recap, we've attached an event listener to a window object. And when the onload event gets fired, this function will be executed. Makes sense, right? So we would expect if we look at our file here, although the script tag is placed above our content, our H1, H2, H3 tag. Ordinarily, if we didn't have that event listener, we would get an error when we, because JavaScript would hit that script tag first, redeem, try and access that h, h2 element. And it wouldn't be able to find because H two doesn't yet exist. But with this approach should still work. Let's see if it does. So let's fire up our server. Okay, good news. Like I said, I always give a sigh of relief when R c R code working as expected, we can see that the H2 tag has changed to red color. So we know that our external one file was executed properly. What would you expect in the console? We'll think about it. What would you expect? Well, out expect our external to, to be console logged first, because external one is only executed after that motivate. So I'll expect to see external to external one. Let's see if that's right. Let's inspect the dock. And they we'd go external to external one. How awesome is this? 18. Custom event - part 2: And I want to do one more thing and I want to just look at the performance of this. I want to look at what's happened in the background. So this profile does that weight. And yeah, you got a heat to make it more clear. Let me just go to the console. Let me access our document, and it's just right. Nothing. To replace it with an empty screen will get up performance yet an artist refreshed again, just so we don't get confused. And you just got to wait a few seconds and offloaded again. And let's zoom in on the area that we're interested in. We can go into the event log. Let me just get rid of myself because you're going to have to start reading some of this text behind me. Ok, let's get going. What is happening here? Let me zoom in a bit so you can actually see a bit more clearly what's going on. Okay, we'll first we hit this, we get the same requests tab, right? An S just singing a request to the server. In our case, our local server earn computer to fit it index to HTML file. That's just what I've called my index file. And if we scroll down, we get to receive data 80 milliseconds. This is we are browsers actually received the daughter from the index.html file. We then hit this parse HTML activity. This is way our browsers now starting to bolt the DOM. How awesome is this? If we open it up, we can see its interior quest are external. One dot js file. That seemed another request to fetch our external to dot js file. So far so good, it's making seems right. And of course we don't have any external CSS files in our examples. So you can start constructing the layout of our page that can then implement a first paint. Right? Would keep going down. Within gates TO external one dot JS file. We get to that script. And if we go back to our code, just to remind you, let script is at the very top of our page. And that's why by the time it hits the script, nothing has been rendered to the screen. So if we go back to our event logs, even as first paint, nothing's actually been put onto the screen at this point, the previous door blank. Nothing's been rendered yet. And we know these things all happen randomly. Brother browser, the browser just doesn't have one painted it. The browser works in chunks. And that's why when we hit this first paint, nothing has been painted because it hasn't yet hit our H1 tags. We scroll down and we get to our very first significant line and our occurred, and that is the external one file. You just move it up a bit for you. But what's interesting is it doesn't execute that file, does it? Why is that? Let's write because we've attached an event listener that it should only execute this when that load event is fired. So that's why this hasn't been executed as just posted. And we get a load of vein saying, cool, that's passed a JavaScript file. And then we move on. And now the parser continues to go through our code. We can see that it's continuing to pass our file. How cool is this hand? Remember higher up. When we looked at our first DOM construction, bold it sinter quiz to fix their external to dot js file. Well, what's really awesome is if we scroll down here and we get to this. Receive response activity. We can see that now it's received that external to dot js file completely. It's finished loading it and now it evaluates it. And if we open that up, there we go. It actually gets executed, which is why when we go to console log, we can see that external T2 is executed before external one, because this is the point in our whole, entire critical rendering path that this file gets executed. Man is as exciting. I hope you're enjoying it and it's continued. Let's don't stop. So let's close it down. We continued to pass our HTML file. And then we've got this web socket handshake. This is all the Wave server that I'm using the live service or don't worry about this. This all just happens. It's out of our control. Okay, same here. What's interesting as we get to our first paint process, and they can see that external to judge js file has been executed because we have the blue H3 header. But the load of gains, delays and fight has it. So we're gonna keep going, we're going to keep going down. Got to keep going down. And we get to alert of India. 229 milliseconds. You can see this as we are motivated occurred and what happens if we open up this load of it? What is this function call? Will, there isn't this interesting? This is exactly where our external 1.jpg file gets executed. How awesome is this? And this is the point I was wanting to show you when we create our customer vein clusters, we can be very specific as to when we went out JavaScript fast be executed. And here we've told it we want it to execute after this load event has been fired. How awesome is that? And of course, at this point in time, still hasn't updated the paint hazard map, which is why we scroll further down. We've got this paint and this is way our H2 tag is now converted to read because now it's repainted the screen to ask the user, this just blows my mind and I hope you're having fun as well. Like it should start sinking in now, like it's quite intuitive when you start funding the process down the page. And then when you start writing code, you'll be more aware of what you're doing and heart works in the background that really will help you so well done for getting this far. And just bear in mind when we look at all these loader veins on the Activity Log don't get overwhelmed. We just remember that the load is not a single point in time. All these loadings are kind of like different experiences that not one metric can capture annual multiple moments during the whole load process, the whole Grindr process, they can cause the user to feel like it's a phosphate load or a slow load. And remember how we saw the paint before we even had reached our H1 tag. As I scroll up here, I'll just show you right at the top. We had this paint. Where is it that we had this painter vin here, with nothing displayed on the screen at this point, because the parser hadn't even hit our H1 tag. Point I'm trying to make here is that there's nothing protruding the browser partially rendering an incomplete dominance and CSS on tree and infected. The browser actually has to do this. It has to keep doing reflow in case JavaScript is referencing the CSS file. And if it is having to do reflow is on a consistent basis, why not just display those reflow updates to the screen? Why not just keep rendering as we go along? And I took the browser dance hand, I'm sure you can agree with me. This becomes even more important when a large files being fetched from the server with a browser doesn't wait for the entire file to be downloaded. It starts rendering it to the screen so the user can start reading incomplete data. It just helps us get the content to the screen Foster. So this is what I'm trying to get across the whole evaluation, rendering and painting process happens as a stream processing pipeline with many files and parts being done in parallel. Speaking to defeat makes sense, right? We trying to render content to the user as quickly as possible. And this is what the browser's helping us achieve. So I hope you've learned a lot through this specific lecture. Don't stop. I'll see you now. 19. 18 async vs defer vs custom: Who we have learned a ton and that's sorry, Fine. I really enjoy doing us and I hope you're having fun too. And Nas said, so let's assume the browsers already gone to the server with its via ajax or some other technology and it's received the daughter, we adapt point. Now I want to break down the rendering process into three broad categories. Simple. First is the page renders star. Then we get to the next milestone which has the DOM content loaded event and remote debt was, there was just an event that fires when the initial HTML document has been completely loaded and passed without the browser having to wait for style sheets, images in sub-frames to finish loading. A lot of jargon and a lot of words. Just bear in mind that DOM content loaded event is quite a significant phase in the render process. And then we've got our load in faint at the end. And probably very intuitively, the load event is fired when the whole page is loaded, including all the pendant resources such as stylesheets and images, which the DOM content loaded didn't take account off. Okay, so you've got a three broad categories. And what is our default case when we just include a script tag in our HTML? When a net case, the script execution, the point with a Damas paused. It depends on the placement of that script tag. So your DOM construction, your parser can be paused at any point between the start and the DOM content loaded event. That's our default case. We need to the script tag within your HTML. What about async? How do you think deadlocks will async, as interesting, async could be executed right from the page renders start all the way up until the load event. This was interesting about async. And instead, execution happens before the DOM content loaded, a faint has been fired. It can affect the DOM process. That's why we say a sick can affect the DOM. And what about our differ remember when naked fired? That's right, that's executed just before the DOM content loaded event is fired. And in that way, we can ensure that our entire DOM is loaded before we execute R script. That's quite cool. And remember we also discussed customer ways to rot out own JavaScript code and define when it's run, when it's fired. Well, one way is that we can listen to the DOM content loaded event and then we can execute our JavaScript. And if we do that, and you can see that the code would be executed just after that DOM content loaded event fires. This also allows you to ensure that the full gums constructed before your JavaScript code runs. And of course, they are many, many other things we can do such as we can listen for the load event on the window object. And that just means that the code or execute when the load of faintest fired. Who I, so this is it. This is like a bird's eye view of all the things we've learned to erected and we put it onto one slide. And I hope it's starting to make sense. I hope this is sinking in Hopi enjoying it, but setback pauses video taken the slide. Understand what all these different attributes do. Async defer that DOM content loaded event on the document object and then the load of inked on the window object. Just take it in. It's very interesting and I'll see you in the next lecture. 20. Preload: And last but not least, we've got preload, async and defer, or great, if you want to put off handing some scripts. But what about the stuff on your page that's critical for user experience? Speculative parsers are handy, but they do preload only a handful of resource types and they follow the logic. The general goal of a browsers to deliver CSE is first because it blocks rendering. Synchronous scripts will always have higher priority than asynchronous images visible in the view port should be downloaded before those below the fold. And you've also got Fonts, SVGs, videos, who in short, just gets complicated. There's a lot of things happening and sometimes a browser doesn't get it right. As the developer, you know exactly which resource should be the most important for rendering your page. And some of them often buried behind CSE. So scripts in a can take the browser quite a while before I even discovers those resources. To the awesome thing with preload, as you can tell the browser to pre-fetch resources without executing them, it gives you more control. In other words, a handler does it look like how do we do this? Well, the preload has to be wrapped within a link tag and unearth strange debit JavaScript in a link tag. But that's the way preload works. And the only other addition you need to link tag is this as attribute. And why do we need this as attribute ball? Because we need to tell the JavaScript engine what resource we want to be preloaded. You can link pretty much anything. So the S attributed just tells the browser what it will be downloading. How are we dealing with JavaScript, which is while as value is a script that we didn't have to weaken habitus, a style image, font, video, audio, et cetera, et cetera. We've come a long way. We've come an incredibly long way while then. And now we're onto our last one. And that is preload. It's quite an interesting one. That's fun to show you how that works. Okay, so we've got our previous example where we just listened to our own customer dangerousness. Let's get rid of that and say using preload. Let's move our script tag and its rightful place, and they don't wanna go into external one. Let's remove this event listener or the reader. There. We've got our normal code, okay, and what we can do. Okay, so first let's just look at the default scenario. Delicious learn a live server. And it's good rat with what read regard blue in our script files are working. Grab Performance tab and we look at our network tab. Let's have a look at are showing up. If we look at this network, we can see that this is the normal course that occurred, takes a browser downloads this index.html file. It Dame features the external one dot js file. And then surprise, surprise, it fetches the external two dot js file. We know this, this makes intuitive scenes and it's happening sequentially. But what happens now if, say, this external two dot js file was very important to us and we wanted that feature first. What would this look like? Let's go back to our coding editor and leads now. Comment out our external to script. Let's go into our head section and let's write our link tag, or atria F is going to be our external 2.2K JS file. And our relationship here is not a stylesheet. Our Raul has to be preload the signals to the browser that we want this pre-loaded quickly. And of course, we must also tell the browser that we want this to be a script. This is not a CSS file and it's not an image. So we're being very specific to the browser here, fits the strong script quickly. And now what is gonna happen will expect us to break now, wouldn't you? Because what we've done is we've brought this script file at the very top of our fall, and we've told the browser to execute this quickly. So it's going to do this all before our doners even started passing H12 and h3 tags, which of course is external to file should affect. But that's put theory to the test. Let's go here. Of course we can refresh and we can see we're not getting that blue font color for external today's. But what I did want to show you is if we inspect this document, we go the performance and we just sisters. I wanna look at that network to begin with. Let's just zoom in on the area of importance and look at this. Here is where our index file gets paged grass. And on the very, very nice thing it does is it features as external to fall. Only then does it execute the JavaScript one file. And that's just what I wanted to show you there. So preload does it gives you much more control as to what you unfinished. First you can imagine, I mean, we've used now JavaScript, which is a bit stupid to use preload in this instance. But if you had an image that you wanted to display very quickly on this page, by all means, use preload because it tells the browser that you, as a developer want to prioritize debt, resource. Hooper Bank scenes. Let's move on. 21. Recap - where can you place JS code: We've come an incredibly long way, well done for getting this far. I hope you've had a lot of fun. I hope you're enjoying it. But that's now just quickly give a summary of what we've done and where we can place our JavaScript code to speed things up. I've split it up into six main categories, right? The most obvious number one is you can place your JavaScript code anyway, but they just need to realize that you are going to be blocking the DOM at that point, your parser gets to your script. And if it's a very simple site, this may be perfectly fine implausible. Two, we can place our JavaScript below the main DOM, directly above our closing body tag. This is website 101. This is what we've all been told to do. And although it's good practice to do this at, might be sub-optimal. And I say that because think about what it is that's going to be happening when you put that JavaScript at the bottom, you would agree with me that before the final Marina, before the final paint your screen, those JavaScript files have to be executed, don't they? For those reasons, sometimes placing the JavaScript file directly above your closing body tag isn't quite the most optimal thing you can do. Three, if your JavaScript code doesn't rely on the dom, we can use the async attribute. So resist mean will this just means if your code doesn't rely on an add-on being loaded and it runs Moore's part of Team or things for other scripts in your document, then you can place the script at the top of your page with the async attribute sit on it and your browser will determine when the most optimal point is for it to execute that file and it will featured in the background. Remember, asynchronously how caused that. And number four of our JavaScript code does rely on our DOM being fully constructed, then we can use differ. And the benefit with using differ is that it holds off executing that JavaScript file shares before the moment of DOM content loaded event occurs. Well Clyde, you might be asking, isn't this just the same as placing our JavaScript blow the DOM directly above our closing body tag. And it almost is a sand is a very good question. But with deferred, Remember what we're doing. We're allowing the browser to fetch JavaScript asynchronously in the background. So by the time that Damas fully loaded the JavaScript files already there, then it can immediately execute. Whereas if we just place it above the closing body tag, remain what happens then? Well, your browser's pause or conflict any other file when it hits that script tag. Cool. Number five, if you really want to be specific and these don't quite give you what you want. Then you can build your own custom load event. And you've obviously got a few different methods. We have seen that we can add our own events to the window object called load. We've done that. We've seen that it's been awesome in red. And in the last one is number six, and that is preload. And preload gives you a lot of flexibility because it allows you to tell the browser to download and cache a resource, like a script for a style sheet as soon as possible. So it's very helpful when you need a specific resource a few seconds after loading the page and you want to speed up the critical rendering path. Remember this with the preload, this is a very important point. The browser doesn't do anything with the resource after downloading it. By using preload. Scripts aren't executed. Style sheets onto applied. They are just cashed so that when something else needs it, it's available immediately to think about preloaded as literally just prefetching its utility in the browser. Hey, get this resource as quickly as possible. So in our code needs it, it's their hope it's making scenes. And again, well done for getting this fall. I'll see you in the next section. 22. Putting it all together: We really have come a long way Heavenly ashore right now. You kind of appreciate a lot more what happens in the background in terms of the critical rendering path. But so far we've taken a very simplistic few in that. We've just assumed with the browser hits that script tag, that everything else is paused and blocked to a large degree. That's true in the scenes that JavaScript is still synchronous, meaning your JavaScript files are executed in the order they appear document. And when your browser is executing that JavaScript, the parsing is blocked. So that is true. But it is a little bit more complicated because the guy sitting behind Google Chrome and Safari, actually Internet Explorer at the time, they thought they must be more efficient ways of doing things. For example, when the browser is executing JavaScript, they kinda set a thinking, well, gee, why caught the browser that has big capacity distort, featuring additional files from the server. As soon as its script has finished executing bomb, it can go on to executing the next line of code immediately. And this is what I want this to be about. I want this to kind of wrap everything together and it really will blow your mind because this is kind of just as kind of the glue. And you'll see that what we've learned so far is very valid. This just a little more information that you need to know in order to fully grasp this concept. Cherry on top. So grab a coffee like I hand and sit back and enjoy this lecture. And I hope that we'll just seek, and I hope you'll have that Glossina. 23. Speculative Parser: So let's just recap what we've learned. And I'm calling it the old school way, but bear in mind them all the concepts we've just learned still do apply. So it's not that we've learned all these things for nothing. It's just that this a slight nuance with new browsers have, which we'll get into shortly. But let's look at what we've learned so far. We know that if the browser came across a script tag, it would execute that script tag right away. And of course, if the script is external, then the browser would have to download that script from the server first. And back in the old days in order to execute a script, pausing had to be pools that had to be blocked, and would only start up again after the JavaScript engine had executed code from a script. So what did this look like? Well, we've got HTML and JavaScript, and we know that your DOM will start being constructed. And when you pass a hits that script tag, we know JavaScript has to be fetched and the number has to be executed. And during that process, the DOM is paused. We've seen this, we've proven this. And only after JavaScript is executed, Can a DOM continued its construction process. Cool, all is good and well, the question you probably have is, why did the parsing half to stop? Well, the reason is, is that scripts can change both the HTML and the DOM. How? Well, for example, we all know that document create element method that can add nodes to the DOM hand to change HTML, you can add the document.write script. It's notorious because it can change the HTML in ways that can affect further parsing. The point I'm trying to make is that scripts can query something about the DOM. And if that happens while the DOM still being constructed, it could return unexpected results. And this was the logic behind pausing DOM construction when ever a script tag is encountered. What okay, so that is the HTML, but what about CSS? Well, we know that JavaScript blocks the parser because it can modify the DOM, but CCS doesn't modify the DOM, does it? So it kinda seems like there's no reason for it to block passing, right? Well, not so fast. What if your JavaScript script, OSC school style information that has not yet been parsed. The browser doesn't know what the script is about to execute. For example, your script may ask for something like the DOM node's color or a display property to become a block. And of course these depend on the style sheet, or it may expect to access to CSS on directly. And because of this, CSAs may block passing depending on the order of your CSS files, JavaScript files. And usually, I don't say always, but usually we place our CSS files before our script tags hand if they are external style sheets placed before scripts, didn't the construction of the DOM and CSS on objects can interfere with each other. When the parser gets disk script tag that DOM construction cannot proceed until the JavaScript finishes executing. And the JavaScript can't be fully executed until the CSC says downloaded, parsed and the CSS on as available. So how does this look like? We've got our HTML and we have our JavaScript. And again, we know that the DOM starts being constructed. When it hits that JavaScript script tag, the positon has to reach the JavaScript file and it has do them execute that JavaScript file and during that execution process in pitching process of parser is blocked. And only after the execution of JavaScript can a DOM continue. But how does CSS come into the picture? Well, we know CSAs has to be fetched from the server. And then as soon as it's brought back, we know that the CSS on is constructed and during the construction process, JavaScript is blocked. Heavy. Got it. So it's a case that JavaScript blocks, DOM, put cs is blocks the JavaScript execution. So in a way, the CSS does affect the DOM construction, but it's indirectly, another thing to keep in mind is that even if the CSS doesn't block DOM construction, but does block the rendering because the browser won't display the final render until it has both the DOM and CSS. Ominous because pages without CSAs or just ugly man. If a browser showed you a messy page without CSAs, and a few moments later snapped into Style page shifting content and it's sudden visual change would make a turbulent user experience that would just fit, just wouldn't be nice. So we've seen all this. This is the current situation. But the future is here. Blocking the parser whenever script is encountered is slow. It means that every script you load delays the discovery of the rest of the resources that are in your HTML. In this whole process that we've just been talking about was known as sequential script loading. Sequencial script loading. What does that mean? Well, it means it happened in sequence. For example, if we had two script tags and we had one image file, what was sequential script loading all about? Well, your parser would get to that script one file. They could, they'd have to fetch it and executed. We know that your possible Damon hit script. That would then have to fake that and it would have to execute that file, but it could only do so after the execution of script one. And of course that gets to your image techniques. And in the parser can go and fetch it from the server and display it to your screen, but it could only do that Of the script to was fetched and executed. So this is what I mean by sequential script loading. But the good news is that this changed in 2008 when Internet Explorer on I'm old-school, they introduce something they called a lookahead downloader. It was a way for them to keep downloading the files that were needed while the synchronous group was being executed. Firefox, Chrome, Safari were soon influenced by this and they followed suit. They basically copy them because I was such a great idea. And today most browsers used the same technique that they just call it different things. Chrome and Safari have the preload scanner. Firefox calls it the speculative parser. I dislike the name speculative posture, so I'm going to use it in this. Ok, so what's that deal with all of this? What is the logic? Well, the idea simple, even though it's not a 100% safe to bold the DOM while executing a script. Y not still parse the HTML to see what other resources need to be retrieved. Discovered files are then added to the list and they start downloading and the background on parallel connections. And this is awesome because by the time the script finishes executing, those files may have already been downloaded. So your browser can immediately start executing the next line of code, x_max scenes. And just FYI, why is it called speculative parsing? Well, it's called speculative because That's kinda possible that the script can change the HTML structure completely. Remember, free right, document.write. We replace everything in the DOM with what's in those brackets. So this would just result in wasted guesswork by the browser because it's going to potentially fh files in the HTML tag won't be needed anymore. And he's, while this is possible, that's not common. And that's why speculative parsing still gives better performance improvements. So to recap, the new way of downloading requests is known as speculative parsing. And this manner of resource loading delivers a significant performance boost. And you don't need to do anything special to take advantage of it. But straight out of the box, bats as a web developer, knowing how speculative parsing works can help you get the most out of it. So how does it work more? We've got our script tags and our image, right? We've seen this example before. And your posture is going to hit that script one js file. It's then going to look ahead and it's gonna go, hey guys, there's also a script to JavaScript file. And it's going to go even further. And it's going to identify that this also an image one file that needs to be fetched. So what's awesome is that then can fetch and execute the script one js file. But at the same time it can go and fetch that JavaScript to file. This is the beauty of speculative parsing at stall con executed. Remember that stole can't executed at stall synchronous, that it can fetch it in the meantime. So then when the script one has finished executing script T2 can then execute. And awesome thing with this is that by the time that's all happened, your browser would have already fit that image one file. This is known as speculative parsing and it's awesome. So we know the main advantage is that this speeds things up. And what kind of things can the browser preload? What kind of things are subject to speculative parsing? Will all major browsers preload scripts, external CSS files and images from the image tag. They are limits, However, as to how many files of browser can download in parallel, right? They are limits, and the limits vary between different browsers and depend on many factors. Like, are you downloading a file from one server or multiple servers? And are you using HTTP or HTTP protocol? And before we finish off this lecture, I just want to drive home a few important points. One, all the scripts are stole synchronous and blocked the policy. Having the speculative parsing doesn't magically change or JavaScript to asynchronous execution. That's important to get this. And not all scripts or equally important for the user experience, right, such as those who are tracking and analytics for example. So what does this solution? Well, the solution is to make it possible to load these less important scripts asynchronously. And this is why differ and async were introduced. They give us developers a way to tell the browser which scripts to handle asynchronously. These attributes async and defer, that both tell the browser that it may go on parsing the HTML while loading the script in the background, and then execute the script of thread loads. So this way the script downloads don't block DOM construction and page rendering. The result is that the user can see the page before all scripts have finished loading. Cool. So then what is the difference between the fern async? Well, the difference is when they start executing the scripts. Fu was introduced before async and its execution starts off. The parsing is completely finished, but before the DOM content loaded event is fired. So in other words, it guarantees that the scripts will be executed in the order they appear in HTML and it will not block the parser. Okay, cool, let's defer. But then we've also got async, async scripts execute at the first opportunity after they're finished downloading and before the window load event is fired. So this means it's possible and likely that scripts will not execute in the order in which they're pn HTML because now it's a race against time, right? The second script tag is fh before the first. The second script tag will be the one to be executed first. So this kind of means that they can interrupt the DOM building process. Well, I really hope you've enjoyed this lecture. This is it brought everything together. We've, we've seen how important it is to place your JavaScript code in your files in a logical manner. Sometimes you don't need him scripts to block the DOM, in which case we need to use the for an async because it allows us to build a DOM quicker, that CSS on quicker and the render tree quick as so we can get it to the user as fast as possible. Hope you're having fun. I really enjoy the staff and I'll see you in the next paycheck. Don't give up. Go grab a coffee and let's keep going. 24. Outro: We've done a lot. I've actually, I've got a nice cup of tea in my hand normally as coffee, but I just felt like T burner. It's weird, strange. Walden, we've been through a lot And by this stage we understand how the browser features Dodd from a server. Art has to then converters bytes, two characters, two tokens to nodes. Remember, and then a constructs that dominant CSS. And those are combined to form the render tree. And the range tree then has to go through a layout and painting process. And that whole process is referred to as the critical rendering path. And this last section is about optimizing this critical rendering path. Because think about it, greenie, their page to be delivered to the user as fast as possible. Not only does this increase engagement, but also results in more page views and better conversion, which is what you want when you build a site. So this section is going to be phenomenal. We're going to start with a very simple example. And then we're going to start building up our patch when we'll be adding more resources, adding scripts, any JavaScript. And then you're going to see how to assess are bottlenecks and how to improve performance. And we have kind of done this. It's true when we started looking at the performance tear, but look at the event logs and we looked at what were render blocking resources and we kind of solved those as well. And you know, we've just come from solving them by using async defer and JavaScript media queries with CSS, etc, etc. But this section's going to take a more practical approach because there are better ways to do it. And then just looking at the event log and hacking that way. And it's very important to understand that, which is why we went through it. But there are better ways. So this section, we're gonna be looking more at the network tab, understanding how resources of pitched serve and how long a particular resource takes to actually get executed. So that's one thing we're going to be looking at. We also going to be looking at how to order top edge in a more streamlined and efficient way. And then motto and a few bonus lectures. Yen, so hope you enjoy it and go grab a coffee, go gravity, and I'll see you enough.