 Hey, everybody. Paul Lewis here, just going to show you some features that have been landing inside of DevTools recently. And I have, as always, Serma with me. And we're just going to talk those through. Navigate around. I've got a few demos and things to show you. How are you doing, Serma? I'm good. Good, good. I thought we could start with, I know you've been working on the performance tab in some ways. And that's something that people are interested in. Why don't we start with that? Let's start with that then. So if you've not seen it, in fact, let's just go there right now. Web.dev slash metrics. It helps if I can type. As always, my typing is woeful. But let's have a look. Nothing has changed. Nothing has changed. Web.dev slash metrics. OK, so here you can see we've got important metrics to measure. First contentful paint, largest contentful paint, first input delay, time to interactive, total blocking time, and cumulative layout shift. Now, some of these metrics it's worth saying from the off. These are all designed to help you improve the user experience in your sites and your apps. But not all of them are suitable for what we'd call a lab setting. Some of them are we call field setting metrics. So for example, first input delay, it's not really something you typically test in a lab setting. It's something you do more with the field, with like ROM and sort of live data. So not all of these make sense in the lab. But the ones that do, we've been trying to get into the performance panel inside of DevTools. Because once you open DevTools, you are in a lab setting. Exactly. You can never acquire a real user athlete. Can you please open DevTools and quickly do the measurement? The second you need DevTools to measure something, you're in a lab. Yeah, and so our assumption is predominantly if you're sort of local host on your machine, we tend to refer to that as the lab setting. So let me just run you through very quickly the kinds of things that we've got. So if I just go to the Web.dev home page, and I've got the Performance tab open here in Chrome. This is currently in Canary. So some of these features are very kind of hot off the press. They're subject to change. So just bear that in mind if these things look a little bit different over the coming weeks and months. It's because we're working on them. We just wanted to share them with you because we're kind of excited about some of them and all of them and we want to show them to you. So if I take a recording, so I'm going to go to Record. I'm going to hit, in my case, Command Shift R, which will do a reload without any caching. Just wait for a little while for things. Or Service Worker. Sorry, say again? Or Service Worker. Like it's literally as if you hit the network. Yeah, exactly. So I'm going to stop that profile. I left it running for quite some time there. And it's going to process that. OK, so let me bring that down. So this, I mean, this is actually a really good trace recording, like a performance recording. If you've got something like this in the lab setting, you'll be super happy. And the reason is, if I just zoom in a little bit here, you can see that most of the tasks in all of these top level tasks here, the task, they're all really, really short. And that's really good because it means super short. It means that the main thread is remaining responsive. So let me just zoom back out. But let's talk about some of these metrics. So for example, DOM content loaded, that's been around since forever, really. And that continues to be shown here. But you see this timings row contains some new ones, like first paint, first contentful paint, first meaningful paint, and largest contentful paint. And you can actually see on my screen here, when I roll over largest contentful paint, the element that is the largest contentful paint highlights. We put an overlay on that one so that you can see. So immediately, some of these metrics that you're going to see in web dev slash metrics are showing up inside of the DevTools timeline. So that's the high level metrics. What we can also do, though, is we can show long tasks. Now, as I said, all these tasks are pretty, pretty quick. But I'm running on decent hardware here. This one here is 18 milliseconds. And I think we could probably do another recording and actually show it slowed down. So what I'm going to do is I'm going to go to the settings here and I'm going to switch on CPU throttling. I'm going to switch it to six times, slow down. The reason I'm going to do that is just so that we can see what it would look like on slower hardware. So we have a sixth of a MacBook now. Yeah, exactly. So I'm going to record, I'm going to refresh, as I did before. As I say, I'm going to give it time to actually settle down. Some of our metrics, they do need to wait until there's only a couple of requests running on the network and so on. So I'm going to stop that recording. And what we start to see is we start to see these red triangles. So again, let me zoom in on what's going on here. So there's a couple of things to notice. One is that the task at six times, slow down, in this particular case, is 168.54 milliseconds. What we're trying to do is we're going to try to keep all our tasks under 50 milliseconds. And the reason for that is that we can make the main thread responsive when we do that to user interactions. Because most of the JavaScript that people are running, like touch handlers, and mouse click handlers, and all those kinds of things, all run on the main thread. And so what we want to make sure is that we're not blocking the main thread with work. And so keeping tasks under 50 milliseconds is the goal. So the blocking time. And I mean, let's be honest here that, I mean, 50 milliseconds is somewhat lenient. If we went to the good old goal of like 60 frames a second, it would be even less. But during the first load, we can be a bit more lenient because nobody expects to interact with the website during the first second of loading. So we can have a little bit of a higher threshold there. But above 50 milliseconds, it can become very noticeable if the main thread is blocked. Yeah, absolutely. Great point. In the context of page load, absolutely. This is more about the 50 millisecond thing. If you're animating, yeah, absolutely. To just repeat that, you'd be going for 60 frames a second and your tasks would need to be a lot, lot shorter. So if you're wondering how much of your recording is actually blocking, so how much of candy striping overall do you have going on in here? Well, we actually have this new metric at the bottom which says total blocking time, which you can think of as like the amount of candy striping that's in this recording as a whole. In this particular case, it's 230.05 milliseconds. And we have a link to explain what's going on. And you can see that that would take you over to the total blocking time metric information. So that's, so I find it quite interesting because we have the total blocking time is actually not necessarily the amount of time that the main thread has been blocked because you have a 50 millisecond budget per task that you're allowed to block. But everything that's over counts into that total blocking time. So that is the amount of time that you went over the 50 millisecond budget. Exactly. I should say that the total blocking time, we tend to stop it at one metric that is not shown here, which is the time to interactive. So when we hit an interactive time and the back end in blink actually notifies us that we've hit interactive time, if it can, we'll actually stop tracking total blocking time for that value at the bottom. But the candy striping here would tally pretty much entirely with that total blocking time. At the bottom, you've got this number 230.05 in this case. If that number starts to creep open up, that's something you're gonna wanna take a look at because that means that you're spending quite a lot of time with long running tasks on the main thread and the chances are it's negatively impacting the user experience. In this case, Web Dev is actually really good. It's just I had to introduce some slowdown, which is a good feature to know about that you can introduce slowdown both in terms of the CPU but also the network as well. You can do that if you so desire. So that's the total blocking time. That's long running tasks as well. We marked that at 50 milliseconds plus with the candy striping and the little red triangle in the corner. Now, the other thing we've also introduced is a thing called layout shifting. So if I just even go to the Google homepage and I do a recording here and I just refresh like so and I hit stop. Okay, what you're gonna see is you're gonna see a new track if we find any layout shifts and the layout track, sorry, the experience is the new track. It's called experience. And one inside here, we've got a layout shift and if we click on this, let me just bring this up so you can see a bit more, you get information on the layout shift. So the idea of a layout shift is, I think most people have experienced this, you're browsing the web and you're about to tap on a button and it moves to somewhere else on the screen and it's really frustrating. And so we're starting to give you the ways and the means of tracking those layout shifts in the course of, you know, interacting with your page and so on. And we put them into this experience track. So there's some stuff about scoring, which if you read the documentation on cumulative layout shifts, I will explain the scoring a little bit more to you. And you can also see whether or not it was in response to some recent user input. We also include some location information where you went from and you can see this here is this. So it's gone from here, this element has shifted to here, you can see that overlay. So I'm pretty confident I know what it is. It's probably this privacy reminder here that is coming on here. Now, one of the things that we probably need to add is which element it is specifically. And there is that information in the trace. It's just a case of plumbing it through. So that's actually something that I'm gonna hopefully look at. So maybe by the time you see this video, go and have a look in Chrome Canary. Possibly we've got the elements there. If not, what's doing the timer recording with screenshots help? So you can go through the film strip and actually see something shift in. That might be a good way to work around that until DevTools can pinpoint it for you. Yeah, absolutely. That's a great way of doing it. Often I think when it's your own code you have a fair sense of what's likely to be moving around. And the thing to bear in mind is layout shifts do cause problematic UX. And so it's a good thing to try and get those down and ideally removed if at all possible. And the way to do that normally is to reserve space for your content ahead of time in your style so that you're not just leaving content to just move other content out of the way. Sometimes it's not possible, but where you can, if you can mark certain areas as being the correct size ahead of time that should help an awful lot. So that's the layout shift information. So that's added in. So those are the main bits of performance. So in summary, we had the timings, which are here, we've got the layout shifts and we also had long running tasks which we show on the main thread with the candy striping and the red triangle. So in DevTools, we have also been working on WebAssembly and the debugging experience that it gives you because you write your code in whatever language, then you compile it to this VM bytecode and you kinda don't wanna step through the bytecode. You wanna step through your original code that you wrote. And for the longest time, WebAssembly and DevTools used source map, source maps to define that mapping from the compiled WebAssembly binary code to the original source code. And source maps were kinda built for JavaScript and minifiers and transpilers. And so that worked quite well, but it's also lacking some capabilities that are quite important. So I have little examples. C code is actually a sample from M script that I just simplified a little bit. It just draws a little gradient. It doesn't really matter what it does, but this is C code. And I have compiled this to WebAssembly with our new debugging experience because in native land, in binary land, there has been a debugging format called Dwarf for a very long time that has all these capabilities, but until recently, DevTools didn't understand it. So now we have compiled this to WebAssembly. This is what the output looks like. It just draws this little nice gradient that you see on screen here. But what's cool about this is that now, if you go to the source panel in DevTools over here, we have our usual JavaScript files. We have our WebAssembly bytecode, which, that's not the kind of code you wanna step through, because that is basically assembly. And while that sometimes can be useful, it doesn't read that well, let's be honest. What you can now find with Dwarf support in DevTools is that we actually have a mapping to the original C++ file. Again, this also worked with source maps, but this has some more capabilities. So I can now set a breakpoint here in the C code. Actually, let's set two breakpoints, why not? And so if I reload, the program will be halted once we reach that breakpoint. And then we can continue going through it as we're used to. And you can see the UI updating. So if I now step over this SDL unlock surface, whoop, the gradient shows up because we're actually stopping the program and updating the UI as we go along. And I think that's pretty cool. So now the- The question now for you there, Serma, is are you able to inspect, say the values of like i or j or alpha and those kinds of things in your loop? So for example, if I hover over this, nothing shows up. And that's exactly the capability that does. For example, I was also missing with source maps because source maps can't really handle renaming of variables very well. Dwarf however can. So while we are using Dwarf to have a more efficient debugging experience, the capabilities are potentially possible. We haven't quite built that part yet. So we are using Dwarf to allow you the old experience of stepping through and break-pointing and all these things, but you can't quite inspect variables yet, but we are working on that. And only now is it even possible to build. So that's really the exciting part here. The other part is that we are no longer using a WebAssembly interpreter during debugging but actually our baseline compiler. So usually in the olden days, when you would start debugging your WebAssembly source maps, you would actually experience a much, much slower WebAssembly execution. So if you had a long loop and you went to a breakthrough, it would actually have to wait longer until it is done. Now we are at the baseline compiler which generates much more performance code under the hood so you can debug with higher performance. And if that isn't a great tagline, I don't know what is to be honest. So you've kind of pointed at this, I think, a little bit. This is experimental. It's still a work in progress. If somebody wanted to actually try this out for themselves in Canary, what would they do? Where would they go? So it is currently in Canary. It is still being worked on. So in the last couple of days, it kind of oscillated between working and not working. Sometimes I could set break points, sometimes I couldn't. But we are on track for getting this ready for stable. I don't know if we've set a milestone yet. If so, I will update the description of this talk accordingly. But if you want to play around with this, please do. If you just Google for M-scripten and Dwarf, the most recent release now has support by default for these Dwarfs debugging symbols. So if you just update your M-scripten to the most recent release, this should just work out of the box. Just to be clear, there is no source map file in the file that I'm serving. So source maps cannot have provided this debugging experience. So this is definitely using the Dwarf symbol that are in the WebAssembly binary. Cool. Well, with that, I think we have covered what is important and new in DevTools, didn't we? No, I've got more stuff to show you. I've got the issues. You have more stuff to show? Yeah, switch back to me. Well. All right, so the next thing I want to show you is the issues tab. Now, you're similar to me, I think. When you see lots of warnings and messages in the console over here, you kind of go, sure, and you start to kind of mentally filter those out and maybe if you like me, you kind of clear the console and you sort of think, okay, it's just too busy, just too noisy, I'll kind of deal with those at some point. Well, if you are like that, completely understand where you're coming from. So we've added this new thing, which is the issues tab. It says the issues have been detected. So if you see something like this, we've detected some issues during the execution of your page and you can go to the issues tab, which opens a new tab here. Now, sometimes if the page is already loaded and you bring up the console, it might say, well, there's possibly more information. Would you like to reload? So sometimes you'll get an option to reload the page and you might see more issues coming through that way. So you can see here that this particular page, some same site cookies, issues are starting to show up. So you can see I've got the issues listed here and I can spin this down and it gives me an explanation of what's going on and how I can resolve this issue directly. It also tells me which cookies in this case are affected and it also links me off to some information on web.dev about how this all works. It's also true of something like mixed content as well. So if I go to something with mixed content, which is HTTPS and HTTP mixed together. Similarly, I can go here and it says that there are eight cases where I have mixed content where all resources should have been loaded via HTTPS, but they haven't been and it lists again, it lists the requests and the resources in question. So hopefully that's going to make the console less noisy and makes it much more clear to you how you can track down any issues that DevTools has noticed in your site and your app. Okay, so the last thing I want to talk about is color vision deficiency emulation. So let me fire up this brilliant video of HTTP 2.3 and then pause it just a second. Yeah, talking about imposter syndrome, something I personally suffer from. So if you've not seen that, go ahead and watch it. It's a really good video. So what I've got on my screen, I've got the rendering tools inside of DevTools. Now, if you've not seen this, you can go to more tools and then rendering down here. If you click on that, this tab will pop up and there's a load of tools just for rendering inside of here. And since we're passing through here, the layout shifts that I talked about earlier in the performance area, layout shift regions. This is a live update version of layout shift. So if you're just wanting to see very quickly what layout shifts you have during the, you know, the lifecycle of your page, you can switch this on. And if you see blue flashes, then that's a layout shift that would have been caught if you'd taken a performance recording. Now I'm not going to show this today because as it says here, it may not be suitable for people prone to photosensitive epilepsy. And I want to be mindful of that. But if you think this is the right tool for you, definitely check that out when you're looking in the rendering tools. So if I scroll to the bottom here of this list, you'll see that you can emulate vision deficiencies. And if I start playing this video back, you can see that if we work our way through this list, we have blurred vision, which you can see applies a blur to everything. And I can still interact with the page. I can still click on buttons and so on, but you can see the content is completely blurred. We also have protonopia. And there is deuteronopia, tritonopia, and acromatopsia, assuming I'm pronouncing those correctly. If I'm not, then forgive me. I find it really cool that all these effects, so to speak, are applied to the page without disabling the interactivity or the animations or even the video. So you can really check if all your animation and the entire experience holds up when someone has one of these vision deficiencies. So I think that's just a really cool thing. Yeah, absolutely. So you might have noticed, so these seem fairly extreme when you look at this. It looks, to me, as somebody who doesn't have any of these vision deficiencies, these look like a very extreme form of change, visual change. So, I mean, I said this in the introduction with Dion earlier, but to say it again, these deficiencies that we're emulating are physiologically accurate, but the most acute form of that particular vision deficiency. So it's not on-off like we have emulated here where it's sort of no vision deficiency and then protonopia. If you have one of these vision deficiencies, it's much more likely to be a spectrum and you may have a certain amount of one of these vision deficiencies. So what we're doing is like, this is the most extreme version of all of these vision deficiencies and so that way you can make sure, if your page holds up in the most extreme case, your note will also hold up for any less severe case. You can make sure your website remains usable for anyone really. That is exactly the idea behind it, exactly that. If you're optimizing for accessibility, you want to be as confident as you can be that you're capturing the colors and the contrast and all of that stuff in the most helpful way possible. And so by going for the most acute version of these vision deficiencies, exactly as you said, you can optimize for those and then anything up to and including those will also be covered as well. So that's as we've talked about the issues tab. We've talked about long tasks. We talked about layout shifts, color vision deficiency and WebAssembly debugging with Dwarf. I know, right? And that is quite a lot of new things in DevTools and you should definitely try those out. Absolutely, yeah. So if you want to try any of these out, probably the easiest thing to do is to fire up Chrome Canary, give them a go. If you run into any issues, you can go over here to the help menu and you can report a DevTools issue which will create a bug and you can fill that in and that'll make its way. AKA your inbox. I really hope not. So with that, thanks for watching and I guess we'll see you around. See you around. Bye.