Layouts and Reflows

[00:00:00]
>> Steve: So we talked a little bit about style calculations. The next part of that chain was layouts and reflows. Right, like a layout is effectively ok a reflows is effectively a we layout of the page. You changed something with JavaScript didn't you, right? Or by resizing the window because I don't know if whenever you make a front end webpage, the first thing a nontechnical person does is see if it's responsive by grabbing the side and making the window small and large a bunch of times.

[00:00:26]
Also technical people do that. I do that. I understand where all the responsive design tools are in Chrome, I don't care. [LAUGH] So, layout is the first time, a reflow is a word frequently used for, things have changed, I need to update the layout. A layout can be really, really expensive and they're usually one of the main causes of JavaScript, that slow down rendering, right?

[00:00:54]
Because, yeah, if you do it too much, that's problematic. Again think about all of the elements on the page, every list item, every text node, everything, every image. It's a lot of work. I don't even know how it gets it done in the time that it does. It's kind of impressive, like, I think it's mostly that we've had like 29 years or now I think the web is, 29 years of experience doing this, has made it decently fast.

[00:01:18]
But like it's incredible. You can actually, there are some YouTube videos that show Wikipedia, or a few other pages effectively, the process of Firefox goes through laying it out. It's like okay, there's an H1 it's inside of a div. And it keeps having to move it around and change the size and adjust stuff and it's fascinating.

[00:01:35]
So kind of mentioned this before. Whenever the geometry of an element changes the browser has to reflow the page, right? Like, how that actually happens like in the browsers is very different, right. Like it doesn't really matter. The major points we're going to touch on is not doing it when you don't need to, it's the largest one, right?

[00:01:56]
But the actual process is very different for every different engine. So, things that you need to know about a reflow. A reflow is what we call a blocking operation. Everything else stops when we're relaying out the page. None of your JavaScript is running, nothing, right? We are reflowing the page.

[00:02:11]
That is the thing that we are doing right now. Stop everything until that is done. And obviously if I haven't made this clear enough, it's hard. And it takes a lot of resources and it's not fast or easy. And if you do it a lot, guess who's gonna notice, right.

[00:02:26]
A lot of the stuff we're trying to do is, for a lot of this web performance stuff, if we're doing our jobs well, the user should never notice that we're doing anything. Users never go, they implicitly in their brains go like, I like this side. They don't know that performance is the reason why.

[00:02:43]
But, if performance on your side is terrible, they know, [LAUGH] right? If users notice the performance, it's usually that you're messing it up, right? So you end up doing this in a loop. It's gonna be noticeable, it's gonna be bad. And we basically don't want people to notice us.

[00:02:59]
>> Steve: Coo,l the only thing to keep in mind is that reflow of an element. I'm very careful with these words, right. Reflow of an element causes the reflow of its parents and children. Think about what you know about a tree. [LAUGH] If you reflow all of the children and then you reflow the parents and they reflow the children.

[00:03:22]
Pure most the time, there are some edge cases where you can get away with only having to reflow part of it and we'll talk a little about some of those. But generally speaking that is code for saying you touch one thing you touch everything, right, this is technically the truth.

[00:03:36]
But really more often I would say 95% of the time you reflow a thing, you're reflowing everything. Good luck. So, okay, we know that reflows are expensive. Avoiding them is not necessarily fair cuz sometimes you do need to change the layer of the page, right? So, it's as much as you need and as little as can get away with kind of thing.

[00:03:57]
So what causes a reflow? Here is a incomplete list and yes, the small font is a joke, [LAUGH] right? It's a way to put as much on this slide as possible, right? Resizing the window, changing the font, changing the content, adding or removing a stylesheet, adding or removing classes, adding or removing elements.

[00:04:14]
Changing the orientation, like when you take the phone from portrait to landscape, obviously, like that reflows the page. Calculating size or position. That one's interesting. The simple act of trying to figure out the size or position of something, causes a reflow. Fascinating. Changing the size or position, like yeah, of course that causes a reflow.

[00:04:34]
And when you reflow and you change the size of a bunch of stuff, guess what you got to do next? Right, you got to repaint, because you now need to paint more pixels blue if it's a blue element that you changed the size of. More or less, I'll give you a hint.

[00:04:52]
Layout is the second most expensive part of the rendering pipeline. Would you like to take a guess at what the first one is? Painting,and for every time you reflow every time you do a layout you have to do a paint, guess what, they always come usually as a package deal.

[00:05:07]
So questions how do we avoid this? Yeah,you can try like if can't get away with it changing like the lowest levels of the DOM trees and not get that whole page reflow, like give you change the container element from 600 pixel wide to 800 pixels wide, everything inside of it is gonna change.

[00:05:23]
There are times when you can get away with changing a much smaller subset but keeping your changes as low down the tree as possible. Stop modying in-line styles will do it, right? The less you change, the less you can trigger this stuff. I think a really interesting one is the trade the smoothness for speed if you're doing an animation in JavaScript.

[00:05:42]
We'll talk later about how, you probably shouldn't be doing animations in JavaScript but sometimes you need to. But the thing to think about is, we talked a little bit before, the ideal you're aiming for 60 frames a second. At 16 milliseconds right? You're like yeah cool. So on every little pixel I want this animation to be smooth.

[00:06:05]
I want to animate every single pixel, right? If that takes longer than your 16 milliseconds and you're going to miss that frame, right? Because you're triggering all this reflow. You're better off moving that box three pixels at a time, right? Because you wouldn't have actually missed as many frames.

[00:06:22]
So sometimes, writing the animation to be a little bit jankier makes it faster because you don't miss the next frame that's gonna be painted. The other one is avoiding table layouts, that kinds of makes sense for a lot of reasons, one like I write similar emails, just trust me.

[00:06:38]
[LAUGH] All right, a table here is hard, but the other part is like, if a column and a table gets wider, what do you think happens like every other cell above it, and below it? It's got to give, you know reflowed. A table effects, everything around it by definition.

[00:06:53]
And then batting down manipulation, this one, if you're using a framework, you effectively getting it for free, right. This is what makes React, React, right? It's what makes Ember, Ember, and Angular, Angular, is that they figure out how to take the state of your application. And do the bare minimum of changing the page, and doing it as efficiently as possible, right?

[00:07:13]
So, rather than, I'm gonna add all these. Like, you'll change a bunch of stuff in your application. It will figure out a pro forma way to do that. That is like legitimately what a lot of our frameworks are bringing to the table, right? Is the, we will let you make a bunch of changes to the state of your application, we will figure out an efficient way of rendering it.

[00:07:30]
If you're not using a framework, this is on you, right? And like not using a framework is always a toss up. Like Frameworks come with a cost, that we'll see in a little bit. Right, they're not free. You have to write like they are built on JavaScript, we know that we have to part JavaScript and execute the JavaScript.

[00:07:47]
And that they make a lot of assumptions that have to be general. A given framework has to be as good for you as it is for the person sitting next to you. Which means that they're are kind of like Jack of all trades, they're making best case assumptions.

[00:07:57]
If you were going to fine tune stuff. Yeah, like you could probably make it faster than if you used react but you'd have to do that for everything and a lot of times we make the trade off of a framework making good decisions for us most of the time right?

[00:08:11]
So that like we make them more often right? And then debouncing recess events, which is, if you are, have an eventless scenario that's listening for the window to resize. Typically for me, this happens if I'm making a data visualization with an SVG and I want to change the width of everything, like when the window resizes.

[00:08:31]
They usually dragging it. So usually you dont want to do it repeatedly. You say, okay, I have to drag it and let me do this every so often, you'll have less reflows.