Lighthouse Audit Exercise

[00:00:00]
>> Jon Kuperman: For the next thing, we'll go to the Exercises, and we'll go to Lighthouse, and we will see this very slow page. And yeah, please go ahead and run a Lighthouse audit on this. You've sort of got two different options here. If you'd like to just kind of loosely follow along, run the Lighthouse audit.

[00:00:14]
And then just kind of read through some of the things and make sure you understand and internalize them. If you have the code running locally, please feel free to go ahead and change the source code, according to the suggestions. And then reload the page and see if you can get your Lighthouse scores at least up into the green somewhere.

[00:00:30]
>> Speaker 2: How would you compare Lighthouse to PageSpeed Insights?
>> Jon Kuperman: Yeah, that's a great question. So I think that, in many ways, Lighthouse is the new and reimagined version. I think that if you were to go with one, going with Lighthouse would be great. In a lot of ways, PageSpeed Insights is a subset of the Lighthouse rule set.

[00:00:49]
I do think that if you have a current workflow, like a CI workflow with PageSpeed Insights, that's excellent, that's really great. I don't think there's a big call to migrate over, but if you were starting something new, I would go with Lighthouse. It's got a lot more contributors, it's a lot more open and established, and I think it's really well thought out.

[00:01:06]
But it's one of those things I would not recommend switching for the sake of switching. If you've got a workflow that's set up with PageSpeed Insights, that's great.
>> Jon Kuperman: Cool, yeah, I wanted to give a call-out here for this exercise. And then going forward, I think there's slightly more value you get out of running the code locally, whereas the previous exercises were identical.

[00:01:30]
So just another call-out if you wanna go here and grab this and then just run it with a simple HTTP server. It can be a little bit more fun as you're going through. Again, completely optional, feel free to use masteringdevtools.com, but if you wanna really get in there and mess around with stuff, local can be a bit more fun.

[00:01:47]
So cool, let's run through this together. It's a very tricky balance making the most annoying site I can, but then also knowing that I'll have to be live in front of a lot of people and not lose my cool while trying to mess with the site. Maybe I went a little overboard on annoyance with all these pop-ups.

[00:02:03]
But okay, so we'll analyze page load, let it go. It's quite a lot over these requests. No, just do what you want, just do it. Okay, great, so we did pretty poorly. Boy, [LAUGH] yeah, I saw, I can't remember where it landed. There was a cool discussion about all these pop-ups for location and all these different permissions that were Chrome, I think was like, we wanna make it more punishing.

[00:02:33]
Where if you click no, then you as an app developer have lost your opportunity, you can't pop it up again, basically. I don't know if that went through or not, encouraging you to be like, wait until I hit open map and then ask for my location, don't just ask.

[00:02:47]
But anyway, I digress. Okay, so we did pretty poorly on these things, but I think it's a cool opportunity to look through a whole variety of things that may have gone wrong. How did people find it? Was it somewhat digestible as you were kinda clicking through? Did the messages make sense?

[00:03:01]
I think they've done a really excellent job with that. So yeah, I think this is good. So we can see right away, the first paint took too long. We didn't have anything blocking, no layout shifts, which is nice, but just in general, we did very poorly on the speed index.

[00:03:14]
And then if we wanna drill down into why, we can start really looking at these things. So largest contentful paint, we can see here. And this is the element that was given the largest contentful paint, and we can see that it took a long time. So we can kind of start going through these and kind of putting together an understanding of why this might be so off.

[00:03:33]
So we can see there's a lot of JavaScript, if we minified it, we would save 56 kilobytes. So that's important, that's like gonna be blocking as it's parsing and things like that. Images are not in next-gen formats. So we can see here that we've got this big image of the cat here.

[00:03:49]
And it looks like the cat is a, it doesn't say what the format is. Images, it says what's better, I guess-.
>> Speaker 2: It's a JPEG.
>> Jon Kuperman: Yeah, right, I guess I was surprised it doesn't say. But we can go over to the Network tab and I think we could do a refresh there and see that it's a JPEG and see that there are better formats out there than JPEG like WebP.

