How Web Pages Are Built

[00:00:02]
>> Steve Kinney: The JavaScript code that we write has to execute in the browser. In order that, we need to know a little bit about how web pages are created and how they're actually rendered, and how they use interface updates. So let's talk e a little bit about how web pages are born.

[00:00:16]
Again, the step one is the browser goes ahead sends get request to a server, he says, hey, give me a webpage. We get back a response and guess what it has in it? A webpage, like typically HTML. The HTML is just a big sting of text and likely has other things that we need to get like Style Sheets, JavaScript files, so on and so forth, right?

[00:00:39]
Becomes the basis of the webpage that we're creating. That HTML also needs to parsed and figure out like what is the actual structure of this page, right? So we take the HTML and we pars it into this thing called the document object model, the DOM if you will, everyone's friend.

[00:00:54]
Which is basically the representation of the page starting with the document. We got the HTML tag, the head and the body, so on and so forth. It's this big tree like structure that is a representation of the webpage that we have. Now in the previous example, we saw that link to go get some CSS.

[00:01:11]
We need to go fetch that as well. That's obviously a different language, if you will, right? And that needs to kind of get created, figure out what are all the styling rules for this page? And that gets turned into this other very similar archetype called the CSS object model.

[00:01:27]
So the cascading style shape object model, that's a mouthful. Which is just basically a giant tree of all the rules for how our page should look. So we have in one case is we have an entire structure of how the web page or web application is laid out.

[00:01:43]
And we've got this other one for a set of rules on how different things should look, right? That's not necessarily how each particular element looks, but we're gonna go tell all paragraph tags. All things with the class of cool, right? That's not semantic, but we'll go with it.

[00:02:01]
And how we have all these rules. We have that state of the world, right? So in order to figure out what the page looks like we have to take the state of the world and the rules about the world and we put them together into this thing called the render tree.

[00:02:14]
Now the render tree you'll notice like, we don't have that HTML anymore and we don't have the head, right? It's only the parts that will actually show up on the page, right? Because we don't need to worry about how to style things we're not going to show, right?

[00:02:27]
So basically the structure of our page along with the computive rules. It take all the CSS and all the rules and figure it all out and tell me what this given element on this part of the DOM should look like, and this other given element, so on and so forth.

[00:02:44]
So the render tree, again, has a one-to-one mapping with the visible objects on the page. You can have multiple rules applied to the same element. You could have one rule applied to multiple elements. When it comes to the render tree, it's here are all the things that are gonna show up on the page.

[00:02:59]
Here's what they should look like, very cool. Things that anything hidden is not gonna show like if you do display none, that's not on the render tree, cuz we're not displaying it. Things with the head are not gonna happen. But things like pseudo elements like, hey, put this other element before this other one and we write that in CSS, that is on the render tree.

[00:03:18]
So it's a little bit different. And we need to figure that all out. And the process that we figure that out is called style calculation. The browser looks at all the styles and all of the elements. It figures out what styles apply to this given element. What rules apply?

[00:03:31]
Okay, two rules are changing out the background color, which one of these win, right? And kind of figures out everything about how it looks. So again, this really results in two things. Like, which rules apply and if two rules are defining the same property twice, which one wins, which one has higher specificity?

[00:03:50]
If they have the same specificity, which one came later? So on and so forth. The browser will figure that all out, you just basically give it a structure, give it some rules about that structure, [SOUND]. Out comes a render tray ready to be shown onto the page. That doesn't necessarily show it on the page, but that is like a set of instructions on what's on this page?

[00:04:09]
What does it look like? The other thing that we have to keep in mind is figuring out which rules apply? Cuz it can be a little bit tricky, right? We could have stuff like all P rules in CSS apply to the paragraphs, fine. We could also have some a slightly more complicated one, like nth child 4n- 1, right?

[00:04:31]
That takes a little more work to figure out. [LAUGH] That's not as simple as like, are you a paragraph or anything along those lines. We have to do work to figure that out, right? You can almost see where this is going here, which is things where we have to do more work tend to take a little bit longer.

[00:04:46]
So the more complicated you end up making your selectors, the longer this whole process is going to take. It seems like computers are fast and everything is free, but that's not really the case. Everything we go ahead and do is gonna take some amount of time, and the more work it takes to do it, the more time it takes.

[00:05:03]
So easy rule of thumb, class names are super simple. Like, does this have the class of header or footer, or whatever? That's a yes or no question. That's very easy to figure out. But when we get to the point where it's going off the page of sidebar, the first descendant of menu-item, the nth-child, that takes a lot longer.

[00:05:25]
So when possible you can always speed up the time of calculating all the styles and matching to the elements by keeping it as simple as possible, right? Any kind of system where you define it with class names would be BEM or CSS, it doesn't really matter, right? But if you can do this by defining all those states and classes, it is always gonna be faster than doing trickery, right?

