*NEW* Speed Up Webpage Loading 2021 - Part 3: How is the DOM constructed? | Clyde Matthew | Skillshare

Playback Speed


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

*NEW* Speed Up Webpage Loading 2021 - Part 3: How is the DOM constructed?

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

Watch this class and thousands more

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

Watch this class and thousands more

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

Lessons in This Class

11 Lessons (55m)
    • 1. Introduction to the class

      1:29
    • 2. What does this class cover?

      1:52
    • 3. 4 steps to how a browser renders a page

      4:01
    • 4. How the Browser works

      12:56
    • 5. CRP Summary

      2:55
    • 6. Constructing the DOM (byets and characters) - part 1

      3:22
    • 7. Constructing the DOM (byets and characters) - part 2

      3:48
    • 8. Quick recap

      2:14
    • 9. Performance tab - introduction

      10:54
    • 10. Call tab - introduction

      3:52
    • 11. Bottom up & edge tools - introduction

      7:21
  • --
  • 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.

15

Students

--

Projects

About This Class

WELCOME TO THIS SKILLSHARE CLASS ON HOW THE BROWSER CONSTRUCTS THE DOM

THIS IS PART 3 OF MY COMPLETE WEB SECRETS SERIES

What we cover in this particular class?

We will cover of ton of information in this entire series, but for Part 3 we're going to start talking about the Critical Rendering Path. The CRP is basically the sequence of steps the browser goes through to convert your HTML, CSS, and JavaScript into pixels on the screen.

Optimising web speed is about understanding what happens in the intermediate steps between receiving the HTML, CSS, and JavaScript bytes and the required processing to turn them into rendered pixels. And in order to become a brilliant coder, we need to understand the steps the Browser goes through in fetching data from a server, all the way to displaying the content on your screen.

The first part of this process is the construction of the Document Object Model - or the DOM. And this is what the entire class is about. When the browser first hits the page it downloads the HTML. It then starts building up the DOM tree. Each tag in HTML represents node inside the DOM tree which has all the information regarding it.

But let me not jump ahead of myself. 

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 Critical Rendering Path 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?

Absolutely.

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

WHAT ARE YOU WAITING FOR. LETS GET CRACK’

Meet Your Teacher

Teacher Profile Image

Clyde Matthew

!false | funny, because its true

Teacher

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!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
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.

Transcripts