[00:04:12]
So yeah, so that's cool, so we've got too much JavaScript. We've got a big image, we've got no caching policies, we've got a bunch of unused JavaScript, which I always find a really cool thing. Caveats here, so I guess a few years ago, DevTools added this unused concept, right?

[00:04:25]
So they have unused JavaScript, unused CSS, and that's really great, because I think we can accidentally ship a bunch of stuff, especially with CSS. Sometimes I look at what's unused, I'm like, yeah, I totally got rid of all those elements. But the important thing for long-lived applications is It might be unused now, but it doesn't mean it's always going to be unused.

[00:04:45]
So you can't necessarily delete unused CSS because what if you have a modal that pops up later during a workflow and that's what needs it styled? So you do need to be context-aware when you're looking at these unused things. That being said, if you don't need it till later, then you could defer the bundle itself from loading too, right?

[00:05:03]
You could have that JavaScript and CSS bundle. So it does get a little bit tricky, but I think unused is a very good metric. It just doesn't mean you can just delete anything that's marked unused and be okay. Cool, so yeah, so basically I think we found some really good stuff here, a ton of JavaScript, too big of an image, the image is in a bad format.

[00:05:22]
We get this kind of nice picture, where the first paint was blocked for a really long time. That being said, there weren't any layout shifts, and we were interactive right away after we loaded. So that's 65 out of 100, I think that puts us in an okay spot.

[00:05:35]
Accessibility, did really badly. Mostly, we have these things, we have this aria-hidden on the document body, meaning the whole document won't be accessible to screen readers. That's a real problem. And then we have these aria-hidden elements that have descendants that are meant to be focused. So we're basically saying, you can't focus on these things, and later, we're saying, this needs to be focusable.

[00:05:56]
So again, this gets covered a lot more in-depth in my accessibility course, but we could do some really nice things. We go through the code and we could remove these aria-hidden tags, which probably aren't doing us any favors. We also have the document with no title element, so we don't have a title up here in the head for the screen reader to read out what document you're on.

[00:06:14]
So we could probably fix those things in three minutes and get some really nice gains out of that. Moving on to best practices, we've got this thing that it catches, wherever you prevent users from pasting into input fields. Remember this from our essential one. We also don't have a meta viewport.

[00:06:31]
And again, if you're curious about these things, why do we need this meta viewport, we can see that it basically helps your app be optimized for mobile screens. So it can provide a really big boost to your app's loading time if you add these these viewport tags, and you can click through here to see a bunch more information on it.

[00:06:47]
And similarly, for SEO, we don't have the title element. I think this is an important caveat here, cuz I do a lot of teaching on performance, I do a lot of teaching on accessibility and the crossovers. Being good at one, or helping your website with one, helps it with the other so often, which I find really nice.

[00:07:03]
So thinking about it for an example, adding a simple title element crosses over the threshold between SEO and accessibility. So accessibility for the screen reader reading what document you're on, and SEO for the search result knowing what to display. But this is similarly true, for example, keyboard shortcuts or any kind of partial loading, where something comes in later.

[00:07:25]
For an accessibility standpoint, you can add aria attributes and have the document announce that an image has just loaded in. And from a performance standpoint, you cannot load that image immediately cuz you don't need it yet. And so I find that the crossover between these things is very pleasant a lot of times.

[00:07:40]
Where if you make your website very SEO optimized, you'll often get performance and accessibility wins just by virtue of doing that, and vice versa when you do a full audit. Another one's semantic HTML, that can be faster cuz it has to do less laying out and it can also be more accessible.

[00:07:56]
That's another one of switching from divs with click handlers and all this JavaScript to a button, something like that, can give you all these different ways, which I think is kind of nice. So yeah, we don't have our meta description, we don't have our title. So yeah, hopefully this one went well.

[00:08:09]
This is a really nice starting place, just go hit your app with Lighthouse, get an initial idea. Does anybody have any Lighthouse questions before we move on?
>> Speaker 2: Looks like the unused JavaScript shows the particularly large JavaScript files in their modules, is there a way to see that total list of unused JavaScript rather than just the top ones?

