Lighthouse Audits

[00:00:00]
>> This is really, really cool. So, Lighthouse is the last tab we're gonna kinda cover here. When I did this talk last time, Lighthouse wasn't in the panel, and was it's own separate website. It's a open source initiative that came out of Google. It's really well maintained with all these rulesets and tests for web performance.

[00:00:24]
And I used to have this advice where I was like, if you're doing a local app, you got to use Audit. But if you have an app on production, go check out lighthouse. It's like the best. And now Lighthouse is here in the tabs, which I'm like, just very giddy over because it's just so good.

[00:00:38]
All the rules are open source and online and a ton of people contribute to it. And it has all these different categories, which are somewhat self explanatory. They're maybe a little complicated, but so performance is going to be initial page load performance, very similar to what we've been doing manually with the network stuff.

[00:00:57]
Progressive Web App is going to check, does it service worker does it work offline. Does it have a manifest? All these great things for progressive web apps which we're not building right now, best practices is gonna be just a lot of normal stuff about the images and compression and all those different things.

[00:01:15]
Accessibility is hugely valuable, I have an accessibility course on Frontend Masters but making sure that interactive elements can be done via the keyboard, making sure that color contrast works well for people with different vision impairments. All sort of things like that making sure screen readers are going to have an easy time reading your content, to non sighted users.

[00:01:35]
And then SEO, just making sure that you're doing kind of the basic things for Google to be able to track your website well and for other search engines to track as well. So I think for now, let's just go through, let's just generate a mega report. And this is keeping in mind that we know that we're not a progressive web app.

[00:01:50]
We know we don't have any of those features. So, you click what you want, and then you click Generate Report and it's gonna do a bunch of stuff in the background. It's going to refresh the page and stuff like that. And so you get this very, very nice easy to parse, 0 through 100 score on all the different categories.

[00:02:08]
So you can see it's pretty cool. I found that we're not a progressive web app and instead of giving you a bad read score, it's just kind of grayed it out. We get 100 number Performance, 90 on Accessibility, 93 on Best Practices, 78 on SEO. So let's just start looking through.

[00:02:23]
These are like, sometimes I think about things that I'm like, you could probably just make money just by offering people who have business websites and aren't super tech savvy, probably just honestly like run Lighthouse, print it out and go talk to them about it. It's so valuable even though it's free, it's just so cool to be able to see.

[00:02:43]
So on the Performance tab, that's the onload performance. We can see all these great things like how long it took for the first contentful paint, how long it took before the site was interactive. For those of us that work at big companies, we probably have a few of these metrics that are mandated, like time to first byte or first contentful paint.

[00:03:02]
Those will be things that we need to keep the app on a certain time. So first contentful paint is like we talked about on there when the page renders the first time and time to interactive. I've seen this on some slower sites where it's loading that is blocking the main thread where you can't click on things, you can't scroll, you can't click on a button.

[00:03:20]
So that's time to interactive before. The main thread is free enough that you can do stuff again. Largest contentful, paint, layout shift, all these different metrics. And what's really cool with these is if you get one red or yellow, it'll flag you with a page for each and every one of them where you can click on the page and go to this really nicely maintained dock for like, well, why am I getting that?

[00:03:43]
What can I do? What's the problem here? I know I'm gushing over it, but it's just so awesome. Lighthouse is such, such a great resource. Cool, so kinda scrolling down. You can also see, I know these are all mini. Remember I said that if you have the Dev tools not popped out, the screenshots will be really tiny.

[00:04:01]
So here is just little tiny screenshots of what's going on up there. And then it has suggestions. So here it can says the only suggestion normally you get a lot is that you could save 100 milliseconds or something like that if you eliminated render blocking resources, and specifically if I extend that it's the custom font that I use.

[00:04:22]
So I have a custom font. It's pretty small. But if I got rid of it, then I could speed things up a lot. The other thing you could do is, you can do that. Have you ever loaded a site and it loads with a system font and then it changes into being a custom font.

[00:04:36]
You guys do that. I mean, it's gonna be a lot faster or not maybe a lot, but it'll be somewhat faster but at a worse user experience. So kinda your choice. And then here's all the things that, these are not marked red. So, if they were I could go and read into those more, if I was messed something up.

[00:04:53]
And then here are the ones that are passed audit. So you can see these two. These are all the things that would flag, if you're on a production site, and it had any of these issues. Next one accessibility. Same thing, it just gives you immediately useful, very helpful stuff.

[00:05:07]
So it's like, this HTML element doesn't have a Lang attribute. And it has this whole important thing about screen readers. If you don't set a language on the HTML element, they will use the user's default language. So if you are a Spanish speaking user on a Spanish screen reader, and I have an English website, but I don't set the Lang, it's going to try to read it in Spanish because I haven't set the Lang.

[00:05:29]
So, immediately very, very useful stuff that you honestly could just go, just follow along and kind of fix all these things. Then again choose all the passed audits that we got. I will give a caveat here. Accessibility testing like automated testing has come such a long way. And I know that sounds a little cliche, but it's especially true with accessibility, like really nothing beats the real thing.

[00:05:52]
Nothing beats actually getting a user on and trying to tab around and make sure, because things might have tab index, but they might be unintuitive or clunky. And Chrome Dev Tools won't be able to catch that. So this is a really good starting point. These are easy things to fix, but accessibility is very subjective.

[00:06:10]
For making a good experience, it's a little bit harder to lint and better to have somebody on your team that knows how to use a screen reader and knows how to tab around and make sure that it feels good. That feels nice. Another thing, best practices, missing one where there's no doctype set.

[00:06:28]
So again, on the HTML, you might how you usually do like doctype HTML, or whatever, sort of a relic back to the old days where we had, before HTML5, we had all these specific doctypes and these specific modes that browsers would. But again, you can go to the Learn More and it'll just tell you to put doctype HTML at the top of your page.

[00:06:47]
And then here are the audits I passed. Coming to SEO, I don't have a meta viewport tag. And so this helps mobile devices know how to scale so they don't have to pinch to zoom. Have you ever loaded a site on your mobile device and it's like super mini, and you're trying to zoom into it?

[00:07:02]
So this meta viewport can help with that. And there's no meta description. Again, not an SEO class, but these are things that help the search engine know more about the page so that they can index it better. Cool, and then PWA. I failed a bunch of things, but it's not a PWA.

[00:07:19]
That's okay. So it said, hey, we went offline and we expected to 200, we didn't get one. It doesn't have any service workers at all. There's no web app manifest. I mean, these are things we know because it's not a progressive web app. But if you do have one working on mobile.twitter.com, and you want it in the App Store and you want to, make sure that you pass all these PWA tests as well.

[00:07:40]
Cool, and then it's got a bunch of meta information, just about what slow down it used, what site it was, all these kinda great stuff.