 So I want to share with you a new tool in the Chrome Dev tools called the Vertical Timeline. The goal of the tool is to help you identify what is hampering the responsiveness of your application so that you can help identify it, smooth it out, and make your application run as smooth as possible. To kind of demonstrate this, we're going to bring up this demo. This is made by an interactive developer named Hakeem. He goes by Hakeem Alain Twitter. And he made this a bit ago. And well, let me just show you what it does. So as I scroll, we get some of these cool effects. So this one kind of flips in things. We can also just kind of manipulate the skew. So this is pretty cool. He put this out about a week ago. And I was looking at it, and I was like, this is cool. I think we could actually make it a little bit smoother, the animation itself. And so I started looking at the code, and I said, let's see what we can do here. So first, I want to bring up the vertical timeline. So I'm going to bring up the Chrome DevTools using my keyboard shortcut. And here I am on the Chrome DevTools timeline. Now, if I just record a timeline right now, I'm going to hit Record. And we'll do, let's see, the curl. OK, got that recording. And that's good. So I can zoom in here on the timeline, and I see kind of what's going on. But I'm looking down, and it's just scroll event, recalc style, paint, paint, paint, paint, paint tells me the size, but this is not really telling me anything. This is not too helpful to me. But now, if you see up in the top left right here, we have the vertical. So I'm going to switch over to vertical bars. And we have quite a different picture. So each bar represents a frame that's being drawn to the screen. And a frame is kind of how the browser sends information to the GPU as it draws. So right now, it's kind of the tall bars take longer. Purple is rendering time, and yellow is script time. But that's all kind of the information that we have. So this is cool, but I think we need something a little bit more useful than this. So what we're actually going to do is take a look at the code and see if there's anything that we can immediately change. So over here is the source of what's going on. And one of the first things that I noticed in the source is that we have this, a scroll listener. Now scroll is particularly troublesome and does not work well against sending things to the screen. Scroll kind of fires at its own pace, and the screen kind of wants things at 60 frames per second. And scroll is either firing too fast or not fast enough. And so we can do a little bit to optimize this. So what we're actually going to do is just get rid of this because we're going to use request animation frame. So request animation frame is what the browser optimal API for rendering. So we have a little shim in here for cross-bouser and back compatibility. And I'm going to use this little loop inside here. So this is just a recursive loop. And we're just going to continue to call update through request animation frame, just ongoing. Now I'm going to come back here and I'll reload the page, reset my timeline. And now when I start recording, you'll see it's quite a bit different. So one of the things you'll notice is that the request animation frame is just firing, firing, firing. So I'm getting all these bars right here, right? But the good thing about this is that you get to see what the height of the bar should be. And so the height of all the bars over here is essentially indicating 60 frames per second. This is the ideal. Your monitor refreshes at 60 frames per second. And in Chrome, we've made it so that request animation frame matches the refresh rate of your monitor. So it's as smooth as possible. You cannot get smoother than this. But when we blow up above this area, we're going above that. And so 60 frames per second translates into 16.6 repeating milliseconds. And we can verify this by zooming into this area. And the time code across the top of this shows that we're at 16 milliseconds or so for each of these frames. But once we go into this area, these frames get quite a bit larger, 70 milliseconds, 116. And so those are recorded when I was scrolling. And so what we can do is we can zoom in to that area and investigate what was going on. So it looks like we have this animation frame fired. I'm going to expand this. And here we have a bunch of stuff going on. Recalculate style layout. Recalculate style layout. Recalculate style layout. This is not a good pattern. But we're able to see what's actually going on here. So I can actually click right from here into the code. So this is the stroll.js that we were just updating. And what it was telling me was line 40. And here it's highlighting this. So it looks like line 40, we have an offset top and an offset height. And if you're familiar with reflows, let's see, faster site reflows. They're also called layouts in WebKit. But here's the blog post where you can identify all the properties and methods that cause a reflow. And so in here you'll see offset top and scroll top and an offset height is in there as well. So this is actually causing the browser to recalculate all the geometry of the page. And this is happening inside a loop going over all the items in this list. So it's happening quite a bit. So we're able to identify a nice connection between the rendering time back to our JavaScript. And now I'm able to see that this line in particular is really costly. Now, noticing that we have these two calls, which require calculating the layout, and we look down and we see that we're actually adding a class. In this case, adding a class here and adding classes here. What we get into is a loop where we are setting properties on the DOM and then immediately asking the DOM for new information. And that is exactly what is causing this recalculate style, recalculate style back and forth. Optimally, we only have to recalculate our style into our layout once and not have to go back and forth. So what we can do in the code is, instead of doing this where we get the information and then we set it and then we keep on doing our loop and getting it, we have this new version that I wrote. And we're actually going to do a funny thing where we use two loops. So my optimization here is to translate this from one loop into two loops. In the first loop, we get all of our offsets. And then in the second loop, we go through and then we apply our changes based on the information that we gathered. So we're just getting in a big row and then we're just setting. And so this is a lot more compatible with reducing the amount of reflows that you have. So if I bring up this version, this is the new one, and I open up the timeline, I'll hit record. And here, you'll actually see that the bars are much lower in this case. So they're not spiking as far above as they were on the earlier case. And if I go in really close, let's see, here is a good one. Yep, this is what we like to see. So we have a single recalculate style followed by a layout. So we're giving the browser as much, we're optimizing our code as much as we can to avoid the reflows. And so as a result, we're able to hit our target of 60 frames per second a lot closer. So this is really pretty cool. And I'm very excited about this feature, the vertical timelines. If you want to check this out, the best way to do it is go to About Flags right now. And here's where you can turn on a bunch of experimental things. If you search for developer tools, you'll find this and you can enable it here. You restart the browser and then you go down into the bottom right, the Settings, where it brings up this. And down here on the bottom right of that, we have these experiments where you can turn on a few things. So right now, vertical timeline is in there. But hopefully, soon everyone will see it by default in their timeline. So we're really excited about that and hope you enjoy it. One of the things that we're looking to bring later is per frame profiling. So what this means is that if I had a lot of script execution happening in these frames, so a lot of yellow, I would be able to pick out one frame and essentially see what the profiler captured during that single frame so I can identify what in my JavaScript, what methods inside of my JavaScript are causing the most time. So we're looking towards that and hope to bring that to you soon. In the meantime, please take a look at this feature and let us know if you have any feedback. Thanks.