1. Introduction to the class: Welcome back Skill C students to yet another class. And this class, yes, it's following on about the rendering process, the critical rendering path, how does your browser display content to the window? And this clause is going to be interesting. And the reason it's interesting is that the browser doesn't live in isolation. There is a lot of things happening in the browser. In fact, is a lot of software. Developers just call this engines. They a lot of engines in the background running. For examples, these the JavaScript engine V8 on Google, but there are also other engines, is the rendering engine, and it's also the browsing. And most important of these engines for this course is the rendering engine. Engine. How does a software process information displayed to the screen? So in this class, we are going to be looking at perhaps the most crucial aspect of the rendering engine. And that is the construction of the DOM. In, in the next class, we are going to be talking about the construction of the CSS on. Many people even know that exists. And that's why I'm so I'm so excited and other stuff. And yeah, this is for all levels, herpes sticking along with me. We've already been through a few clauses together. Keep sticking with me. It only gets better and better. But anyway, and I'll see you I'll see you. 2. What does this class cover? : We have gone through a lot, haven't we been awesome and Walden for getting this far? I mean, really it is amazing. And what's the next step from here? Will we've learnt about requests, we've learned about responses with learns, how we seen those. We've learned about Ajax. It really has been awesome, learned about packets. But now I want us to go a bit further. Someone's left a cochlea ever look like are saying, now one has to get just a little bit further. What you need to understand is that JavaScript's JavaScript doesn't live in isolation. And what I mean by that, other execution contexts are their environments. They exist alongside JavaScript. And part of that broader execution context is the rendering process and the reading process. Also not many people know much about it. And what's really cool is that in this section, we're gonna be going over the DOM. We're gonna be going over the CSS on which not many people know even exist and begin to explain how your browser actually ranges content that it receives from a server onto the screen with their phone or their PR laptop. How the habit, it's gonna be really fun. So please bear with me. Honored, can seem quite daunting news topics. But in order to truly become a grandmaster in web development, you're going to notice. So enjoy the station, had fun. Stick with me and the section, it is going to be MHz. And enjoy going into code, go to coffee, and I hope you have fun. And just in case you were wondering, this actually was my cook. Enjoy it. I'll see you now. 3. 4 steps to how a browser renders a page: All major way browsers comprise subsystems that suited me speaking about before. And least subsystems helped put the entire rendering process. These systems are involved all the way from accepting the waves URLs to displaying web content on the screen. And they do this by making network calls, fetching resources, parsing the HTML, CSS, and JavaScript files to create objects. And these objects are used to render data onto the screen. And these all combined all these processes and all these tasks and actions to create wonderful websites for users. And this whole process is what I'm referring to when I say rendering. In other words, the rendering process is how your browser shows a webpage. And at the crux, a web browser loads files and displays them to you. In other words, the browser figures out what to display to you based on a file type it receives. But before we go on, I just want to reiterate this point. When you code in JavaScript, you're not coding in isolation. Set your JavaScript code interacts with other environments, a whole lot of other execution contexts, a whole lot of other environments. And this is how I like to think of how everything fits together. You don't only have one engine, like a seed, your JavaScript, the JavaScript engine that works in conjunction with other engines and with other environments. Or what are they? Yes, you have the JavaScript engine V8. And if you've done my complete JavaScript grandma Stir cause you'll be very familiar with how JavaScript engines work and what they are bad. We also have other engines. We've got one rendering engine, which we are going to be talking a lot about in this course. And of course, we've actually got what I like to call the browser engine, aka the browser. And all the processes that happen within that key for us to understand right now is this rendering engine. This rendering engine lives within the browser and just take a step back, does realize all the rendering engine is, is that software and that software that draws text and images to the screen, right? Kinda make scenes. So if it is just a piece of software, you will have no difficulty in conceptualizing that. They can be many different versions of software and people out there creating the software so they are not. Examples of layout engine's include gecko inch webkit, but the one of the most popular ones is blink. Blink is just the rendering engine for the Chromium project for Chrome. But let's move on. This rendering engine is responsible for displaying requested content. Okay, but how does it do this? Well, I can break it up into simple steps. The first step is that the rendering engine has to create the DOM and CSS on. We're gonna get into this, so don't worry about what these mean now for the next three steps all involve the rendering tree and it has to go through different phases. The first phase is the construction of the rendering tree. The second phase is the layout of the rendering tree. And final stage is the painting of that data to the screen. And that's it. That's the way I like to think about how this whole rendering process works. Don't worry, I'm gonna get into each one of these steps in much, much greater detail in the upcoming lectures. But for now, take a step back, understand these different contexts, environments. There's different execution environments happening all the time on your browser. But the rendering engine is key to being an awesome developer because it allows you to stop bottlenecks that allows you to speed up fetching data from a server and displaying to screen. So this is really going to be awesome for you and it's going to teach you a lot. So I hope you have fun. Let's get cracking. 4. How the Browser works: Okay, so how does the browser work? Will, I'm going to try and explain it to you the way I like to think of it. And you can see I've broken it down into four easy steps and hope is intuitive. It is to me. The first thing the browser has to do is it has to fetch data, right? There's Jupiter from somewhere. That dotted line has to be processed. Once it's processed, the browser can then display it to screen and make this whole process easier, can implement storage functionality. So at a very high level, that's intuitive, right? And it's important to note that browsers such as Chrome, but many others, if not all others, run multiple instances of the rendering engine, one for each tab that you have open. In other words, so each tab you have open is running in a separate environment, a separate process that's without further ado. Let's look at each one of these steps in more detail because it is nevertheless easy, right? His voice more detail once we start truly wanting to understand what it is the browser does. Facially, we've just said the browser has to fit something, right? What does it fated? Features, things like HTML, jpegs, PDF, CSS, JSON, even JavaScript. And wait, is it fetch the starter from Will that we, the network layer comes into the picture. The network layer accepts the URL entered into the address bar from the user. This network layer uses HTTP FTP protocols to fetch resources. And once it features these resources, it feeds daughter to the process subsystem called the rendering engine. And we're gonna get into the shortest. I don't wanna talk about it here. Normally gives the rendering engine there's data in bite size, and it does this to improve performance. The network layer usually looks for any local cache for the new requested URLs, and nothing's found at history. Unfortunately, create a brand new HTTP packet. I don't know how advanced you are watching. Those caches are great for the quick response times and saving network requests for regular visits. And if the requested website does implement a cache, copy of their data is made in app cache or service workers for next time, for an exam, a visit in a request doesn't have to go all the way to the server, can just use your local cache. So this is the network layer. And to summarize, the browser initially looks FOR ME cash available on your local memory for the requested URL. If it's not found, the network layer has to create an HTTP packet with a domain name for requesting or web resources over the internet. And the network layer plays a huge role in user experience. That can be a bottleneck in web performance. If you don't get this right, because browsers will then have to wait for the remote data and the content to arrive. And various techniques can be used to reduce this impact on the user experience. We're gonna be getting into this a bit later. Who her case. So it's the act is the Fitch process and I hope it's making another seems to you right now. Once it's finished the daughter what happens? Well, that's right. The daughter has to be processed. So let's talk about that. And as we've just said, after the browser has fetched something, it has to then process that information. And remember, the network layer has provided the daughter to the browser at this point, this is where we are now. The browser Dean needs to take this data and it has to feed at the layers. What are the layers? And we're talking about where you can see them in the, on the screen, the rendering engine, that JavaScript engine and the UI backend. These all separate processes, separate layers that have to work together. Let's briefly talk about each one. The rendering engine. The rendering engine is responsible for displaying the requested content. That's good to know that the rendering engine Candace play any kind of data. In fact, it will display data according to your specified content_type or mine. For example, HTML images, XML, CSS, JSON. Next, citric Sandra. Many rendering engines are available, but they usually written in C plus plus. And remember what I said? I said that different browsers can use different rendering engines deny. So Chrome and Opera use blink, for example, but Firefox users, gecko, Safari uses webkit, et cetera, et cetera. And for any webpage we visit, a key part of the rendering engine is the HTML parser. For example, if the requested content is HTML, the HTML parser within the rendering engine has to pass. In other words, it has to read the HTML and CSS and display their past content on the screen. And once the rendering engine has passed the HTML and CSS, a render tree object is constructed. And once the screen the tree is constructed, it undergoes the layout and the painting process and displays the output on the screen. Remember, in the previous lecture, we went through the four stages of how the rendering process happens. The first stage was the creation of the render tree that dominant CSS on the second, third, fourth stage were all render tree related. And the first part was the construction of the render tree. And the second third was enshrined the layout and the painting process. And that's why I've put the layout and paint process within the rendering engine because they are all intertwined. Let's quickly look at the layout 100 in Baghdad. After the render tree is created, the browser starts the layout process and the labour process actually is very simple. It just calculates the exact dimensions of where your elements go on the page. And that's all there is to the lab process is not that complicated as you've then got the painting process. Now that we've got the layout, we need to fill it with style rather. Sorry at the cracks, the painting process includes fooling the layout who style attributes like color, background and other CSS properties. We have it. We've done quite a lot heavenly. But just remember what we've spoken about. We are talking about how the browser processes information and displays it to your screen. Remember, we spoke about the first process being fh, fetching the data from a server. We on the second process now net is, the browser, has to process all the data that is Literacies. And it does this by sending their daughter to different layers. The layer we've just dealt with now is the rendering engine that remember the Otherland. That's right. There was no JavaScript engine. This is the subsystem for parsing JavaScript code to machine code and then executing it. And these JavaScript engines can be standard interpreters or just in time compilers. But these anions are usually interpreted as one of the most popular engines is the Google V8 engine, which is again written in C plus plus. But Safari uses JavaScript Core Firefox users spider monkey, each user's chakra and Internet Explorer uses chakra.js script. And these engines include two components, and memory heap and a call stack. And I don't want to jump into this too much detail now because it's, it's, it's beyond the scope of this course, but it's always nice to have a very high level understanding. So a memory heap is just a memory is allocated for variables and functions in other JavaScript elements, the call stack, on the other hand, is, it's kinda just simply a queue of a stack of frames or sequential steps executed by the browser. And you probably already know this, but JavaScript is single threaded process. And each interior execution stack is a stack frame. That again, this is beyond the scope of the course and I want to get into it now to some very high level, this is what the JavaScript engine does. And remember there were three distinct subsystems involved in processing all the information. The one was the rendering engine we spoken about. The second one was the JavaScript engine, which we spoken about. What's the third one? Do you remember? It's the UI backend. And UI backend is used for drawing basic widgets like combo boxes and Windows to your browser. And this backend exposes a generic interface that's not platform specific. And his lectures getting long already, so I'm not going to harp on more bath you IBEC. And if you want more information posted on the Q and a and I'll help you. City we go, we've looked at how the browser features data. We've looked at how the browser processes that data pertaining to the different layers, to the different subsystems. And now what? Well, I'm sure you can guess there looking at the screen now we kind of ready to start displaying their daughter onto the screen. Right? And this is the end goal and the UI and the browser engine are responsible for this step on what I mean by the UI in the browser engine. All the user interfaces, just the visual appearance that you and I have when we go and visit the browser. He have a view port and the UI communicates with other layers within the browser. For example, when you type in your address bar, that URL that then has to communicate with the network LAN. Makes sense, right? And in our specific standards that govern the UI, more important to us is the browser engine. And this provides a high level interface to the rendering engine. And its job is to pre much load the URL. Help the user navigate around. It also helps with displaying JavaScript alerts and progress bars to the user. And the browser engine also helps for querying and manipulating the rendering engine sittings. And the final layer is storage. To improve speed, storage is crucial. Browsers have a small amount of storage capacity. So implementing cache and data storage just makes our experience much quicker and just bear in mind this daughter storage layer is a persistence layer because the browser usually has to save all sorts of data locally, such as cookies, for example, bats. Bear in mind. Persistence is achieved through various browser APIs. Some of them include things like local storage, session storage, cookies, Web SQL index, DB file system App Cache and service workers. And what all these things will. Again, I don't wanna jump into too much detail right now. But local storage and session storage of key-value pairs, they can store any JavaScript object in function in the browser. So it's pretty useful. Session storage, persist the data on the browser as long as the website session is active, local storage is kind of like the memory on the browser. It persists, daughter, keeps the daughter until it's cleared or altered explicitly by the user or JavaScript code. And the rules and things like that. They govern certain aspects of how you can use the storage. For example, the limits, I think it's like five megabytes per object, 50 megabytes per system or that kind of stuff. But anyway, like I said, I don't wanna get into detail yet. And cookies, water, they, cookies are quite simple actually is just a collection of key P values and they just stored on the browser's memory. They sink back and forth between the client, a-k, the browser, and the server. That's because of this back and forth. They are expensive in terms of performance and they're the least performance of the daughter persistent methods. However, they are useful when privacy and security come into the picture. What about Web SQL, index, DB, and file systems, while they all have the ability to store data on the browser depending on size, performance, and necessity. App cache. What's that? Well, that was introduced in HTML5 and it stores website static content and it serves UI content during network downtime and what a service workers will. Those are Google's new way of caching website data for offline usage, it has significant features compared to app cache. So again, there's just a very high level summary. And there you have it. Don't get lost in all the detail. Up, boys love taking a step back. And you can really think about the whole process is being very intuitive. Like I said, just think about it with these four processes running. Each time you visit a page for browsers to fetch the data has to process it at S2, then display it to the screen. And to improve performance that usually implements storage capabilities. And that's it. And we're going to be talking into more detail and do some of these elements in the upcoming lectures. I hope you've had fun. This one hope has been intuitive and I look forward to doing some more coding with you. 5. CRP Summary: We've done a lot, but we're gonna keep going and honest to stop. And I want to now show you how the browser goes from a source HTML document to displaying a styled and interactive page in the viewport. And are we keep referring to this entire process as a rendering process, but the more correct technical terminology is to call it the critical rendering path. So right now, I just want us to take a step back and I want to show you what the critical rendering path looks like at a very high level bird's eye view. What is the first step or the first stage involves a browser parsing the document, your HTML to determine what will ultimately be rendered on the page. The second stage involves a browser performing the actual render. So how does this look? So we know we've got HTML. This is what you and I are used to writing. What happens next? Well, the first step is for the rendering engine to parse that HTML document and convert dead code into DOM nodes in a tree called the content tree. But at the same time and not many people realize this. The engine will also pass the style daughter. The styling information, together with the visual instructions in the HTML, will be used to create another tree, the CSS on tree. And finally, the DOM tree and the CSS on tree are combined to form the render tree. So that's our goal. Our goal is to get from the HTML which you see to the render tree and to get to that in state, but the DOM and CSS on have to be created. And what's our next goal? Will the next goal is to actually display that data on a screen. In our case, we've got an H1 tag called critical rendering path that needs to be displayed on a browser. How does it happen? We've seen the first step is to construct this render tree. And after the construction of this tree, it goes through a layout process. This means giving each node the exact coordinates which should appear on the screen. And the next stage is painting. The render tree will be traversed in. Each node will be painted using the UI backend layer. And it's important to understand that this, the entire process is gradual. For better user experience, the rendering engine will try to display content on the screen as soon as possible. It won't always wait until the HTML is parsed before starting to bold and layout the render tree, parts of the content we passed and displayed while the process continues and the rest of the content keeps coming from the network. And just remember what I said. This whole process is technically called the critical rendering path. And it's important for us to understand it because it'll make us better developers. 6. Constructing the DOM (byets and characters) - part 1: We've seen that one of the most crucial aspects to the critical rendering path is the construction of the dom. Dom stands for the Document Object Model. And the DOM is just an object based representation of your entire HTML document that has some differences to the actual HTML document. And we'll see that in the course. But the DOM is sensually and attempt to convert the structure and content of your entire HTML documents into an object model. And why does it do this when it does this, so that that object model can be used by various other programs and software like JavaScript, for example, the objects structure of the DOM is represented by a node tree and its so-called, because it can be thought of as a tree. This tree will have appearance damned branches out into several child nodes. You can kind of think of it as the parents Damon being the root HTML element and all the child branches of a nested elements and the leaves or the content within each element. It's kind of how you can picture it. And why is this important? Well, remember what we said when comes to the rendering process, the first step is for the browser to render the DOM. Remember there were four processes to the whole render process. The dominant CSS on with the first step. Here we just talking about the DOM. The $1 million question though is, how does the browser do this? And this is where I'm gonna start blowing your mind because this is gonna get not interesting. Let's figure out how the browser actually converts your text file into the DOM. So let's start at the beginning. You've got your computer and you computer only understands 1's and naughts. If you compute a good talker, probably say something like, I only understand one S and 0. Please send me data in by this makes scenes right? So it means that our HTML, CSS, and JavaScript to be sent to the computer in bytes. So all that means is that we have to take our files that we've written in takes that needs to be converted to ones and zeros and he's to be sent to your computer. You computed in goes UP. I have my 10. But now the browser doesn't come this stand. But now, and this is a problem. Now your browser doesn't understand what it is, because your computer has to tell the browser would all those ones and zeros mean. So in other words, you computer they needs to convert the bytes into characters. I need to convert bytes into characters. Your bites are what your computer can understand. Characters is more akin to what the browser can understand. Your browser translates those bytes to individual characters based on specified encoding of the file. For example, a very common encoder is the UTF-8. And that's why in our HTML file we actually specify that specific encoding type who are great. So you would think we done, but we not, unfortunately, we're not done yet. The browser now has a whole bunch of characters. But what do these characters mean to a browser? It means nothing. It's just takes, so is something else that has to happen that see what that is in the next lecture. 7. Constructing the DOM (byets and characters) - part 2: Fisher, Chicago Coca-Cola, Coca-Cola, Coca-Cola, Coca-Cola glucagon, cool Klocal, OK, cool, cool, cool. We're at the point where we have st are bytes to the PC. The browser engine has been converted those bytes into characters. But now what's, you know, from a browser point of view, sitting with a whole bunch of characters means nothing. In fact, astronaut browser, and this is what it had to say. But what do all these characters mean? And that's exactly why we need to keep going. And the next stage of the rendering process is to convert those characters, two tokens. And I like to think of the tokenization process as the browser's way of structuring all your characters into meaningful knowns, into meaningful pieces of information. Basically takes your characters and it stretches it into a way that the browser can understand. So conceptually, just think about a token as a piece of your HTML page. And each token will contain information about each HTML tag. Like a paragraph tag, for example, will hold certain rules associated with that. So how does this all work? Well, every time you Coding and index page, you save it with what extension? That's right, you save it with a dot HTML extension. And every time we do this, we signaling to the browser and then link that to hardware to say actually signaling, signaling anywhere. When we have the dot HTML extension, we signaling to the browser to interpret that file as an HTML document. And how does the browser interpret the document will in coding talk, we just use the word pass. So the browser parses that document. And in the parsing process, in particular during tokenization. If we start in every end, HTML tag are accounted for. And important to us is that each tag, each token has a specified set of rules attached to it. And you might be sitting there going, cool, okay, I understand, but wait, all these rules come from Hadoop browsers know what rules to apply to each tag. The oxygen xat is that we have an organization called the W3C persist the World Wide Web Consortium and nave develop the HTML5 standard specification. And what that means is that it's just a global set of rules at browse apply. So just remember, each token has a special meaning and its own set of rules. So we are, we know, okay, cool mole of bytes that we seemed to the computer have been converted to characters. There's characters on our converter, two tokens, bats, we are not quite done. Hello Hannah, seems like this never-ending, but we always do. These tokens have now been created, but they're not structured yet. We haven't structured them. We do so by converting these tokens into nodes. And those nodes are structured in a tree-like structure that we've discussed. And the awesome thing is, is that this is the DOM. Once this trees created that tree is the Dom. Cool. So we've done it. And before you and I forget what we've just discussed, very high level, Let's just recap. We seem bytes to a computer. Your browser engine then convert these bytes into characters, but this isn't enough. Your browser has to then convert these characters into tokens. And in order to organize these in a structured way, nodes are created and this is what creates the DOM. That is awesome. But you might be thinking, what about CSS? And it is a very good question when I look at that shortly. But before we do, I just want to solidify what we've learned here. 8. Quick recap: We have learned and epsilon is passion. So proud that you've got this fall. Keep going because I know it can seem a bit academic and can't seem daunting. Thats just to recap what we've done, we start with our JavaScript file. We've talked about HTML and CSS. Those have to be converted into bytes, make scenes because the computer only understands 1's or not. We send that to the computer. But then there's ones in Norths are meaningless for a browser. It's meaningless for any application where a user has to actually have a UI experience. So those bytes have to be converted into characters. We've seen this and the usual encoding type for the actors UTF. But unfortunately this is not the end because your browser doesn't understand text. That's just mumble jumble. So your browser then has to go through those characters and it has to go through it tokenization process. And basically they, tokenization process is just structuring or their texts. And certain structures have certain rules, like a paragraph will have a different rules and imaged as the last step is to convert those tokens into nodes. And this is what forms the basis of the object model. So have you got there bytes into characters, into tokens, into nodes. Process that your browser has to go through every single time you visit a webpage. Ok. So hope you are getting it now. It is not that difficult. So with this process, your HTML is converted into a dump. Your CSS is converted into a CSS object model, or CSS for short, that these two data structures are completely independent. Even though these two data structures are independent, they are combined to form the render tree. And once that render tree is created, the layout and the painting process can begin. And right now, I, she wanted us to open dev tools and I want us to see these things in action. So let's look at a practical example. Let's jump into it. 9. Performance tab - introduction: In order for us to get a div tools on taste, something We need a site to taste drought. And yes, we could just go into some random site like Google.com. The only problem that I had with that is that there are a lot of extra plugins and JavaScript calls that we now can understand. This is not going to be that intuitive. She's going to look like a whole lot of miss. So I thought, why don't we create our own simple website. That's what I've done here. I'm going to show you kind of high-level does the code that I've done anymore jumped devtools and we'll actually see the critical rendering path in action. Let's have a look. So you can see here, this is my simple HTML page and the first resource it has to fetch is the styles.css file. If I just show you what that looks like, it's just a very simple file in. I've got a dark background heating, and you'll see that I've just created a head-on on the side. So a lot of these about creating that nav bar. And so it's a very simple stylesheet is nothing crazy going on and going back to our HTML file, the second resource is to fetches the app.js file. It's going to execute our JavaScript file. And I just wanted to create a simple call stack for you because we'll be able to see this when we are in dev tools. It's a very simple execution file. We just defining a function called my first function. Function executes my second function. My second functioning just console logs proved to the screen. So let's set, it's not very difficult. If we go back to our HTML page. That's pretty much all we have. I've got a header section which contains my entire navigation bar. I've got an image which you and I can just pretend it's an vulgar. I just fetch it from a site called and splashing. And I define the dimensions. And then I've just got on links in the nav bar. So very simple, very intuitive. But let's see how the critical rendering path works on the side. First step is let's head over to our side that's loaded up. And you can see now specifically in image and boom, the images loaded. So they took Eleanor, I'm guessing Nava three seconds. But that's it. That's our site. You can see it's not very pretty, but it is enough for us to look at this example. So let's head over to the dev tools. And there are a lot of things we can do here. But for now, I just want to give you a high-level overview of the critical rendering path. And for that I'm going to be using the performance dead bat. Just bear in mind, we're going to be dealing with the network tab a lot in this course a bit later. But for now performance table B2 sine. So we can click on this performance tab. And the two things we can do, one, we can hit the record button and Amy can interact with buttons. We can refresh the page, or we can just click this reload button, which will refresh the page for us and record that whole entire page load. So let's do that. And remember house sit it felt like it took about three seconds or so, 34 KG. So took about four seconds. They And to get everything done. What is all this? Don't panic, honored can seem daunting. There's a lot of information on the screen and we in the beginning through it slowly and how this is very hard to find online. So I hope you really appreciate the level of effort that I'm going through to show you this, but it's very useful. Fun, once you actually begin to understand what's going on, it's awesome. Let me get into it. The first thing we want to look at is that overview panel, rod at the top, right at the top, that's the overview section. And the two most important things, they are the blue line and the red line. The red line is the onload event. You've got to remember that when your browser features a resource along the way at fires of veins and does this in order for us to define where we want our JavaScript calls to be made. That last vein that's fired as this onload event. And that is when all resources having finished your images, your CSS has been passed. Basically everything is done. That's why we can see here this automotive V_2, two sequences quite a long time, but it's predominantly because at imaged took a long time to receive from an splash. When an image is received, we still not done. That's why I took, you know, we had to wait a bit longer because then the final rendering process has to happen. So that's important, right? And when we refer to the critical rendering path, we kind of, in my mind, I'm kinda referring to their grade line. We want a great line to be as far to the left as possible. We want our page to load as quickly as possible. Kind of obvious. Next thing we can look at an overview panel, others house. And what's really cool about Dave Tools is that we can zoom in. So if we look at this section here, which is the main kind of resource heavy load, we can see that there are few Hampson. And whenever you see humps and, uh, may be very obvious to you already, humps just indicate resource heavy activity. And we can see that the, this with the browser starts fetching or HTML parsing the CSS, executing our JavaScript fetching the image eccentric citrus. That's why there's a whole lot of humps there. So when you look at this overview panel, look at two things. Look at the blue line and the red line, and look at the humps. That just gives you a high level overview of what's going on. Remember we said the red line was onload event Excuse me. Excuse me. So we said that the red line was the onload event. We see that humps or resource heavy activity that I just drew to realize we haven't discussed the blue line. Sorry. The blue line is when the DOM content loaded event is fired, it just triggers the point or defines the point mark. The point with the DOM is reading. And at deny style sheets that are blocking JavaScript execution. So the blue line as when DOM content loaded has been fired. And a lot of us when we developing size, we wait for this event to be triggered before we start implementing our own JavaScript logic, says high-level. Okay, what's the next thing we can look at? Well, you can see here we've got this screen shots chained. And what this means is the browser records screenshots of the entire process. Remember what I said that red line was when all resources have been Fichte. So you can see if we look at our screenshots before ECR images, not day. But as soon as we hit this red line, boom, there's our imagery. So when we go over that on load event, our image is really, we've received all our resources. These screenshots day, not just a useful way to visually see what's been going on. But like I said, it's enough for you just to see the blue line and the red line. And most of the time our aren't even look at the screenshots because you know, intuitively, but with more complicated sites, it is useful. What are some of the other things that are useful for us now? We'll surprise, surprise. The main tab is the main information of all your requests and responses. So that's very useful to look at. And let's just zoom in here and it's just highlight the section and zoom in on our most resource heavy time is on the main tended to things we can look at. One, just bear in mind from left to right as time, okay, your x axis is time. Your y-axis number two, your y axis is, your function calls. And that's all there is to it is not that daunting. The thing to bear in mind, especially when looking at the main tab, is that your browser responds to user input. And it does that by adding tasks to a queue on the main thread to be executed one by one. So this is also where the browser executes our JavaScript. So net, since you can kind of view the browser, is single threaded because in some cases, these tasks can take a long time to run it. When that happens, the main thread is blocked and all other tasks in the queue has two wet. So that's why when we are looking at this maintain, the most important thing to look at is the length of each one of these tasks. The small tasks are good because it means it's happened very quick. The longer tasks are the ones we need to look at and try and efficient ties. Who? Okay, we've done a lot. I don't wanna hop on too much longer. Just what can we look for our members and our site. We had that JavaScript file and we had those two function calls. Do you think we can try and find it? But should be at the very beginning. Do you agree? Because after the browser's fish to CSS, remember we had the script file and we just executed that very, very simple scripts are out imagined it to be somewhere here, which lead to try and find it. And I don't know it is actually, let me just quickly translate into me, start profiling and reload the page again by clicking this button. Very strange. Her homage to say I've been, I've been looking at the screen too long. Services look again, maybe I just missed it somewhere. Now we're the might've just mister I'm not sure if I looked in the right place. But if we zoom in, we can actually see here our function call. And this is what I kinda wanted to show you. Remember Father vector, coding editor and our app.js file. We had two functions. The first function that was executed was my first function, and my first function executed and another function called my second function. And edges console log glued to the screen. And it makes sense, right? So if we go back to our dev tools, we can see my first sanction was a first to be executed debt in turn called my second function which was executed. And that's what I meant by when we scroll out of this and we see this main tab, this is a call stack. These are call stacks. It's referred to as the waterfall stack. But it's a call stack is just one function calling another. And we can zoom in here and we can see our function. My first function calls my second function. And at the very bottom we've got our summary tab and add Summary tab is just a summary of what's included in your range. Your range up here in the overview section. So here our range is tiny and we can see how long each section has taken to complete. But what I wanted to show you here was the event log. Because here you can see my first function, my second function, it has to evaluate the JavaScript. And if you open that should bear a See my first function here. And you can literally see how long it's taken for this to happen, to execute that first function actually took 0 milliseconds. That would have been 0.0.0, something very, very small amount of time. And if you open that, we know that they're called. My second function. In my second function took 0.2 milliseconds, obviously longer than the first function because that's where we had the console log. So this kinda makes sense. And if we take a step back, this is the high level overview of the critical rendering path. We're gonna get into more detail. Trust me. But this Lichter is already getting long, so I want to pause it. Yan will continue in the next one. 10. Call tab - introduction: We finished off here. We finished looking at the overview panel. We looked at the main tab, we looked at kind of how the call stack works. It's quite interesting, IP and join us death, that after recording your page load. And again, you don't have to rely solely on the main section to analyze or your activities. Because Dave tools also provides three tabular views for analyzing activities. In each view gives you a different perspective on the resource activities, the fixing and the loading and the painting, eccentric, cetera. It's quite cool. So what are these three tabs with a very high level when you want to view the root activities that cause the most work, you can use the call tree. That mean what does that mean? Rooted activities. At the very crux of it, the root activity is an activity that makes the browser do work. For example, if the user clicks a button or a click, activity gets fired and event gets fired and neck may then trigger handler veins and so on and so forth. So that click event is a root of aint because it's the root activity is the activity that has caused the browser to start doing work. And in the main section, the root activities are all displayed on the top. So when we start scrolling in here, if you look at our custom function core member, that my first function, that is the root activity. And if you keep going up, there'll be another activity that called it an anonymous function, in this case, my first function. But anyway, the point being is that the root activity is always on the top. And the same is true with us call tree. Let's see what is called tree looks like. Let's, again, let's look at our main activity, right? Or actually let's just go all the way. Let's resume. Highlight in the overview panel the entire enduring process up until unmotivated file. And if we look at the call tree, the we have it, you can view all the roots activities that cause the most work. In our case, 63% of the entire rendering process was done by evaluating JavaScript. And bear in mind that all of this is web sockets and other JavaScript calls that have happened in, in the background. And it wasn't us in order to display this to the screen, the root activity that took 26% of the time is this parsing of the HTML. And you can see the layout process, the paint process took really short amounts of time. But at a very high level of lists, you can start seeing the bottlenecks. So if we see that our JavaScript is taking 63% of the time we can go into here and we can start breaking it down. We can find which function calls are causing the masonry can try and fix it. In our case, it's a very simple sites is nothing really we can do. Enter mind. You bought what route activities are all these top-level items? Inactivity pedal, such as evaluate script, parse, HTML, layout, paint. These are all routes, activities. And the nice thing represents the call stack. Yeah, you can see the call stack. If you want to look at our function. Here it is my first function, and that executes a function called my second function. Today ego, there shows what these missing cortex mean. And you'll notice on here we've got self time and we've got total time. What's the difference? Well, soft time represents the time directly spent in that activity. So if you look at our custom function here, activity took 0 milliseconds, but the total time represents the time spent in an activity or any of its children. So in this case, we can see the children took up all the time and the children of the school's tech of course, is my second function network took most of the time and I've can't seem kind of weird and daunting, don't worry, really. We're going to be getting into a lot more detail other things in this course. I just wanted to give you a high-level overview of this call tree. 11. Bottom up & edge tools - introduction: The second tab we can look at is this bottom, up top. And the bottom tab allows us to view activities. But I'm not talking about only root activities, not talking about any activity that directly took up the most time in aggregate economic saints, right? So if we look at it, we can see here each activity in detail and how much time it took to execute. Just make this a bit bigger. You go, they are all the activities and the time that each activity took. And you can see he has my second function, which took 0.2% total render time. How interesting as us, we've got our parsing of the HTML which is used for the DOM. We've got the CSS object model creation, which is in this recalculates dial. It's quite interesting, lack ego, the layouts. You've got the painting process which, which doesn't take a lot of time. And you can just scroll down spearing very interesting. Linear hen again, you can see we've got two columns, self time, total time. It means the same thing as in the call tree. The soft time represents the time directly spins in net activity, and the total time represents the time spent in debt activity or any of its Jordan. Who is one more tab. So bear with me, keep going, keep going. We've got the event log tip. Now we use this tab to view activities in the order in which they occurred during the recording. So adjusted literally displays not the ones that took the most time. It's the ones that happened in order that the Quinton and again, I'm not talking about routine activities now understood about any activity again. So if we look at the event log, let's look at an action. So here we're looking from the very start to the very entitle, this onload event. How causes. So you can see these are on load event at the very end and obviously it has to go through a lay-up process to finish off the side. Sequential makes sense. And you'll notice here that there is another column now called startTime. This datetime column represents the point at which the activity started relative to the start of the recording. For example, the start time of 18.8 milliseconds for the selected item means that activity started 18.8 milliseconds after the recording started. So if we only want to look, for example, at this RAM one yet, if we want to only look, for example at the intersection here, you can see our veined log tells you how far off the recording, how far in advance that we actually start this process. So it's quite interesting in that it, well, we've done a lot, haven't we? Just a very high-level overview of all these things. Let me just move this ten that lower so you can see, yeah, we've done a lot. Hand MALDI-TOF liner can seem very daunting, but trust me, it's going to be awesome when he started realizing when you do your coding and heart is put onto the screen, it just makes you a bit of development. That's all I'm trying to say. What else can I show before in this lecture, actually the NICU attack very quickly that just shows you or your network requests menu resources that you fetch. So if I scroll here to the very aimed at, sorry, meant at the very beginning, you can see that the very first resource we have to fit is the index file. And you can see that little tiny dots. The amendment. Not really, but you can see there's a tiny, tiny blue dot in the top left corner. There just is an indication from the browser that it's a critical resource, that this is a very, very important resource. It's loading. I think these are color-coded. I think HTML is blue. Zoom out. Might not be. Now maybe it's not color-coded anymore. I think it used to be. Anyway. Let me just show you quickly what this means. You can see that this is big long gray line and these, this kind of block of color, everything before that blue block of color from the start of their grade tab is everything up into the connection point to the server. In other words, everything before the request is sent. And then we've got a light portion and adopt portion. And light portion is Everything up until the point where it equates to seat all the way up until the first byte of data is actually received or TTF-1. But we're gonna get into this later, so don't panic. The dark blue section is what is the actual time it's taken for it to actually download all the content from the server. And that's remaining gray line. What does that? That is just the time we've had to wait on the main thread to finish. So yeah, that's, that's the network requests. You can see it's got our HTML file. You can see here we should have our styles. These are app.js file. So everything is a and what's taken really the longest time, which I'm sure you've guessed by now is this image, this and Splash.com. So you can see how long that took to establish the connection to the server. And then how long it took. You see this light green bases the art Calico coordinated because we're looking at Blue before green is images. That kinda makes sense. You can see here how long the light green is, less the amount of time it took in order to wait for the first byte to be received. And the dark green is actual time it took to load the image. So you can see here, if there was a bottleneck fast to perform or to improve on o would be and reducing the lag of time it takes to actually get the data from the server. So that's the Network tab. And one more thing I wanted to mention a lot of the times when we're coding websites. Remember we looked at that red line, the onload events a lot of time and a lot of sites only trigger a lot of JavaScript off to that onload event has occurred. And I can prove this to you if we just look at I don't know much about him at Google. Google.com. Google.com. And it's not looking at this page load. And we can see the red line, the onload event is there. But look how much happened afterwards. So you can see the red line. Look at how much happened. Authors, a lot drug says just my point that there's a lot of stuff that happens after that RED Linus hit. It's not that the onload event triggers the final, final execution called. It's just that, that executes the onLoad event sets, all their contact needed to display the first thing to the user. And then obviously you and I can implement logic of Tibet and even Google does that yet, you can see this has been a lot unknown but well-done. Seriously, that this can be very daunting, better hope it's becoming more intuitive. I hope you're having fun and we are not yet done. I wanna get into Nas and CSA so much it understand how lettering in process works. And let's have a look.