[00:05:47]
Because the browsers they read the selectors, if there's one selector cool, they're ready to go. Otherwise, they have to do more computation. The less selectors, the faster is going to be, right? And it could be stuff like well, I need every fourth row, right? Very cool, but it does raise the question.

[00:06:04]
If you need to use it, use it. But if you're like, hey, I'm generating this giant table from the server, can the server put the right class name on for every fourth row, right? Cool, then you can speed up what the user's browser has to do, or if you're shipping reactor, angular, or ember anyway, and you have some logic in there and you can put the class on every fourth row, right?

[00:06:23]
You're already going through that process. You might as well do it there than loading extra work onto the selector engine to figure it out. So we style, we figure out what the rules apply, and then we kind of try to put them all together. Selector matching just takes, okay, this is the fourth row in the n plus 1 minus 4.

[00:06:40]
It does have a class of very important table row and figuring all that. When multiple selectors apply to an element, the browser needs to figure out who wins. And obviously, the fastest way to speed that up is not to do it. So again, if you can do this by having some kind of way that you're naming your CSS classes that figures all that and tests the actual state of the object, it's going to be faster, right?

[00:07:05]
I'm gonna be really honest though like,
>> Steve Kinney: Style invalidation, taking stuff on or off doesn't matter as much. And this will always be a relatively short part. If you notice, if you measure that calculating styles is a very big part, as you wait for the initial page to load.

[00:07:21]
These are the places to look for, my suspicion when we saw some of the other things going on is it's probably not the longest for getting the initial page. Parsing the JavaScript is probably the longest, but a lot of the kind of rules from rendering and how to optimize render performance, has to do with the fact that JavaScript code is likely gonna change the page after that first load.

[00:07:44]
And how do we do stuff, how do we do repeated stuff, right? If you think about an animation, an animation is like they're changing the page many times possibly, right? And like a lot of it comes down to one page has been loaded, but it's worthwhile measuring if you see on initial load, calculating the styles is taking forever.

[00:07:59]
These are the kind of paths to go down or you do have very complicated selectors. Do you have a bunch of CSS that you're not using, right? If you have a bunch of CSS that you're not using, we still have to check that, right? Getting that code out of your code base is going to help with that issue, right?

[00:08:14]
And we'll look at some tools later for like automating that, so you don't have to hand, look, the CSS class. I wonder if it's on any elements, right? Like good luck not messing that up. So like having some kind of like automated tool it does it is usually really useful.

[00:08:30]
So the high level on stall calculation part is reduce the amount of unused CSS the you're shipping. The less styles you have, the less there is to check. And trying to reduce the number of styles that effect a given element by using some kind of system that can boil stuff down to one class, right?

[00:08:44]
If you can pull those two things off, those happen to be useful for a number of other things too, right? It happens to be useful, cuz like, not only is that less for the browser to do, but it's also less stuff you're sending over the wire, right? It's also, for a lot of the stuff, easier to manage your own code base.

[00:09:05]
These CSS systems, like BEM and CSS, were not necessarily originally built for performance. They were built for developer sanity, [LAUGH] right? It just happens to be that systems for developer sanity also make your code faster. So definitely kind of look out for one of those. All right, so after we figure out the styles and the render tree, and we have this entire tree of stuff ready to go, right?

[00:09:27]
We know everything that's gonna be on the page. We have some rules about what everything should look like. It's time to actually put it on the page, right? And we’re gonna go into this one a little more in depth in a second. We’re gonna go through all the other steps, and then we’re gonna round back to that.

[00:09:43]
But this is trickier than it seems, right? You have to basically find out the size of every element, when you would break to a new line, the relationship between everything, right? It should be no surprise that this is complicated, and it takes a while, right? We will round back to this in a little bit though.

[00:09:57]
So you know what the elements look like. You know where they go on the page. It's time to make them, right? So the process of painting, you take all the information about what it looks like, you take the information about where it goes which a lot of times affects the size of it, right?

[00:10:13]
Like it's gonna be 50% of the width. Well, you gotta lay out the page before you know how many pixels that is, right? Once you've figured out where everything goes and have all the rules figured out, then you can go ahead and paint. Which basically means take this element, right, which is a bunch of rules and location data, and turn it into a picture that somebody can see, right?

[00:10:32]
So that's the process of like turning it into a bitmap image, right? So it goes from a tree and all the stuff to like a picture. You're not totally done yet, right? You have pictures. Having pictures does not necessarily get the job done, right? After you have the pictures, you need to actually send them to the GPU in order to be put onto the screen, right?

[00:10:55]
And there's some rules about this that we'll kind of talk about in a little bit. And once that, then you're ready to just make Internet millions and you're good to go.