Modified Transcript
Hello everyone, and welcome to another Weekly Wisdom. I am Ross Tavendale of Type A Media. Recently, Google added a bunch of page speed insights into Webmaster tools, or should I say Search Console (that is one for the original Gs out there). So, today I want to show you how to use your Chrome browser to run a Lighthouse audit, but also dig into a bunch of things you can do in the site’s code itself to speed things up. This isn’t going to be super techie, but it is kind of intermediate. So strap in and let’s get into it.
Site Code Examination
First and foremost, this is our website here. Let’s have a look at our case studies page because there are lots of images on it. To get a true understanding of a new person coming to the site, I am going to clear the cache. The cache is essentially all the memory stored in the browser; I want to delete that, so when I click Command + R to reload, you see that that image didn’t load as fast as it did the first time.
So, let’s dig into that and see what is actually going on there. I am going to hit F12 in order to get into the console itself. When you open it up, you SEO guys will be very familiar with doing control/Cmd + F to find and determine if there are canonicals on the page, are they broken, or why is it not ranking. Is it because there is a noindex tag on there or something like that?
Evaluating Site Speed
We are all very used to looking at the site’s code itself, but when it comes to the order of things loading, and things like the first contentful paint, where do we find that information? Okay, well, let me show you. Let’s jump into “Network”, and what I am going to do is I am going to reload this guy again.
Whoa, there is a lot, a bunch of stuff. Great. So, what we see here is something called the waterfall. When you have got all those resources on a page, from the browser’s point of view, it is downloading them one after the other, after the other, after the other. When we are doing speed optimizations, there is something called the critical rendering path. The critical rendering path, of all the things that are in this waterfall, is there any big, massive resources at the front that are stopping everything else from loading?
Now, if you use things like HTTP2, that becomes less of an issue, because it is like a multi-lane multi-threaded thing, where you can download lots of resources at once. And with HTTP3, something I am going to confess, I don’t know a lot about, that is going to be even faster, but let’s look at this website.
So, what are the big things that kind of jump out to us? What I want to do is quickly click on time and get all the things that are really heavy in terms of loading at the very top. Now I can see what things are blocking the site from moving quickly. These are things like SVGs and JPEGs and a bunch of random scripts; there are even some scripts that are not firing. We will get into that in a second.
Image Optimization
This is all very well and good, but what if I want to dig into the individual bits and check them out? Well, you see this menu bar up here, let’s click on IMG.
Here are all the images that are loading on the page. In fact, one of them is a 304. I don’t know how that happened. Here is what is really interesting to me. So, we can see right at the top here we’ve got all these logos, but on top of that, we have also got just random big ass images. So city-of-london.jpg, which is this background image you can see here, and cmc-markets-logo.png, are two separate files that look like one image.
And not only that, if we move the mouse cursor over it, it is all moving and animated, but it is a really lame animation. You can barely tell that it is happening. That is JavaScript.
We have got two images for every single one of them, so we have doubled the page size, and then we put some nonsense JavaScript on there to make it a little animation; it doesn’t really add any value.
So, here is the first thing we are going to do — kill these images with fire. We are going to turn them into a single image and load them up like that, and we are going to squash them down because this is way, way too big. A lot of images are only a hundred bytes. These are too big, so I need to squash them down.
Lighthouse Audit (4:33)
When it comes to running speed audits, there is something called Lighthouse, which is built into Chrome. Let’s run an audit and see some of the backwards and forwards of it. What it is doing when it’s running this audit is it’s taking me offline, trying to load the page through 3G and 4G networks; it is loading it through a bunch of different device types in order to give me this score.
There is a bunch of things straight out of the gate that we need to have a look at and understand what it means. The big thing for me is first contentful paint. It means the amount of time that it is taking to physically load this page, so it says it is just slightly less than two seconds.
The other thing we want to look at is time to interactive. When I was talking about the waterfall, you could have noticed in the bottom that there were 50 requests, and only half of them have been fulfilled.
That is time to interactive. So, that is everything that is physically loaded, and the page can be interactive, and I can actually use it. So, although it looks like it is ready to rock, actually there is a bunch of stuff in the background that is still going, so that is something we really need to have a think about and take care of.
Now, you might be seeing all these things and be like, “Ross, how do I even begin to understand what all of these different things are? First Contentful Paint, Time to Interactive, First CPU Idle… God, it’s painful.” Well, top tip, press the burger menu, and it is literally going to expand it, and it is going to give you the exact definition of what is going on:
And see these little “Learn more” things? It is going to take you to Google documentation, which is going to show you all the exact things you need to do to fix it.
Code Analysis
So, as we are going through this, it is a very good idea to understand what “Opportunities” and “Diagnostics” mean. First and foremost, to understand that, you need to understand what your code is doing. I am going to take you back to the waterfall and show how you can see the code that isn’t actually firing on the site.
You go into “More Tools”, and then you go to the “Coverage” report. Here is the interesting bit. Things in red are code that is not used. It is being fired, and it is blocking things on the site, but it is not being used. The green bit is code that is being used.
So, what do we do, and how do we actually make any changes? If you click on it, what it is going to do is actually going to load up the exact code that it is having to bother with.
Now, you see this, these numbered lines, it is just the lines of code in the document. The green bit means it is being used. The red bit means it is not being used. It is all JavaScript, of course, it is, because JavaScript is very expensive to render, and it takes a bunch of time.
I want to be looking at that, and I am thinking, “Oh, can I maybe concatenate any of these JavaScript files into one file? Can I chop out some of the stuff?” So if I have got a JavaScript file and only half of it is being used on most pages, do I need the other half, because that could really cut down the amount of time it takes to load. So, jumping into this and understanding the code that is used and the code that is not used, really essential for you to do optimizations.
Now, how do you get this to your developer?
Well, I would literally just be taking a screen recording as I am doing right now and get it over to them. Or guess what? Oh, a lovely little export button, so you can actually export your coverage report, take it out, and then get it in a deck or get it in a business case and show your developer, “Hey dude, there is a bunch of code on the site that is loading, but it is never actually used, and it is killing our speed.”
Wrap-up
Okay, so that was your very short introduction to how to use inspect element inside of Chrome to work out where to find speed optimizations. We have covered Lighthouse, we have covered redundant code, and we have covered the waterfall, to understand the critical rendering path. So, what I encourage you to do is go and try this on your own site and start playing around with it. And, stop using those tools that give you a speed score, because ultimately if your site loads in under two seconds, you are doing a great job. Digging into this, you can maybe shave off a millisecond here or there, which is going to make the experience for your user much, much better.
So that is everything for this week’s Weekly Wisdom. We hope you have enjoyed it. Please leave a comment down below if you are having any speed issues, and we can audit them for you live, perhaps in an upcoming webinar, but until next time, we will see you later.