 Okay. Yep. Okay. So I'm going to be talking about, um, performance beyond the page load. So kind of like, um, what you think of performance is usually, usually page load speed. I'm going to be talking about what happens after that and how you can, I can like measure this sort of stuff and how you can, and look into it and diagnose some issues. Um, so that's me. Uh, I'm a team leader at Zendesk. Um, I love how serious I look in that photo. Excuse me. Um, so I work in Melbourne for Zendesk, hence the green shirt. Um, I come to you from Melbourne. Uh, it's actually, I thought it was the world's longest flight and then I actually wanted to verify that. So that's not a fact, but it's pretty long. Uh, it's about 15 hours just to get to LA and then another five from there. So it's a long way to, to come here. Um, so when we, when we talk about performance, uh, the automatic thing that you will think of would be page load. And that's, that's, um, because there's been a lot of people working very hard on getting page load performance, um, up to speed. Uh, so when you think of performance, you really think of page load. Um, and you know, that's for good reason. You know, slow sites lose people. Uh, you've got, uh, this graph here that shows the slower your site is, the higher the bounce rate. Um, so it's really important that you have your pages load, loading fast. Um, and this comes from a really good website, Web Performance Today. It sort of goes into that sort of detail about, um, how page load speed can really affect your, you know, your revenue if you're a, if you sell stuff on your website. So a lot of smart people will be working on page load performance. Uh, to name a few, there's filament group and Google really, really sort of pushed away there. Um, so like inlining critical CSS, uh, you know, only sending down the bits that you need initially, uh, you know, with a, with a responsive image talk, talked about sending down the right image for the right device. I really like this gift here. Just, uh, it's about performance. So I grabbed this from online. I can't remember who I got it from, but it's just, it was taken from like a car crash. If you're too slow, then you'll explode. Um, but page load performance is only sort of the beginning of the story. Like if you, if you've got really good performance, then it's down to, you know, that's the first second that your person visits your site. So if you have your page loaded in the first second, and then there's a whole other timeline after that they visit your site where you need to sort of think about how it acts and how they interact. Um, and it can really change someone's opinion on your website. If it's really clunky and janky, they can come away with like a sour feeling about your, your website and just think it's like it's bad and it hasn't got that native experience that people like to use. And H2D2 is really going to change the landscape of how we optimize for page load. Um, Chris sort of touched on it a bit. Uh, it'll really essentially make a lot of best practice obsolete. Uh, so things like minification, inlining critical resources, domain shouting. So with minification, uh, there's a concept in H2D2 called push where you can say, if I request the index file on the server, I can say, well, actually it's got all these resources. I will push that down in one, one request. So you can really get away with not having to worry about having like six different files loaded on your page because you can all push it down in one go. Uh, inlining critical CSS, that's sort of the same thing you can push down all your resources. So you don't need to concatenate everything together. Um, and your site can be rendering faster because it's got everything it needs straight away. And then domain shouting is kind of the concept. If you know how you have your assets on a different domain, uh, that would normally be cookie-less. Uh, so you can save, um, save the, the, uh, request size because the more cookies you have, uh, on your domain, uh, the bigger the request size gets, uh, with H2D2 has compression, uh, header compression. So that sort of negates that issue. Um, and actually is, uh, can actually slow down H2D2 if you have too many domains, um, requesting. That's kind of a story for another talk. We're kind of here for UI performance. Uh, so UI performance is kind of a black box. Uh, we're only just sort of getting the hang of what it is and how to measure it and, uh, figuring out what causes these issues. So browsers are really starting to expose the ways Chrome has really led the way, uh, with their DevTools. And I'll be using a lot of examples from the Chrome DevTools. Firefox, Safari, I all have these sort of tools where you can measure the performance in different browsers to really get a good look about, um, what's going on in your website. So this is an interesting graph and it will probably make sense after a few more slides and we'll revisit it, uh, and have a look at it. But you can see here that, uh, it's got the, on the y-axis, it's got the, the time and on the x-axis, it's got the number of DOM elements. And you see, so the blue line, I don't know if you can read that, says time in script. And the red line's about, uh, recalculation time. And recalculation time really sort of has that linear growth based on how many DOM elements you have. Uh, so that really shoots up and that really comes down to, uh, performance in the UI and what sort of CSS properties you're using and how the, how the browser works and we'll step into that. So this is sort of connected to that graph. Uh, this is looking from HTTP archive where they've tested a whole bunch of like the top Alexa ranked websites and you can see like almost 50% have between 400 and 1200 elements on the page. Uh, they're looking back at that graph. You know, you've got, you know, this slice here to there. So there's quite a bit that's about 10, 20 milliseconds can happen based on how many elements you have on the page to how hard the browser has to work to figure out any stuff when it changes. So the browser kind of has four stages of the rendering pipeline. Um, so when you're using interacts, when a script runs, when a CSS file loads, there's certain things that happen, uh, in the browser, um, that can affect the performance. So the first one being an on that graph that I showed was stole recalculation. So when you ask for an elements dimensions, you change the DOM, you scroll, uh, you resize the browser. Um, if you have a pseudo element like hover, the browser needs to figure out, uh, what elements are affected by that change. So it needs to recalculate the styles and figure out, uh, how it connects to the DOM elements on your page. Um, so they'll need to traverse. So the big, you can see as the bigger the DOM it gets, the more it needs to traverse everything in your web page, which becomes, uh, a harder task for the browser for the second stage. And this doesn't always happen, but this can happen. So there's like layout. So once it's done the style recalculation, that'll always happen. This can potentially happen. Um, and essentially it takes that style recalculation information and applies it to the DOM. So it works out the position of each element on the page based on the styles, based on the style recalculation. Um, and this will only trigger if something happens to, uh, to the browser where it needs to figure out a new position. So if you resize the window, then it needs to figure out where everything lies again. Cause everything changes. Uh, if you, uh, hide an element, then obviously everything moves up or moves down based on what you've hidden. And that's how layout or reflow. So depending on the browser, they kind of switched between the layout or reflow words. So you might hear both of those in articles. Uh, to take a quote, um, it's a bit of a wordy one. So reflow is the process of which the geometry. So geometry is the important thing there of the layout engines, formatting objects are computed. So essentially, if you were to, um, define reflow, it's essentially comes down to geometry. So if something changes with the width, height, size, um, then a layout is going to be triggered. So I've got a YouTube video here, but I've downloaded it in case it doesn't work. Let's see what happens. Now let's switch over. So this is really cool. This is a modified version of Firefox. And what they've done is they've shown what's happening when a page gets laid out. So what's the browser engine doing? And it's pretty full on how it's doing it. You can see it's figuring out, it's laying out, it's figuring out the position. Um, it's kind of slowed it down. This will happen very fast. Um, but they've slowed it down so we can sort of see what's going on. And you see it's a lot of work it has to do. And you can see at the end result isn't really that complex. So you can see for a simple site, I still a lot of work. Um, so it's kind of really eye-opening to see that sort of visualization of what the browser's doing, to how complex it can get, especially, um, for something so simple. You can imagine like a more complex web app would be, um, a lot more work again. Don't play. And then so the, the third step that can happen, so the layout, um, or paint can happen either or so they can happen together or they can happen independently. So, so once layout's been computed and the browser knows what it needs to draw, so it's figured out where everything lays on the page from that last visualization we looked at, uh, then what happens is it needs to then tell the browser to actually draw those graphics. So it's, the term's called paints and there's sort of two processes. There's paint and then there's rasterized paint. So paints are about setting up the instruction. So if you've ever used a canvas API, uh, it might be similar to you. So in the browser, there's sort of got this graphics drawing library where it can do like move to, fuel rectangle, begin path, um, and that'll like figure out those instructions. Uh, so paint won't, won't always happen either. So if you just request geometry information, so if you've got an element and you want to request, uh, the offset left, that will just cause a layout but not a paint because nothing's actually changed on the, on the, on the website. Uh, so you don't need to, um, doesn't need to relay out and figure out where everything's moved because nothing's changed. Uh, just needs to redraw the image. And then finally rasterized paint, uh, is a process that goes through those draw operations to draw like your, your box with a background color. Uh, and it essentially creates like a buffer and this gets put onto the GPU, which is the next step that happens. Uh, so this is kind of a new, um, it's a lot of browsers didn't originally, uh, do this automatically. Chrome has recently done it in the last, I don't know, maybe six versions ago where it will take that instruction and it'll give it to the GPU to draw that actual image of your website. Uh, and it can do that a lot faster because that's what GPUs are for, they're for graphics. So they send those instructions to the, to the GPU and it's called what's the composite. So it takes all those drawings and it composes it together and then renders it on your screen and that's like your final product that we see. Um, so once it's there, uh, it's very fast. Um, but if you need to do that process again, so you do something, uh, that will need to go through that process of style recalculation, potentially layout, potentially paint, and then back onto the GPU. Um, and that can be, uh, like take a while and you can see like your terms like jank and that's kind of what happens. You do something that causes the browser to go through that process again and it kind of stutters and doesn't, um, make it across, in the, in the frame timeline and it's got, so it's kind of a lot to take in. Um, so we'll look at a simple demo just to visualize. Um, so help you visually understand the difference between paint, reflow, uh, and composite, we'll just switch over here. So for a simple demo and we've got current DevTools open here and I'm on the timeline bit here. So it's kind of a really small resolution, but, um, this is the important thing for measuring this sort of stuff in Chrome. So I can do here, so I've just got a timer set up that'll do something in three seconds. So just record that and see the background color has changed. And what you can see here, like you can't really see the graph bar there, but there's a really tiny little green bar there and it gives you, uh, if it's under 60 frames or if it's above 60 frames a second or 30 frames. So you'll probably hear those numbers about, you know, hitting 60 frames a second. And this is a really easy thing for the browser to do. You're just changing the background color. So you can see it's, it's on the style recalculation, um, update layer tree is kind of like the data structure representation of the DOM. I don't think that's really important to look at the moment, but you can see here it's just on a paint, um, and then a composite. So that's taken that pain instruction and put it on the GPU. So that's really simple. So that's, that's kind of like no geometry has changed and that's sort of the important keyword is just the background color. So background color, uh, background image, uh, will cause a paint. So if we do a reflow and see essentially I've just changed the height. So that's just out of the class has changed it from 200 pixels to 400 pixels. And you can see down the instructions down here, it's done again, recap, recalculate styles. Now let's trigger a layout and you can see it's highlighting what the layout has changed. So because it's needed to change the height of this, it's needed to figure out where these things sit now because now that they've been pushed down, you don't remember that visualization. It needs to work out now that this button and this checkbox has now moved and this has changed. So it's affected the whole website. Uh, and again, it does the paint composite. And then finally pretty composite. So this does a similar thing to reflow except now you see, we only see recalculate. We don't see any paints. Um, we only see stuff. So what we've done here is we've used a transform. So transform is a, is a graphics card friendly operation. So what it means is it doesn't need to invalidate that texture that we put on to the GPU when we first rendered the website. It can actually just go and translate the height of that. You also notice that it actually cuts off the button. Um, because it's actually like translate it's a layer on top of the browser and it's sort of like transitioning and changing the height of that, but it doesn't take into account anything where it lives. So it's kind of like having a position absolute element in there that doesn't affect anything else. So that's kind of a simple, uh, to explain the process I just went through. So I think the moral of the story is you always have to be compositing. So if you can avoid, uh, anything that can cause a paint or a reflow, uh, that's where you're going to have that performance, uh, at its best because you're handling it's handled by the GPU and the GPU really excels at that sort of scenario. Um, so the two properties that are safe to use are transform and opacity. Everything else is detrimental. Um, though you have to essentially avoid everything else. Obviously that's not always possible, but if you can always stick to transform and opacity. So transform has got rotate, skew, um, translate and scale. And then opacity, you can just switch the, um, opacity of it. A really good website is CSS triggers. So that, that'll allow you to type in a CSS property and it'll tell you what it'll actually cause. It will cause a layout. It will cause a paint, uh, or just a composite. And you'll see that only transform and opacity, uh, are the really fast ones. That's kind of where you hear the 60 frames a second. And in that timeline that I've showed, you got the two timelines there. You want to have, uh, any green bars here, not go above that 60 frames a second. Otherwise it's going to skip to the next frame and you get that stuttering that you might notice on some websites and they're doing it, trying to do a lot of stuff that quite, quite fit in. And that comes down to the 16.6 milliseconds. So you might have heard of these two numbers and you're not sure what they mean. Uh, so 60 frames a second is kind of matching with, uh, the average display, which is kind of 60 Hertz. And that means it's going to refresh 60 times a second. So you've got a thousand milliseconds and that divided by 60 means you have 16.6 milliseconds to work with that. And there is a JavaScript API called request animation frame, and that'll fire every time the screen refreshes. So instead of using a set time out, you might use request animation frame and it'll tick and you can do some operations. But if you go over that 16.6 milliseconds, that's when it cuts in the frame rate slows and you start to get slower and you start to get that stuttering in that jank. So let's look at a non-trivial demo that shows that. So this is just like, uh, I took this from a Airbnb project called InfinityJS, which is like this infinite scrolling thing. And so it's got a whole bunch of images on there. But the one thing I want to do is I want to have this thing where it can show a modal over the top. And I just want to show what happens. With something that you can think is completely unrelated to your website, it can actually affect what's going on and what the browser has to do to figure it out. So we'll jump over to the timeline. Sure, we're already on timeline. Now I've just got some JavaScript functions that happen on there. So I'll do a recording. I'll then show you the modal and stop that. You can see if we zoom into that, you can see there now we've just done the 60 frames a second. Let me just reduce this one. So you can see here, all I've done is I've just switched display none to display block on this. So this is like hidden behind. And then I'm just using like jQuery to say this dot show. And it shows that element. But you can see even just showing it is we've almost gone over a 60 frame per second. And that's because we've done display none. We haven't done it at graphics card friendly property. So of course the layout update later tree has a paint composite. Has to do a lot of work. And you can see like we've just done something really simple that you think is disconnected from your hold on just because it's sitting over the top doesn't mean it's disconnected. So if you change this property, it means it has to go through that whole DOM element. And there's about 200 of these images in here, which is kind of like a realistic website has to go through and do all that work and do the layout. And you can see it's actually laid out the whole website, even though I'm just showing us over the top of elements. We never we don't really have this concept of containment in web development. But if I do a GPU friendly one, so bring up the console. It's called a new one. I've got another one called show perf. Actually, stop that. So this does exactly the same thing. Except this time, this time you can see it's no hit at all because we've used translate the transform translate property. So essentially, this this layer was just translated off the screen. And then now when I trigger the second one, the show perf modal, that actually just translates it into the middle of the screen. But because it's a graphics card handles it, it doesn't need to go through that whole process of layout restore recalculation or it doesn't start recalculation, but not layout. And it can handle it really fast. And it can show it. And if you know, we've barely even can kind of see the green thing there. So we come back to that graph, you can see even just doing something like a modal can really affect the style of recalculation time. So the more elements the longer it takes to work out what's going on, the more the browser has to work. So I talked about we don't really have this concept of containment. You know, what essentially is an isolated part of your page isn't treated as isolated by the browser because it doesn't really know that they can probably do some clever heuristics to figure out that maybe it is, but they won't always get it right. And sometimes they might get it wrong and you get weird rendering artifacts where something won't render properly because it tries to think it thinks it's isolated from the rest of the page, but it's not that makes it really hard for the browsers to figure out that for you. And that's just the graph showing the difference between the two. So that's the that's the GPU friendly one. That's not the GPU friendly one. So depending on your resolution, the paint time can go up over 60 frames a second to below. So if you've got a high resolution, so this is quite a small resolution, so it doesn't work as hard. But if you've got like a big, big screen, it has to work harder to paint that because it's got more surface area to work out. But there is a there is a spec called containment. So this will actually give you control saying, hey, I'm fully in control. And I know this is an isolated piece of my page. You don't need to work out the position of everything else. Trust me, I know what I'm doing. And it's really simple. I'm sure if you can read that. But it's basically it's just a single property says contain. And then there's a couple of like three values as style, this paint, this layout, and then there's a collective term, which is strict saying, I don't want you to cause any styles, paints or recalculations on this model. I know what's going on here. So you don't need to worry about it. Unfortunately, no browser has this yet. It's just a specification. But hopefully people will start to implement it soon. So you can have control and you can you can sort of say, I know this is isolated and it shouldn't affect the performance on my website. But I guess that last example was kind of unfair. There's a static page. There's no animation happening. There's no animation happening, then you don't really care about that 60 frames a second because you're not going to see any jank happening. So in that scenario, then it wouldn't matter that you're flipping the display none, then the browser has to do a lot of work because to the user, it just shows up straight away. There's no sort of like stuttering because they're not scrolling, they're not it's not animating in. If you were animating in, then you definitely have to use the graphics card transform property. Otherwise, you might get that stuttering. So it's kind of like a target. And it only makes sense when people are interacting or you're animating something on the page, you don't always have to hit 60 frames a second and you're not always going to hit 60 frames a second. It's kind of like just to think about when stuff's happening on a page that you need to sort of measure that through the timeline and the depth tools. So let's look at a real world example of where doing the stuff we've just been talking about can affect and show the difference. So this is a Bloomberg article about what is code. You might have seen it. It's not going to do it now, is it? So you can see when you load, you know, kind of stutters there. So it froze a bit when I, when I was scrolling, it's trying because it's trying to do a lot of stuff here. So how can you figure out what's going on there? So there's a few things we can sort of look at what's happening. So you can see this gets stuck there. And as I scroll away, it sort of shoots up away, as well as this background here that's animating. So there's something in Chrome DevTools that we can see what exactly is going on here. So we bring up the console. There's this rendering tab here. We can do show paint rectangles. So we just get rid of that. So you can see, you see that's changing color. That's a bit, you can see what the browser has to repaint every time I'm scrolling. It's essentially repainting the whole website. So highlights. And it's what this is doing if we drill into this. You can see it's actually animating the top property. So if I scroll away, you can see it animates it to negative 100. So that's going to have to cause the browser to go through that whole process. When you could easily do something like translate to say, you know, translate negative 100% and that'll move it up. You can also see here they've got this flashing cursor that's causing a paint every time. So on that they're using like an animation, but they're switching between color white and color transparent when they could easily do something like opacity to say like, you know, it's off, it's on, it's off. And then also the more complex one is their background, which is essentially a canvas, which is causing the whole page to repaint, but we'll sort of focus on the top bit. So I pulled down the website. And what I did is I changed that. So you can see I've just got a transition and I've just got the initial status it's shown. So it's translate 000. I'm using 3D to make sure that that would be handled by the GPU because not always 2D transforms won't necessarily always be put on the GPU. It might be up with the browser to consider whether to do that or not. 3D will always be. And we're just animating in a 2D context. So it's kind of XYZ coordinates, just 000. So when I scroll away, you can see now I've just changed the class on that. So the class on this is essentially just a negative 100%. So it's taken out of the viewport, but it hasn't caused any issues. If we bring up that show paint rectangles, you can see now there's no, the only green thing is happening on the scroll bar. This flashing thing also changed to just the opacity 0, the opacity 1. You can see now it's doing less paints. It's repainting here because it's got this background. If you were to disable that, you'd find it. You can see even like it's not even repainting when that when that header comes down and disappears. So this is kind of really interesting tool to see like what your browser is doing and what like it's doing there. So you can go and get that in console rendering. This is in Chrome stable. Now you can have a look and you can show paint rectangles. You can see what what performance issues are happening. So another interesting thing that's happening in web development is the Houdini task force. So this is an attempt to explore and define lower level performance concepts in the browser. Helping back, I remember something yesterday was mentioning, I think it might have been a Brooklyn JS with the extensible web manifesto about giving developers lower level access to be able to fine tune performance. So for people who really want to dig down deep, they can have that opportunity. And I think that's a really powerful thing. So they've now all the browser vendors have come together under the Houdini task force. You can you can Google that. They've already got some example specifications and ideas of what they want to do. It's really interesting. But of course, like if you don't want to dig down, you don't have to. But if you if you need to, like in creating a native app, you can dig down into low level stuff and really fine tune that performance. This is what this task force is about is actually enabling that in browser land through JavaScript API through CSS properties to be able to do that. So this is kind of their mantra of develop features that explain the magic of styling a layout on the web, because really it is magic. It's really hard to understand. You have to read a lot of, you know, browser code, a lot of different weird articles aren't necessarily easy to understand if you're if you're just entering into the web business. So some of the things they want to do is they want to specify the box model. So the box model is kind of like what happens when you have padding and margin display inline display block and how that happens. So they haven't actually spec that out. So one of those things is actually define what the behavior is. So across browser can be consistent and they can all agree on what the box model is. Another one is improving the CSS object model. So that's when you you when you look at an element style property, it's essentially strings at the moment. They want to have like powerful abilities to be able to do much more interesting things. And then they want to explain CSS and layout. So sort of that process I went through of story calculation, you got paint, you got layout, and they want to enable and give you some some APIs. So there's already talks of having like a paint and layout API available in JavaScript. That's obviously early days and they're just talking about it. But if you Google who do any task force, there's some really interesting stuff there. So I guess the moral of the story is performance is really hard. It's really easy to shoot yourself on the foot, like simply just changing do it using jQuery show hide on something that when someone's scrolling or you're doing something, you're going to get that jank because behind the scenes of browser has to do so much work. But I hope with these new with Houdini with, you know, the containment spec with people is better understanding of what's going on in the browser performance become more important story. And you'll have a better understanding of what you're doing and how you can fix it and how you can measure it in different browsers. Thanks.