Check out a free preview of the full Mastering Chrome Developer Tools v2 course:
The "Audit Solution" Lesson is part of the full, Mastering Chrome Developer Tools v2 course featured in this preview video. Here's what you'd learn in this lesson:

Jon walks through the solution to the Audit Exercise by conducting audits through Lighthouse service and inspecting elements with DevTools. Jon reviews common problems that are discovered from audits. - http://gzipwtf.com/

Get Unlimited Access Now

Transcript from the "Audit Solution" Lesson

[00:00:00]
>> Jon Kuperman: All right, so this page needs an audit. It really does. You can just tell by refreshing it that some things are terribly awry. So for this one, we have two options. We could use, since I put the site up in masteringdevtools.com, we could use one of those external services, like sonar wall or,

[00:00:22]
>> Jon Kuperman: WebHS, but since this is local, I'm just gonna use my house tools. They also happen to be my favorite. So yeah, probably just do a performance audit to start off and do Run audit. It does the refresh for me in the background, and then it starts compiling all that information.

[00:00:39] Again, I think this is just a really great place to start because people are like, we see a lot, especially online, about these small optimizations of things you can do with JavaScript to be a little bit more scope hoisting and all the stuff like that. And those are really great, but I think those should only be done after you've done your initial sweep, and how are your images looking?

[00:01:01] How big are your CSS and JavaScript bundles? You know, these very basic things. So I really like the audit as a first place to start before you go down the rabbit hole of these micro-optimizations or looking for memory leaks. First, just be like, how big is the site?

[00:01:15] Is there anything that I could do in an hour that's gonna make a massive improvement on load time? So when this is loading, it has all these cool little pieces of information, again, some of those stuff, like Google's been collecting a lot of data on mobile use, on Internet speed, on the percent of the world that's online.

[00:01:31] And the more you read about that, the more it's like, okay, well, how does my site look on a 2G connection? Wow, 30 seconds to load. It's these kinda things, where if you're building something, especially if you're in social network or you're building a very public app that you want the world to use and it's that slow, that's gonna be a really big barrier to entry for people.

[00:01:52] Cool, so it's loaded. I've got 71 out of 100. That's passing, right? I think I'm proud of that, great. So yeah, first meaningful paint at 270 ms, that really isn't that bad. The problem, if we look at the screenshot here, is that none of the images are there, and the images are pretty vital to this experience, right?

[00:02:13] They also move things around, move the page around. So the first interactive is also really not bad, 520 ms. So what we've seen with the screenshots, right, is that there's nothing along here, and then boom! The HTML and CSS, they load really quickly, and that's great. And for a split second there, you're able to click around, do something like that.

[00:02:36] And then we start getting into trouble here. We start loading these big images in. They're not coming in asynchronously, and it just blocks up the thread again. So you get a little moment where you can be interactive, and then for the rest of the whole time with the audit, it was not interactive.

[00:02:50] It even says, your page took too long to load. So that'd be a big thing is making sure that the site stays interactive at this point, and we do that a couple of different ways. Offscreen images, I really like this. So it's just like you have these images.

[00:03:04] The user can't even see everything you're loading. You're literally making them wait for stuff they can't even see. It might be a little misleading, cuz probably, what we should do is just size down these images. They're not fully offscreen. They're just partially offscreen, but it's good information. Properly sizing images.

[00:03:22] So again, these percentages are huge, right? You could size these to be the space they're actually taking up, and you would save 50, 60, almost 70% here. Has enormous network payloads. The total was 9 megabytes. That's totally, totally unacceptable. It's huge, I think people are always throwing numbers away.

[00:03:45] But I've heard, I think, people from the Chrome team talking about. I might get this wrong, but I think it's around 250 KB or something like that for your critical render. And that will be after GZIP so you have more room to work with. But anyway, we should try to get it a lot smaller, like Mark was talking about before with frontendmasters.com, where they inline stuff.

[00:04:05] They have this really critical bundle, send that down to page loads. And then they start doing their work, right, cuz at that point, the user is happy. They can see stuff, they can read stuff. Now you can load in those images and polish up the experience. So yeah, these images are huge.

[00:04:18] They took a super long time to come through. And I think if we go back over, there's some other tools that can help with this audit. So if we go to the Elements panel and we look inside of these images, you get this cool thing. So it shows you how big the image is currently on the screen right now.

