This course has been updated! We now recommend you take the Introduction to Dev Tools, v3 course.
Transcript from the "Audits Panel" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Jon: So the next section, we've now done editing, debugging. Now, on to profiling which is we're goinna spend the rest of our time. Cuz it's profiling, there's a lot of stuff going on there. So to start off with, why is profiling important? And this deviates a little bit from the dev tools aspect and more into general web performance.
[00:00:26] Why you should care, what you should care about, those kinda things. For those who are familiar with WordPress, it's got a bunch of really cool caching plugins. And one of them is called W3 Total Cache. And they did some research awhile ago and they got these three statistics.
[00:00:42] These are from a few years ago but are really mind blowing to me. So Google had an experiment in which a 500 milliseconds, so a half a second speed decrease on their search results was a 20% traffic loss for them. Similarly, Yahoo had one less than half a second speed decrease was five to 9% traffic loss.
[00:01:02] And Amazon.com had done an experiment where a 100 milliseconds speed decrease resulted in a 1% sales loss for them. So it's really not just, I want the page to load faster. People leave, if you're selling stuff people don't buy it. How to sign up form, it doesn't look, people really do leave.
[00:01:20] But at this point in time, also, search engines have started punishing slower sites. So your search result place will be less. So it's basically, really, really important and it's not just perceived slowness. It's what people, what your potential customers will and will not tolerate. So yeah, really important stuff.
[00:01:41] Like I had said, when we were going over the kind of mile high view. I always like to start with just a page on it because you're not really diving too deep into technical details. You're kinda seeing what nice easy stuff you can fix and get away with.
[00:01:57] So for that, we are going to go into dev tools. And we are going to go to the Audits page. And so we've got a couple things here. These ones will be really fun to check out on big production sites. Cuz they've got a lot more going on in my little app.
[00:02:11] But basically, there's two different approaches it can take, I always like for both. It's network utilization and then, once the network resources are loaded, actual page performance. And you can do two different ways, you can either audit your already loaded site. So if you wanna see, my Ajax staff seems really slow.
[00:02:29] You do this way or the best place to start is to reload the page. So you're loading a fresh page, no cache and auditing the whole thing. So I'm just gonna go ahead and run that. So this is gonna control the reload. And then, it's gonna break them up into those two different web page performance and network utilization.
[00:02:47] And it's gonna give you a bunch of advice, which is just really handy. So this one, you'll see really often. Remove unused CSS rules and this is coming from the fact, I'm using a SS framework. So I'm using Bootstrap and Bootstrap just comes with one size fits. I mean, it does have the option to have a SAS version where you just add what you need.
[00:03:05] But, generally, if you're using a CSS framework, right? I don't have any tables but I have all the table CSS from Bootstrap. I don't have any, a lot of different elements like that. You can save a ton of speed over the wire if you delete staff that you're not using.
[00:03:19] But do keep in mind that this has no, if you're working on an app, not a web site. This doesn't have any way of knowing of what markup could be there, right? So you might have unused CSS rules. But there really CSS rules that are gonna be on your dialog box when it pops up or something like that.
[00:03:36] I mean, this is not something that you can really automate. You have to know it a little bit better but it is good to look at. There's a ton of CSS that I'm not using. Combining external JavaScript. We're gonna talk about this more later with HTTP/1 which is what almost everything is on right now.
[00:03:54] Requests are expensive, multiple requests are expensive. And browsers can only handle so many requests in parallel. So if you have 20 different JavaScript files. I think, Chrome does five at a time. So start the five and then as they come in, it's adding more and more. And that's why you see these bundlers.
[00:04:13] You get all your JavaScript minified, concatenated, all that kind of stuff this is why we're doing that. Gzip compression is really important and really easy. It's basically, it's a compression format that the browsers all know how to decompress. So you compress all your files and you send him over the wire.
[00:04:32] And all major browsers know how to turn that back into your HTML, CSS and JavaScript. So their only thing about implementation details is, a lot of these like Gzip compression depends on your web server. So it's different for Apache than it is for engine X or something like that.
[00:04:49] But there's tons documentations so if you go to your site, and you're seeing that you don't have Gzip compression. Whatever you're doing, node, engine X, how to Gzip, something like that. Using Apache same thing like Apache how to Gzip. If you're using a CMS, there's probably plug-ins for it.
[00:05:05] So this is really important and it kinda shows you in a nice way, how much could be saved. So I mean, really, look at this one, bootstrap.css 78 kilobytes. If I just enabled Gzip compression, these are really big, same with browser caching. So when you serve files down, you're able to specify with that file.
[00:05:24] How long the browser, you'd like it to keep that file cached for. And that can be a huge difference because things like jQuery or your libraries or whatever, you're not gonna change that often. So specifying browser cache can be really, really helpful. So for those that are familiar, Google has this site called PageSpeed Insights.
[00:05:45] Which has this exact kind of workflow but it, actually, has a lot more stuff. So the audit can start in Chrome dev tools, that's totally cool to do. But I would recommend checking out, let me get the link here. And I'll publish this, it's developers.google.com/speed/pagespeed/insights and put your URL in here.
[00:06:06] The great thing about the DevTools 1 is you can do it on your local sites, right? You can do it on something that you're working on. Whereas, this needs actually go over the Internet and have domain name that it hits. But again, you can put any site in there, google.com or whatever.
[00:06:20] And it'll run this whole thing. And it'll give you a bunch of different advice on stuff you should fix, stuff that's good, all that kind of stuff. It's not always possible to fix everything. That's a caveat that I'd like to add here. Sometimes, you just have stuff that you just need.
[00:06:35] There are certain libraries that you'll use, it's a JavaScript library. You have to put it in the head. For those that are familiar, JavaScript is recommended goes right before the closing body tag. But if you're using modernizr or anything that's web component, something like that, it has to go up there.
[00:06:53] So sometimes, your score is what it is. Sometimes, you just still gonna have, I could fix item in here. But it's a really good place to get started with finding low hanging fruit, seeing what you can fix.