[00:08:28]
>> Jon Kuperman: Yeah, so let me actually look into this, because there used to be quite a cool thing. This might take me a minute to find.
>> Jon Kuperman: There is quite a cool,
>> Jon Kuperman: Yes, this. So check this out, let me make sure it's the right thing before I show you how to get there.

[00:09:02]
>> Jon Kuperman: Maybe this isn't what I thought it was. Yeah, okay, so here, does this only work with CSS?
>> Jon Kuperman: Give me a second here to kind of figure things out. There's a really nice workflow. Yeah, so okay, let me back it up then, now I can act all polished about this.

[00:09:27]
Yeah, so this is great. So the Lighthouse audit can give you this basic concept of unused, and it'll show you the largest ones that are unused. Because the point of Lighthouse is trying to get you the lowest hanging fruit to get your site faster. But the Chrome DevTools actually provides a really nice, deep insight into unused code, both JavaScript and CSS.

[00:09:46]
And in order to get there, you can open up the DevTools, hit Escape to open up this little subpanel. Then you can click on the hamburger menu, you can click into Coverage. And then when you click into Coverage, you can do another refresh of your website. And what this will do is it'll list all of your CSS and all of your JavaScript.

[00:10:02]
As well as when you click on one, it will show you in the Sources tab what is used and what is unused. And so it'll show you these big blocks of red, like this page doesn't have an image on it, so this image CSS is unused. Similarly, if we had anything here, I think we use 100%, but you basically can get this really granular view of each file.

[00:10:21]
Which type it is, how big it is in total, how much of that is unused, and then a little visualizer of it. Does this make sense as a concept? So having a more deep dive into out of my CSS, 50% is unused on this page, out of my JavaScript, 0% is unused.

[00:10:35]
So you can really see what ran and what didn't.
>> Speaker 3: How did you get to that coverage page?
>> Jon Kuperman: Yeah, so let's do it one more time cuz it's a bit sneaky. So from any page in the DevTools that you have open, you can hit Escape, which should pop open this little subconsole here.

[00:10:48]
And then from there, you get this hamburger menu, which has a bunch of really cool stuff. We will cover this at the end, under experiments, but we has a bunch of cool stuff here, one of them being Coverage. And so now, with this selected, whenever you hit Escape, on and off, you'll always have access.

[00:11:01]
So you can kind of redesign your little bottom tab to have whatever you want on it. But this is really great cuz you can really dive in, you can be like, okay, what is being hit, what is not being hit in all my JavaScript and CSS?
>> Speaker 4: Sometimes if I want to go to the website, I only use the one style CSS.

[00:11:20]
>> Jon Kuperman: Yeah.
>> Speaker 4: And sometimes you can go to some page who don't use a lot of-
>> Jon Kuperman: 100%, yeah.
>> Speaker 4: So if I see something like that, it's better to have a file for CSS or-
>> Jon Kuperman: I don't think so, it's a great question, because it's like these tools are useful but they're also deceptive.

[00:11:39]
So yeah, he's saying, you imagine you have two pages, right, one and two, and you have one style.css, which has all the style that you need for both pages. So you go to page one and you look at coverage and it's like half of this is unused but it is used, it's just used on the other page.

[00:11:52]
So kind of should you break up your styling by page or is that not necessary? I think it's like you have to make a personal choice on. I think if you have a tremendous amount of styling and a lot of pages that people spend a long time on, it could be beneficial to bundle each page so that each page only has the JavaScript and CSS it needs.

[00:12:12]
I think a lot of the time, you're completely fine with a single style sheet for your entire application. I do think it's worth considering, though, I think you should think about how much you would save. So let's say we had one style sheet, it was 100 kilobytes for two pages, and they're 50/50.

[00:12:27]
I think it's probably worth it to break it up to save the user from downloading 50 kilobytes each time. If it's small amount or there's a lot of shared code, then probably not worth it. I know that's a hand wavy answer, but I think I wouldn't necessarily jump to making chunks, but I would consider it as a tool in your toolkit cuz it could be worth it.