Lighthouse Web Audits

[00:00:00]
>> Jon Kuperman: For this next section, we're gonna be talking about Lighthouse web audits, and I think Lighthouse is the best introduction into these performance characteristics in general. So before now in the course, we've been covering a lot of observational stuff, observing the network, observing the DOM and the CSS, and playing with all that.

[00:00:18]
But we haven't really gotten into, how the application actually functions, fast or slow, and I think Lighthouse is like the best first start because it's super user friendly, it's pretty well-defined issues. And we'll kind of use Lighthouse to kind of eventually springboard into the performance and the memory tabs themselves.

[00:00:36]
So Lighthouse and, tools like it have kind of a long history, as I mentioned in the DevTools history, I think the first application to kind of do this, at least the first popular one was YSlow. I may well get this wrong, please correct me in the chat, but the first one that I kind of heard of, and so this was a browser extension, and you would install it, and it would do a lot of the similar things.

[00:00:59]
The idea is that it has some rule set of what makes a fast application, it refreshes the page, it measures a bunch of stuff by adding instrumentation. And then it gives you back, sort of like grades or scores, based on how long yours took to do X compared to the average, something like that.

[00:01:16]
I think they're a really cool idea. I think that with the web vitals that we have now added, and those being kind of open source and openly discussed, we've gotten to a really great point with this kind of performance audit. But I think this idea has been around for quite a long time of just like a top-level analyzer or overview of your site.

[00:01:35]
Google had their own before Lighthouse called Page Speed Insights, very similar. You would run a web URL. It would run a bunch of things. Some of the limitations here are, they wouldn't work on local projects, right? They would require an external URL. So you'd have to deploy your project before you could run an analysis with them, which also meant that it was like hard to recreate certain conditions and run the analysis, but they worked pretty well.

[00:02:00]
So then many years ago, Google added this new idea of lighthouse, and with it, instead of being a website that you would run, they added it to the Chrome Dev Tools. And therefore, you can run it on any specific conditions with any kind of local application. And the basic way it looks is like this, we covered it a little bit ago.

[00:02:17]
But you started choosing what kind of device, which sections or categories of audits to run. And then this kind of different mode of should we snapshot what it's like on the initial page load, what it's like right now, or do you wanna capture a time span and we'll analyze those things?

[00:02:32]
Which I think provides us with some really good flexibility for analyzing, you could have a simple, hey, this is my marketing page. How fast does it load? You could also have, I have a long running application, like a video game, and I really wanna just capture an audit of this specific action, so cool.

[00:02:49]
So the thing to talk about here is these categories, so we have performance, accessibility, best practices, and SEO. For the performance category, we're basically we're looking here at page load speed and responsiveness, how fast does the page load? How quickly does it become responsive? And does it stay responsive during the time span?

[00:03:08]
What resources are used and fetched, like JavaScript, images, fonts? Do those things block the render? Do they block the main thread? And this is really where a lot of these web core vitals come into play. So it'll measure your first contentful paint, the largest contentful paint, how much cumulative layout shift there was during loading, how long time to interactive like, how long it took until the page is usable.

[00:03:31]
Hover and clicks work on the total blocking time, so any delays caused by scripts loading in, a lot of larger companies will kind of invent their own. The one that I always liked when I worked at Twitter was we had time to first tweet, which would be how long does the page load take before you could say hello and tweet it out, basically.

[00:03:48]
How long does it take before the first tweet is loaded in your timeline and you can actually see it? So, larger companies might come up with their own kind of ideas here, but these are really nice generic ones where these are some important things to know. So that's the performance category, then we have the accessibility category, basically, how compatible is your website with assistive technologies?

[00:04:06]
Somebody's using a screen reader, if somebody needs keyboard shortcuts, does the markup render properly? Does it make use of ARIA roles? Are the colors compliant? Is there good enough contrast? All sorts of things like this. So it's a really nice way of automatically sort of running it, checking for images, and whether or not they have alt attributes so they'll read aloud to screen readers.

[00:04:27]
Whether forms have labels so the screen reader could read it out. One caveat with all these things is really nothing beats real users really using your application. For both accessibility and performance, the best kind of thing is to user case studies or real user metrics, things like that, but as far as automated stuff that we can do and we can add to our CI/CD pipeline, this is very good.

[00:04:51]
The next one is best practices, so this is like quality of your code and security, so making sure that all your connections use https. There was a big push years ago, when we used to say HTTPS is good for these types of requests, HTTP is better for these types of requests, we have fully moved on to the all HTTPS.

[00:05:09]
There was all those cool initiatives, like HTTPS everywhere and the, I can't remember the name of it now, the free HTTPS certs initiative
>> Speaker 2: Let's Encrypt.
>> Jon Kuperman: Let's Encrypt, backed by all these major companies, so it's free to get these certificates now and most deployment sites install them for free.

[00:05:27]
So we're trying to move over to everything being HTTPS, no matter what it is, not using any deprecated APIs, things that might break your website later. Security concerns, like not using inline styles or JavaScript that could have cross-site scripting attacks, efficient use of browser features. So if there's a better image format you could be using, make sure that you're using it, things like that.

[00:05:47]
The last one is SEO. So search engine optimization, making sure your application is as discoverable as possible. This breaks down into just a lot of different things, can the page be crawled by SEO bots? Is it mobile friendly? Does it use the correct status codes? Are the meta tags there?

[00:06:02]
This might be important to you, might not be important to you, if you're building a internal only tool, this might not be the most important thing. And that's why I think it's cool with Lighthouse that you can toggle the things that you care about, so if you don't care about SEO, you can toggle that off and it'll make the Lighthouse report a bit faster to run, cool.

[00:06:19]
With that, let's move into a lesson where we can kinda go together and look at a Lighthouse Audit together, and then we'll move into an exercise that you all can do on your own.