[00:04:34] And it shows you how big the image is that you're sending down. So our max screen width is 1280 pixels, but we're sending down a 4700 pixel image, right, so it's huge. So the things that we'd wanna do here to fix this. We'd wanna, first of all, take all those images and size them down to be the correct size.

[00:04:52] Then we'd wanna run them through some kinda image optimization, which is gonna, whenever you make images and whenever you edit them with programs, they leave behind all this meta information, like its name, its size, last modified date, all this stuff that you use in your file system. But the web doesn't need that, so you can strip all that out and get big savings.

[00:05:09] The next thing we'd wanna do is go to our server and GZIP everything, right? You'd wanna compress everything that you have. There's some really cool websites out there that can help you see how many of your things are being compressed. They really should all be. It's usually pretty easy to enable compression on your site.

[00:05:24] So if you're using something like PHP and you have an Apache config, there's just a GZIP Apache plugin that you can install and just be like, GZIP all the things. If you're using Node, whatever framework you're using, there's definitely a compression plugin for. So if you need express, there's one that's called compress.

[00:05:41] And you just do app.compress and it just compresses everything. So for those unfamiliar, GZIP is a compression format that the browers can decompress. And so that means that it's just a way that you can make files smaller on the server and the browser knows how to make them back into regular file when they come down.

[00:05:58] So you get these huge savings for free. There's a bunch of really cool proposals now. There's more compression formats that we can use. So some people may have heard of Brotli, or there's one new one. I think it came up in the DevTools Audit. I can't remember what the other one is called, but there's a few different ones.

[00:06:14] Those are all great. Whatever your server can support would be totally awesome. I think the newer ones are a little bit better, but doing it is just such an order of magnitude better than not doing it. So finding some way to compress all your stuff on your server should be a pretty huge win.

[00:06:28] Other than that, we can see we're sending down libraries that we're not really using. So if we go and do a best practices audit here,
>> Jon Kuperman: We can get a bunch of other information about, like things that we could just be doing better. But I would say, typically, the biggest thing that you're gonna see is stuff is too big.

[00:06:59] And so if your images are too big, there's a lot that you can do that's really helpful. If your JavaScript is too big, it gets a little harder, but the thing that you'd wanna do is split out your modules, right? You wanna have your critical rendering stuff and then lazily asynchronously load the rest.

[00:07:11] Same with CSS, if you can split it out and load the rest. And then on top of all that, you should also just make sure that you're compressing everything. So really, the name of the game with a lot of that load performance stuff is just getting as little as you need to send and compressing it as much as possible.

[00:07:26] Yeah, I like this statistic. 75% of global users around 3G or worse connections is when you start thinking about how slow that really is, or if it takes five seconds to load on this great connection, it's gonna take a lot longer to load. So again, you could use HTTP/2 if your server, your CDN supports it, again, with these vulnerabilities that we can remove, things like that.

[00:07:48] Those are all wins there. Again, not chasing for the perfect 100, but just seeing how much stuff we could probably knock out in a day, right? We can add compression, shrink the images, remove their metadata, and remove unnecessary scripts. We can probably do that in an afternoon and get huge wins out of that.

[00:08:03] Any questions on the auditing tools?
>> Jon Kuperman: Somebody put it in chat. Zopfli, that's exactly what I was thinking of. That's the new compression. So there's GZIP, and then Brotli, and then Zopfli, I don't know how to pronounce it. But they're all great. It's just up to what your server supports.

[00:08:20] Cool, so yeah, the most common stuff that we see when we do these audits is combine your scripts together, your CSS and your JavaScript. Enable compression, compress your images. Browser caching is another one. Just make sure that if you're doing fetch request for things that you have a cache, say, in cache settings, so that if you have to fetch again, it'll just read from disk.

[00:08:42] Make sure your CSS goes in the document head. And then a lot of things, like when we use these JavaScript or CSS libraries, they're often a lot more than we actually need. So a lot of people are including all of Bootstrap, and they're only using the navigation and the grid.

[00:08:57] So finding some kind of build system that can do dead code elimination. There's a bunch of really great courses on Frontend Masters around Webpack. Webpack's a really powerful bundling tool that can really help you, like dead code eliminate, split your modules out, really help you get your website going really quickly.

[00:09:12] I highly recommend those courses.