Layout Thrashing

[00:00:00]
>> Speaker 1: It's called layout thrashing. The real term is forced synchronous layout. We're gonna call it layout thrashing, because let's see really cool. Let's be really honest like when you have one thing called layout thrashing and another one called forced synchronous layout, you choose layout thrashing every time. So there's a set of things you can do that cause the browser to stop and calculate style, and layout, and as we saw like asking about it is one of those things.

[00:00:26]
This is some code from my application where I just literally did the first possible thing in the editor, which we have a button module like the call to action button. And I hit a recording, I dragged it in and I stopped the recording. Cuz my whole plan was to like kick around, they have a lot to find an example and a real world application to show you.

[00:00:46]
Turned out, it was literally the first thing that I did. You can see that like if Chrome can detect it, it will put a little red triangle up there. And like basically tell you, hey, a fourth reflow is a likely performance of bottle neck. It's like I caught you doing this.

[00:01:04]
I think you should know about it and you can kind of like see all of that stuff in place. So like even in a large application like they was literally the first thing that I tried, it wasn't like I went looking for a pagery flow. I did go looking for a pagery flow.

[00:01:20]
It saved me a bunch of work [LAUGH] by finding it immediately, but it didn't help my moral authority talking about this. But it was the very first thing that I found in there. So one of the kind of definitions, layout thrashing occurs when JavaScript violently, that's why I picked this quote.

[00:01:37]
Writes, then reads from the DOM multiple times, causing document reflows. So yeah, every time we read like we have to figure out the size of everything. And then once it gets the most up to date information, maybe just reads it once. Cool, no big deal. The problem is the browser is smart, you're like what kind of problem is that?

[00:01:58]
If you change a bunch of stuff, the browser kind of like remember we said like budging manipulation was good. The browsers effectively trying to do that, as well. You can change a whole bunch of staff. The browsers like I don't make new frames until like every 16 milliseconds like let them have that it.

[00:02:15]
When I'm getting ready to draw the next frame, I'm gonna forgot what change, then I relayout the page. The problem that you have here is we changed something. And we measure it, we change something and we measure it. Like the browser doesn't know, it wants to get you, it doesn't want to give what the width was of that bar.

[00:02:33]
Last time it rendered, you changed something. It wants to get you the most up to date information, cuz that box might not be where you think it is anymore. So every time you measure, if anything has changed from the last time you measured, the browser has to go through and like figure out the new state of the world.

[00:02:51]
Sure, is that not great? Obviously, but where it became a problem was in a loop. We checked, we changed. We checked, we changed. Which caused we recalculate style lay out, recalculate style lay out. Whenever you kind of see that pattern in there like sometimes you are iterating and it's natural, but you saw that for h was like one long block in there.

[00:03:11]
When you see those patterns and you notice you're blowing through the 16 milliseconds for a frame, you have a problem. And if Chrome like goes as far as to give you the little red thing in that case, you truly know you have a problem and this is kind of one of the first things to look for.

[00:03:28]
So yeah, the browser basically wants to figure out if it has to get new updated layout information after every time you change something. You asked it for stuff, it didn't know. It tried to figure it out. So it stopped, it reflowed the page and got you the information.

[00:03:42]
So how do we solve this? Well, we saw a solution in the code before. If you separate all the reading from all the writing, you should be good like read a bunch of times. Don't change the page, get all of the information you need, then go ahead and do the page changes.

[00:03:58]
So like the first code in a loop would've triggered layout threshing. The second one, we read a bunch and then we write a bunch like based on that information. It is going to be performing for us.