Google Page Speed Demystified
Remember the early days of the internet?
Back when bandwidth was a total joke, and every browser took a few minutes to warm up.
It gives me goosebumps just thinking about it.
These days we have no time for slow sites. And nor does Google.
I want to open 10 different tabs at once and have them all working in less time than it takes a greasy penguin to slide down a hill.
And you guessed it, search engines have a similar opinion when it comes to website speed, so much so that most SEO experts consider it a core ranking factor.
And they try to help us, giving us nifty tools to help us measure and fix our site speed, well they’re kind of nifty, and also kind of impossible to understand!
But fear not, today I’m talking to Peter Macinkovic about how to understand Google’s web speed reports, and how to use them to turn your website turbo.
Tune in to learn:
- What site speed reports are
- Understanding and interpreting reports
- How Google measures the speed
- How site speed impacts your Google ranking
- Report Opportunities: what they mean and how to enact them
- Report Diagnostics: what they mean and how you can adjust your website.
- Tips for using Google Page Insights Tool
Listen to the podcast
Share the love
If you like what you’re hearing on The Recipe for SEO Success Show, support the show by taking a few seconds to leave a rating and/or comment on iTunes, SoundCloud, Spotify, or Stitcher. Thanks!
And big thanks to Briony1983 from the UK for their lovely review:
“This is such a handy podcast which is packed with tips and advice. Perfect for listening to on the daily commute.”
Share the meme
About Peter
After working in-house as a Digital Marketer for an online beauty retailer, Peter now works agency side as a specialist in all things technical – servicing clients such as JB Hi-Fi, T2 Tea, and Metricon.
Peter met his wife on the train by placing his business card next to her. Now together 10+ years.
Connect with Peter
Useful resources
- Google Page Speed Insights
- Cloudflare
- Cloudflare APO
- Cloudinary
- SiteBulb
- Kinsta
- WP Engine
- SEO Meetup Melbourne – Youtube
Transcript
Kate Toon:
Remember the early days of the internet back when bandwidth was a total joke, and every browser took a few minutes to warm up, it gives me goosebumps just thinking about it. These days, we have no time for slow sites. And nor does Google. I want to open 10 different tabs at once and have them all working in less time than it takes a greasy penguin to slide down a hill. And you guessed it, search engines have a similar opinion when it comes to website speed. So much so that most SEO experts consider it a core ranking factor, and they try to help us giving us nifty tools to help us measure and fix our site speed. Well, they’re kind of nifty, but also impossible to understand, but fear not. Today, I’m talking to Peter Macinkovic which I probably said wrong about how to understand Google web speed reports and how to use them to turn your website turbo. Hi, my name is Kate Toon. And I’m the head chef of The Recipe for SEO Success, an online teaching hub for all things search engine optimization, and digital marketing. And today I’m talking with Peter.
Peter Macinkovic:
Peter.
Kate Toon:
Peter, I should be able to pronounce. How do you pronounce your second name?
Peter Macinkovic:
It’sMacinkovic. So all the Cs are C-H, so it’s Macinkovic. It’s a Croatian surname. Hi Kate, how are you?
Kate Toon:
It’s very cool. It’s not as easy as Toon but I love it. I love that. Okay. Peter is a technical SEO strategist and E-commerce specialist who spends his time tinkering away on web platforms like Shopify. After working in-house as a digital marketer for an online beauty retailer, Peter is not only beautiful, but now works agency side as a specialist in all things technical, servicing clients such as JB Hi-Fi, T2T and Metricon. And fun facts I ask everyone for a silly fact, Peter met his wife on the train by placing his business card next to her. Now together for 10 years. That’s so cool and kind of creepy and awesome at the same time.
Peter Macinkovic:
I don’t think it’s creepy at all. I think it was a very strategic move. It worked, 100% success rate so.
Kate Toon:
Must be a pretty good business card. I bet it’s really heavy GSM, 300 GSM for-
Peter Macinkovic:
It was a nice one. A friend of mine designed it. And it was just nice. And my wife and I just stared at each other for like 45 minutes in the train. I just had to get up and I sneakily just placed it next to her. And we texted –
Kate Toon:
Oh, and really cool.
Peter Macinkovic:
And then we had a date.
Kate Toon:
I’m dating someone. But I still want to try that out. So if you’re listening to this, and you try out Peter’s technique, let us know, because I think that’s brilliant dating tip. I’d much rather talk about dating. But we’re going to talk instead about Google site speed reports. Now, there are a few different site speed reports. The thing I say about Google is that they do make all this information freely available to us. But they also make it freely incomprehensible, as well. So we’re going to talk about one specific speed test today. And that’s PageSpeed Insights. Tell us a little bit about that testing tool.
Peter Macinkovic:
Yeah, sure. So PageSpeed Insights is a tool that Google host, and they place on their website where you can input the URL, and they’ll give you a bunch of metrics that report on how good or how poorly your website’s doing in regards to speed. They use something called Lighthouse, which is a built in tool in Google Chrome to actually measure some of these elements that we’ll talk about later in this podcast, where they give you a score and a grade and how well you’re performing. They also have other things such as CrUX which is a Chrome User Experience Report, which is where people who have a Chrome browser actually send data back to Google. And they’ll give you what is called field data so that the lab data where Google is running the test on their server and give you a score. But they also have real users and give you a score based on what’s actually real users have.
Kate Toon:
That’s perfect. So CrUX, C-R-U-X, and that’s the Chrome UX Experience. That’s data gathered from real humans and field. That’s good. As I mentioned in the intro, speed, and I’m doing air fingers, is probably a core metric that influences ranking. I mean, I think we all see this. No one likes these 200 factors. And this is the most important one. No one likes to definitively say, but I think we’ve been pretty sick not to think that speed’s pretty important, right?
Peter Macinkovic:
Yeah, basically page experience in general is a factor. And speed is a really important part of someone’s experience when using a website. A fast website usually means a better experience in a slow website. So the way actually good speed impacts your rankings is in two ways. Traditionally, speed actually impacted most in regards to quality. So how many resources the Googlebot will consume while trying to find every page in the website. And the less resources Googlebot uses, the more efficiently you close your website. So that’s how it was historically, but as of May of next year 2021, Google are doing something called the page experience update where they’re going to use three metrics that they provided with their pages insights tool, that we actually will impact your website rankings as a ranking factor. It’s the first time that Google actually publicly announces speed definitively is a ranking factor as part of this page experience update. There’s other stuff like pop ups and stuff that’s part of this update but it’s actually a core part of this upcoming update. So yes, it is an upcoming thing and it’s a big focus of me so far in 2020.
Kate Toon:
Yeah. I mean, it’s always been an issue, I just think that Google’s getting slightly better at articulating how speed is measured, rather than just saying sites should be under three seconds. It’s breaking it down into what should load, how it should load, how you experience the site on a mobile versus the desktop. We’re going to go through some of those today. So let’s talk about how Google measures speed, and how bad the impacts of slow speed can really be. So what are some things to think about when we think about this?
Peter Macinkovic:
Yeah, sure. You had mentioned earlier, Google uses a tool called Lighthouse. And they have probably about six core metrics that they use when they’re measuring the speed of your website. Now, you have to bear in mind that when Google are measuring your speed, they’re actually emulating speed. They’re running it on a server, and they’re trying to emulate what a real user’s trying to do. So they emulate mobile devices on 360 by 640 display and desktops on a 1350 by 940, which is a random display, but it’s actually what they use for the PageSpeed Insights tool. They actually model the CPU for mobile testing. So they’re trying to simulate very, not powerful devices, they try to render the page, and the six metrics-
Kate Toon:
I’m going to stop you there. When you say throttle CPU for the complete news, what do you mean by throttle and what do you mean by CPU?
Peter Macinkovic:
CPU is a central processing unit of a computer. And so if you had a very cheap phone, you might notice it’s quite slow. That’s what Google is trying to emulate in a simulated environment. They’re basically trying to see what a fictional slow phone is loading your website in a mobile type browser. So they’re trying to see how low power device’s actually loading your website. And that’s when they actually did a testing with the PageSpeed Insights tool with the mobile metrics.
Kate Toon:
Yes, that’s pretty interesting. So they’ve got the Lighthouse tool, they’re emulating the user experience from whatever geolocation it might be. And then they’ve got different measurements for desktop and mobile, and they are the throttling thing. So you get to see almost the worst of the worst, rather than… Because, often when people say, “Well, hey, look at it on my super brand new, fabulous iPhone. It launches really, really quickly.” And you’re like, “Yeah, okay, but that’s not everyone else’s experience.” That’s good to know. We know that there are other site speed tools, GTmetrix, and Pingdom site speed, which seems to be a bit more generous. Google’s page insights tool is notoriously tough, especially for mobile. Why is that?
Peter Macinkovic:
It’s mainly actually, because of the simulated environment because they actually… They have a name for it. It’s part of… I’d have to call it Lantern, and I don’t even understand it well enough to explain it, and probably not for your audience as well. But the reason why it is notorious is that is because of this simulated CPU stuff and as well as funding for mobile devices. And it’s actually a trade-off, that Google actually trading off accuracy to actually get really fast execution speed in measuring the tool. So it is technically less… Because it’s using a simulated device, it’s actually less accurate. And at least the gaps between tested speed versus real life devices.
If you ever look at the PageSpeed Insights tools, you might notice sometimes there’s a big gap between what we refer to field data, which is a Chrome User Experience where all real people, real devices are using it, versus what they’re simulating. So it is a little bit controversial, because they’re very tough. And there’re very, very strict testing conditions that they simulate. And that’s why it can be really, really tough for mobile. It’s really difficult to apply, because Google is basically expecting of us to have really fast experiences for the least powerful devices out there.
Kate Toon:
Yeah. It’s interesting, it’s insightful. There’s good data you can get out of it. We’re going to go through that now. But I think it’s good to acknowledge that it is brutal, because I know that a lot of students on the course, they put their sights through it, and they’re like, “Oh, my god.” I’m like, “No, no, no, it’s not as bad as it looks, calm down. Let’s start with Pingdom and fix the basics like images and stuff and then we can come and look at some of these.” So you mentioned that in this new rollout in May 21, but also existing now that there’re going to be six core factors that Google’s going to look at. We’re going to go through these one by one today and explain them because they’ve given them the most silly names and they love an acronym Google. So the first one we’re going to talk about is First Contentful Paint, FCP. So explain to me what that means, Peter.
Peter Macinkovic:
So, First Contentful Paint, which again, is an awful name because contentful is a made-up word by Google. Something, anything, yeah. So it essentially marks the time for when the first piece of text or image appears on your site. The word paint in computer science means when something is actually rendered on screen. So when your browser is actually capable of rendering a pixel, essentially, so when you go from a website, you see a blank screen to when you actually see something, anything. That is basically what FCP, First Contentful Paint is and that’s about 15% of your score if you ever look at the scoring metrics.
Kate Toon:
Yeah. I’m going to put each of these in context for the listeners. A big problem with a lot of the sites that I look at is that first thing that they want to render is a gigantic image downloaded straight from the photographer, uploaded without a smush, or a dimension resize. So it’s something like 5000 by 5000 picture of a girl jumping in a puddle with some red wellies on takes up the whole page, has no copy over it. Isn’t even clickable, and also slowing your site down massively. So you really have to think about that first thing that you’re rendering, the nav, the first image and try and make it as small as possible, I guess.
Peter Macinkovic:
Yeah. Probably the easiest way to improve is actually just to improve your hosting. So the gap between the white space something, so if you have any shared hosting sponsors, or anything like that, if you have a really powerful host, like a Kinsta or WP Engine, for example, then that will really, really help you. Or if you have a service like CloudFlare, that’s able to cache your website, they can really, really close the gap or disperse contentful because they’re essentially closing the gap for when a user hits your address like the response and therefore at least the first thing to load. So that’s the fastest way to actually improve FCP is actually have a very powerful host or a very good caching and your website.
Kate Toon:
So just explain what caching or caching means. It’s a copy of your site that’s hosted a bit more locally, and it loads it quicker. So reducing the size of giant images on the homepage wouldn’t help with this?
Peter Macinkovic:
Not with FCP, because that actually relates to a different metric, which is LCP which we’ll talk about later, yes.
Kate Toon:
FCP, LCP, okay. Even I get them confused.
Peter Macinkovic:
Oh, yes.
Kate Toon:
And also, I don’t have any crappy shared hosting sponsors. If you are a crappy shared host, and would like to sponsor please get in touch. Okay, so we’ve talked about FCP. Now we’re going to talk about number two Speed Index, SI, bit of a better name. What does it do?
Peter Macinkovic:
So, Speed Index if you look at the documentation is actually very complicated. It’s literally, there’s papers and papers on it. But essentially, it’s how fast it takes for your web page to completely load visually. So the Google has a lot of complicated metrics they use in the… If you remember the old tool, Kate, where they had different metrics going, it’s actually a combination of the older metrics together, and there you get a combined score. So it’s basically how long it takes for the entire page to visually render. So while FCP is the first one, Speed Index is basically how long it takes for the entire page to render top to bottom. And that adds also 15% of your score. It used to be 25. But now it’s 15.
Kate Toon:
Okay, so tips on improving that. You’ve mentioned that-
Peter Macinkovic:
Because it’s the most complicated metric, it’s basically if you improve every other metric, it will improve this except for the JavaScript related ones. But if you improve your hosting, your images, your compression, the amount of assets to use, every single optimization will contribute to SI. Yeah, so the different thing about SI is that it’s not a one unit fixes it, it’s basically a combination of multiple metrics that end up with a weird score that literally you need a computer science degree to understand how to do it.
Kate Toon:
The cumulative result of all your other efforts will be rectified and improved at SI.
Peter Macinkovic:
Yeah. Some people can argue it should just SI as a score and that’s it. But-
Kate Toon:
It would be a lot easier, wouldn’t it? No, it wouldn’t, because I think breaking it down like this actually helps people understand what contributes. So this is the one that I got confused with first and last, so largest colourful paint, LCP-
Peter Macinkovic:
Contentful Paint, actually.
Kate Toon:
Contentful, why do I keep saying colourful?
Peter Macinkovic:
That’s fine. People have used the word cumulate, they use all sorts of different Cs with the-
Kate Toon:
Let’s just say LCP, okay-
Peter Macinkovic:
LCP, the big thing on your website. So basically, it’s the time it takes for the largest piece of text or image that the largest part of your website to load. So this is usually a banner image. So if you’re on JB Hi-Fi, they have a lot of stuff that hurts my PageSpeed score. So for JB Hi-Fi because they have these large banners saying, “Bang, Black Friday sale” or what have you, and that takes forever to load. Now the things that affect it is obviously A, how big it is, and B, how prominent is on the page. If you actually had it further away, it’s waiting for other things to load first and it’s loading it. So it’s from the start till when it’s fully loads.
So sometimes to optimise LCP, you have to actually load the biggest asset earlier if it’s really, really important. But you also have to make it really, really small. So it’s a balancing act. You have to make the largest piece of your website as small as possible and to load it as early as possible to actually improve this score. This is 25% of your scoring, it’s actually the highest one as it’s tied for the highest impact in your scoring.
Kate Toon:
Yeah, so that’s back to my little point about the welly boot picture. But often, removing that giant image or not having a slide with seven giant images can have a really big impact. That’s why I see some people just make a small change like that and it really massively improves their speed super quickly. Now the next one I love. So we’ve talked about the page, the elements loading, and the big element on the page. And the next one is TTI, Time to Interactive. That’s how long it takes till the page is actually usable to a degree. Is that right?
Peter Macinkovic:
Yeah, absolutely. This relates to how things are with JavaScript and how it loads. And anything that blocks important part of your JavaScript, like jQuery or whatever you have that actually relies on interactive parts of your website, if there’s things in a way that stop it from executing, and it takes like three seconds or four seconds before it actually begins loading, this is the part that would affect this particular score. And the easiest way to improve this is actually to get rid of stuff like external scripts, or to get rid of stuff that’s in the way in your JavaScript and just keep it simple. This is also 15% of score but fun fact this in the old scoring metrics, this was actually 33% of your score. And the fastest way to prove the website speed in your old metrics was actually to remove all the third party scripts.
Kate Toon:
Just to translate a little bit further, new JavaScript, I like to describe to my newbie students as anything that wiggles on your site, or anything that allows you to enter content into your site. CSS is another element that people talk a lot. That’s about making your site look nice, Cascading Style Sheets, if you don’t know what JavaScript is, wiggling, data entry, that kind of stuff, and also feed. So Peter talks about scripts, a classic thing that I see on a lot of sites is having some kind of Instagram feed. Now anything that has to go to another site to get contents upon your site is going to take time. Again, I’ve seen big improvements by just getting rid of that Instagram feed, and we get that thing that wiggles and adds nothing to the user experience. It’s just a wiggly thing that’s annoying to be honest. Okay, well, next number five. We’re up to number five already, which is fantastic, is TBT, Total Blocking Time. Take us through this one.
Peter Macinkovic:
My least favourite metric. So this is the time where it takes between the FCP, so when the first pixel loads, and the time in interactive, so it’s basically that time of how much time does it take for things to block your scripts from executing? And there’s some documentation that’s like, blah, blah, 50 milliseconds. By the way, this is why these metrics when people read them get all confused, because it’s just like that. One important thing I know from an SEO standpoint is that in Google Search Console, they don’t actually call this TBT. They call it First Input Delay, which is FID when you look at Search Console.
So if you get confused and say, what’s this FID metric, it’s actually the equivalent in PageSpeed Insights is TBT, at least according to Google. So it’s how long it takes for someone to interact with your website as well. To more accurately say before, like four times the interactive, that actually is probably the total load for all the interactive elements whereas this is more the first interaction on the website. Actually, first interaction would have been a better name for this metric, to be honest with you.
Kate Toon:
I mean, if you’re still with us, well done. This is complicated stuff. And there’s a lot of definitions going on here as well. So we’re going to go through one more elements to talk about, and then we’re going to go through some fixes as well. And some of the things that Google explains in that but this is a complicated episode. So well done for sticking with us. Number six, is Cumulative Layout Shift. I think this is a really interesting one. So take us through this one, Peter.
Peter Macinkovic:
This is interesting, because this is one of the newest ones as the one that developers hate, as SEO should tell people to fix this element the most, because it’s really, really tricky to fix. So it’s the amount of visible movement that happens with elements on your page. So if you ever been to a page, and then you load the page, but then it takes a while for the products to come in, and all of a sudden things just go janky and they shift around, and to go all over the place, that’s why it’s measuring. It’s measuring what we call client side rendering, what uses stuff like JavaScript to render something after it initially loads. And that has an impact. It’s very small impact in the scoring about 5%. That’s a really, really tricky thing to fix.
It’s also a very strange way to score it because they measure it both on the amount of shift and the impact. It’s supposed to be a percentage, but doesn’t actually quite work out that way because it’s a combined score. So instead of being from zero to one, or 100, it’s actually a two. So the score is a bit off, but you want to keep this under 0.25. Essentially, the best way to do this is to make sure you don’t rely on JavaScript to render the layout of your page dynamically. And just try to make it like as soon as your page loads, that’s the layout. That’s it. This is your grid. This is your menu. This is it. This is how it is.
Kate Toon:
I think from a complete newbie point of view, to explain all of these in a simple way, it’s like you know when you go to the site, and there’s big white for bits, and then bits appear, but then a couple of seconds later, they move up and down the page. It’s just not an instant experience. The idea is that what Google’s trying to get is that when you hit the site, everything you need to be there is pretty much there from the get go. And yeah, it can be some things are loading in the background, because you’re not looking at those yet. But the first impression is good, that user experience is good. But as well as all these percentages and definitions, it also gives us some opportunities, thanks, Google, and suggestions on how to make our page load faster.
But again, some of those are a little bit difficult for your average humans to understand. So we’ve got some definitions that we’re going to go through here. The first one that we talk about a lot is eliminate render blocking resources. So Peter’s already explaining that render basically means how quickly does the site load onto the page or what’s stopping it from appearing on the page? But how can we eliminate render blocking resources, Peter?
Peter Macinkovic:
A render blocking resource is any file, whether it be an image, a script, your style sheets, anything like that, that’s stopping the page from actually looking the way it’s supposed to. So this could be like a giant file, a giant JavaScript file, and as critical logjam because essentially have a big file that’s getting away a bunch of little files, and the little files actually should be in front of the queue. So the way to optimise it is that anything that’s a big asset that’s getting in the way of other files, is to actually make that file load later on in the page. So you’re actually shifting the order of what assets get loaded in your page.
So if you have a really important image, that should get loaded higher up, if you have a piece of JavaScript that’s only using your checkout, that actually should not be loaded until the whole page is loaded. So you can do some stuff where you can defer a script and give it a little special class and that will actually improve this render blocking resources metric. You can also use HDP-2 but Google doesn’t score it this way but it can load assets at the same time. But the main way to do it is that basically reorder what gets loaded and when to make sure that only the most important things on your website get loaded first.
Kate Toon:
Yeah, and obviously, this is not something that your average business owner is going to be able to do this, this is something you would be speaking to a developer about. You don’t want to go fiddling around with that. So if you’re a developer, it’s something you might need to learn. The next thing that we cover is preload key requests. Take us through what this means, Peter.
Peter Macinkovic:
So whenever Google looks in your website, and they start to look at an asset, they’ll start fetching it, downloading it, and then they’ll add it to your page. Now, what you can do is that if you know you have a very important asset in your website, so for example, your header image, a main header image, you can actually put that in the head of your document and say, “Here’s the header image, load that ahead of time.” This jumps the queue. And you can preload that asset so that the actual, most important parts of your website get loaded ahead of time. So it’s another thing to jump load the queue.
And it can get very, very complicated. And if you abuse it, this could actually have a negative impact because you might load something that becomes render blocking. So you might load something, it’s giant, and all of a sudden, that’s jumped the queue. And your diversity assets in your website are loading. I usually stick to one to three assets whether they’re images, scripts, or stylings to preload on the page to make sure that the actual visual appearance of page loads as quickly as possible. This is one of the very, very delicate mechanism to use.
Kate Toon:
Yeah, I mean, one of the things I do like about Pingdom is it does have that cascade of what’s loading so you can often see the chunky thing like one of the things we talked about was getting a better host. So you can see that gap between connection to the host as well, which is nice. And then you can see what’s loading when, and often it will be some stupid plugin and it’s a WordPress site that doesn’t do anything. And you’re like, “This is the logjam that you’re talking about.” That’s little cascade. Now, the next one is a bit more clear and easy to understand. Well, next two. Remove unused JavaScript and remove unused CSS. I just looked at JavaScript and CSS. And we know that they can impact performance massively. How do we know which ones to remove? And how do we know what’s not being used?
Peter Macinkovic:
If you have a tool like Sitebulb, Sitebulb is one of my favourite tools that crawls your website and gives you some scoring. There’s some options during the core where you can actually look for stuff where you have unused JavaScript and unused CSS. And they can actually tell you which files that you can remove. So with that kind of software, once you run it, you can just say, “Okay, well, I’m using this plugin that’s using jQuery 1.2,” or something like that, “which is really old, and it’s loading on every single page of my website. I need to remove that plugin, I need to remove that script.” It basically gives you a clean-up list, because there might be a lot of parts of your website where you’re not actually using JavaScript.
It also gets even more complicated where you might be using JavaScript on certain pages, I gave the example of a checkout, if the scripts only use the checkout, it should only be in the checkout section. You’d rather not have that on every single page, because this gets… You’re adding more assets in the line and the logjam gets longer and longer. So whatever you need, just need and then you use your tools available. That’s one example, Sitebulb but there’s others out there that can help you identify these opportunities, and have a really, really powerful impact site wide.
Kate Toon:
Yeah, I shall include a link to Sitebulb in the show notes for this episode. It’s a great little tool. Okay, now this is the one that confuses people, next-gen format, so using next-gen formats for images. There’s some issues around this because next-gen formats aren’t actually completely cross browser compatible. Am I right? So what does next-gen formats mean and how-
Peter Macinkovic:
So typically, formats that we expect for images are stuff like .JPEG, .PNG, that’s the kind of images that we know. There’s a format called web page that’s available on most Chrome-based browsers called Chromium-based. And that’s actually available on 87% of all browsers. It actually has quite a high level of coverage. And that could save over 90% of the same image with virtually zero quality loss. But again, support that you mentioned, Kate, that if a browser doesn’t support it, then it’s not going to work. I actually recommend a service for this. There’s a service called Cloudinary, where you can actually take an image and you can use your existing platform, use whatever platform you want, and just pass it through Cloudinary so you basically add stuff before the image URL, like res.cloudinary.somethingsomething and then your something.JPEG.
And what that does is that it will actually serve it in the perfect format for whatever that user browser is using, and it will be perfect quality as well. And that is really useful because you don’t even have to think about it. It’s very, very simple. And it’s so flexible that I can use this on any client, any platform within a commerce cloud, Shopify, WordPress, whatever. WordPress, we actually have a lot of things to do on-site, but whatever the platform, the limitation, I can just use a third party service to do this for me, which is fantastic. It saves so much time. The support is like 87% pretty good. It’s a lot better than it was five years ago. And yeah, I would say it’s a next-gen format but web page has actually been around for 20 years, it just hasn’t been supported until very recently.
Kate Toon:
Yeah, it’s not that new, it’s just people have gotten into it these days. And then in relation to images, the next one is properly size images. So this is quite straightforward in terms of making sure that the HTML code around your images, you actually set the size there as well. Now, the thing that we’re not going to be able to cover today, when we are having another episode around this topic is how the hell do you do some of these things on sites like WordPress? This is a big long episode, but we’ll get to that. So the properly sized images, it’s about making sure that it looks the right size, but it’s quite difficult to do on different devices, isn’t it?
Peter Macinkovic:
Yeah, because essentially, what’s native in the HTML, when people invented HTML way back in the 90s, they said, “Okay, if your image was like 360 pixels wide, you can just say it has a width of 360 pixels.” But when they invented HTML, they didn’t think of that day where we have multiple devices, screens, we can change the layout of our browsers and that sort of thing. So if you set something as a width of 360 pixels, but then all of a sudden, you’re stretching or shrinking the page, it actually might be suboptimal. This is one of the vices where I can tell people that this is probably low priority, because if you have… There’s better techniques to do image optimization. And just because Google’s recommending it, this is one piece of advice you don’t have to follow if you have better techniques. You can use stuff like source set and all these sophisticated ways to load images, where you can specifically target the devices without setting the sizes directly in HTML.
Kate Toon:
Okay, great. So the final one, I’m going to do myself, because it’s minify CSS, which is all about compressing the CSS files and removing duplication in code. There’s a few plugins that you can get, especially if you’re using WordPress that will do that for you. Because I want to jump into the next bit, which is the diagnostics. We still got a way to go people. The diagnostics section is super overwhelming for most people. So let’s just run through some of the points there. The first one we have is reduce impacts of third party code. We’ve covered that, but let’s go through it again.
Peter Macinkovic:
Third party codes, such as a YouTube or Google Analytics, those kind of things do impact your score and impact the TTI and TBT, that we mentioned earlier, which is everything that leads to the way JavaScript interacts and by removing unused code, or deferring it, so it loads later, this will have a big impact on your score. I’ll give you an example. If you have a blank web page, nothing on it. It has a perfect speed score, because there’s nothing, you embed a YouTube video using the native YouTube embed, all of a sudden your score is 75.
So if you have a YouTube embed anywhere on your website, natively within the YouTube embed code, it’s impossible that you get 100% score on the way Google measures site speed. So that’s the amount of impact just because it has some third party scripts, so you need to avoid using these external scripts as much as possible, or you have to source ways to do a lightweight version of them. So there’s a lightweight YouTube embed, for example, done by Paul Irish, who’s one of the developers at Google actually. It basically has an image and a play button. And when you load it, then it loads YouTube. So all of a sudden, you can fix that 25 score hit that you get from that, despite using YouTube on your website. So look for anything that use third party, embeds scripts, tracking, all those sorts of things and get rid of anything that you’re not using. And anything you are using, try to find a very quick way to use them.
Kate Toon:
It’s a great tip. It’s something that I’m… Because I’ve got a lot of YouTube videos on Vimeo as well, Vimeo is terrible for site speed and so as you said, just making your own little fake thumbnail that looks like the YouTube front end, putting a little triangle on it, and click on it and then loading the video, then it’s a great little tip. The next one you’ve got is minimise main thread work-
Peter Macinkovic:
Yeah, this is super complicated. I’ll basically say that if you have multiple JavaScript files, multiple libraries that you have jQuery, you have this library of that library. Essentially, you’re creating a chain of dependencies on each other. So if one has to rely on another to work and you have to wait for… Yeah, basically it’s like a line of people lining up and say, “I need this from Tom.” Tom comes to me, he gives it to Phil. And then all of a sudden, it becomes a very complicated dependency network. And it just makes the execution really, really slow on the website. It’s the same recommendation as the above. Essentially, it’s you remove anything that you’re not using, you optimise script code. So if you have a good developer, they can rewrite code to be like, 10 times more efficient if they’re quite capable, and anything that’s third party. You only have to use what you need to use.
This is also related to another point that we have down the line which is reduced JavaScript execution time, just basically make… You have to make it as efficient as possible. So you’re only executing what you need to execute and you’re not having your main browser handle so much scripting and fiddly things on the website. Also, it will be overthinking and we always use a website that’s kind of struggling to filter or something like that. You’re trying to find cosmetic products and you try to filter, it just takes forever, it’s not great. It’s not a great experience.
Kate Toon:
Okay, that makes sense. The next one that comes up a lot is serve static assets. What does that mean and how can we do that?
Peter Macinkovic:
Yeah, sure. So every single time an asset, like an image is being accessed by the browser, you actually have these little things in what is called the header, it’s like the front of an envelope. Before you access the image, there’s a little envelope that says, “This is an image. Please keep this in your browser caching for three days,” or something like that. So if you can have access to cache controlling, there might be some plugins for WordPress. But there’s also other things that you can do within other platforms, the server side as well. If you have a static asset A, make sure the image URLs remain consistent. So no query strings, no changes every single time it renders that sort of thing.
And also make sure that it has a cache control header that sets for a really long time, like literally one year. This is the images that are always stable, you’re not updating all the time, if you’re updating all the time, your domains will take a while for it to update for users. But if you have something that’s always the same, it’s the same little arrow that you have on your website, or whatever it is, just simply cache control. Make sure that you’re telling browsers that, “This is my image, it’s the same image. Don’t worry about it. Keep it as long as possible.”
Kate Toon:
Okay, that makes sense. We’ve got some avoiding ones now. We’ve got avoid excessive DOM size.
Peter Macinkovic:
Yep. What’s a DOM? A DOM is the Document Object Model, it’s a very fancy way of saying the actual page, the HTML of your website, the whole document tree. It’s basically use clean markup as possible, if you ever looked at these… Have you ever looked at the source code of a website and just seen a huge jumbled mess where you have a divs, wrapping divs, wrapping around other things? So you basically have to try to make this as efficient as possible. Google recommend a maximum of like 1500 children or nodes, as they call them, it’s very hard to do that. But if you have anything like a list of products, that kind of thing in your website, you just have to make sure that it’s quite clean. And you don’t have too many things nested within each other. You have to basically use as clean HTML as possible, which is up to your front end developer to do hopefully.
Kate Toon:
Yeah. I think we’re going to come on to how to fix some of these in a second. But a lot of especially on WordPress, for example, and Shopify, the more plugins and the more apps you keep adding that don’t do a whole lot, and that sometimes it might be easier for a developer to just write a bit of code to make the thing do. I often see people having like, “Oh, I got an app that makes a little bit of copy wiggly at the top of my page.” And it’s like, “Really, you could just code that hard code into the page. You don’t need another plugin with another CSS file, another JavaScript file.” Less is more, right? We just saw it should all have white websites with black copy and no images. That’s where we’re going. I’m joking. Okay. Let’s get into the final bits now, avoiding chaining critical requests.
Peter Macinkovic:
This is basically keeping your dependencies as low as possible. So if you need to rely on jQuery to load before you load something else in bootstrap, for example, bootstrap’s like a… It’s a framework library, very popular one. Most of your themes, WordPress themes are probably built on it. You want to keep it as low as possible, so that you’re not having one thing passed to another. So similar to what we’re optimising before, and you can also inline JavaScript, add it for critical execution on page level. So that means in the raw HTML, you can just have a script tag and then have really important JavaScript phone is one little thing, you can do that instead, which would be… There’s no dependencies for that. So it’s way faster than having multiple files calling each other and all being in a floaty, little wiggly sea of dependencies.
Kate Toon:
Yeah. I love a floaty, wiggly sea. The next step is straight forward, we’ve talked about these already, Largest Contentful Paint element. So removing or reducing the size of the biggest element. We’ve talked about that, avoiding large layout shifts. So we’ve talked about that, making sure that your site renders cleanly. And then one step, this final one we have here is avoid main thread tasks.
Peter Macinkovic:
Yes, so don’t use any non-critical JavaScript with using web workers to run in your browser’s main thread. So your browser might have a main thread to do some stuff. And it will need it to load various interactions in your website, all these critical stuff. And whenever you use a theme or a browser, they’ll have a whole bunch by default. So you basically have to keep as many things that you’re not using, because they include a lot of things by default reduced out of there. Developers have tools that do this automatically and hopefully your platform does it as well with compression with the…
Essentially, anything that’s not used in your main JavaScript thread, that’s one of the critical things that impact how long it takes to execute on the page, which is really, really annoying. That is platform limitations, of course and it’s also dependent on human ability to how good they are to developing your website. But as long as you keep… It is all very quite simple. It’s basically, only use what you need to use when it comes to interaction, or else your scores will go out of control and you won’t be able to maintain it.
Kate Toon:
Yeah. Well, let’s get to that final bit. Because people listening to this, if you’ve managed to get through all this techie stuff, or you are a developer, some people are going to be listening going, “Well, hey, look, I’m on Shopify, or Squarespace, I can’t do half of these things. I can’t be lazy loading content, or eliminating render blocking JavaScript, because I can’t even get into the back end to fiddle with that.” What are the few tips for Shopify people, let’s start with those guys?
Peter Macinkovic:
Well, Shopify, well, first tip, it’s probably used as a clean theme as possible, but actually CloudFlare announced Shopify support earlier this year in March of 2020 and it wasn’t actually possible before. Now, I probably should explain what CloudFlare is to some people. CloudFlare is something that sits between the browser and your website, as an in between. It’s like a man in the middle. They can do things like cache your website for the page. So essentially, all this stuff that we want to have, they’re getting in the way. Their unoptimized CloudFlare could just sit on top, and you just have to click a couple of configurations, toggle a few switches, and it does stuff for you. It can compress your JavaScript for you, can compress your CSS for you, it can reorder the JavaScript on your page and the further stuff that’s not being used. It’s quite smart.
It also has some of these metrics built in to the analytics. So you can use CloudFlare, it’s a bit of a… You can’t do self-serve, you have to contact CloudFlare to do it for you in Shopify, but it is physically possible to have CloudFlare on it, and just use lightweight things. Now, if you’re using that kind of service, we don’t have access to the server like a Shopify or Squarespace. Using something like CloudFlare on top of it can really help your performance and you don’t have to actually be technically adept to use it. Because, I mean, you might break some things when you fiddle the wrong switch. But if you know what you’re doing, you can save significantly amount in the performance by using something like CloudFlare on top of it.
Kate Toon:
Yeah. And of course, the obvious stuff like not going crazy with apps and making sure you’ve optimised your images as much as possible. So for WordPress people, we have a bit more control on WordPress. We can manage image smushing, we can do some caching, lazy loading. What else can we do? And obviously, we can move hosts which is a good one. What else can we do to work on some of these elements?
Peter Macinkovic:
Actually, I’ll put you back on the hosting one. Moving host is probably one of the fastest, best way to actually improve. Internally, we use Kinsta. That’s our preferred platform, but other people like WP Engine, and they’re probably the two or there’s probably a whole bunch of them, but their high performance WordPress hosting providers, I don’t know if you have a preference-
Kate Toon:
No giving them free advertising, Peter.
Peter Macinkovic:
You can contact them and say, “Peter said you’re great. How about you pay Kate Toon money?”
Kate Toon:
If you’re listening, give me a call.
Peter Macinkovic:
Yeah. That’s really well. And they also have some tool as well for caching and all those great things. Once you can implement will be stuff like implementing critical CSS. There might be some plugins but I’m not quite sure with WordPress, but essentially, having the CSS that renders on the page that you only need, the most important CSS on the page is rendered right at the very top of your head of your website. And what that does is that it actually really helps with the FCP, the First Contentful Paint because it basically renders all your stylings first thing before anything else before even the SEO stuff and it really, really helps. There’s also CloudFlare APO, Automatic Platform Optimization, which CloudFlare recently released. I’ve never used it myself, but I’ve had friends who’ve used it. Apparently, it just does it automatically for you. And CloudFlare just made WordPress very, very quick, literally all green scores on Google PageSpeed Insights. So you could try that out essentially CloudFlare, optimised WordPress, and they have a pre-built configuration to just do it for you, which is something I’m really, really curious to try out with some of our clients.
Kate Toon:
Fantastic, Peter, you’re a superstar. I’m so impressed how you managed to break all that down. If you’re still with us, then I congratulate you. This is a big complex episode. We are going to touch on this a little bit more in our next episodes with Alan Bleiweiss. I’m probably saying his name wrong as well. Gosh, I’m terrible. Now, if we want to follow you on Twitter, because you’re an avid Twitter user, as far as I can see, and I just want to… Can you let everybody know what your Twitter link is please-
Peter Macinkovic:
Yeah, sure. It’s @inkovic which is I-N-K-O-V-I-C. I have a very unique name. So if you see my name in the show notes, just Google it, you’ll probably find me. I’m actually very active on LinkedIn as well.
Kate Toon:
Okay, great. I’ll include links to all your different social media platforms. Also, Peter is part of the Melbourne SEO community. That’s where we met. And that’s a great community, which hopefully, 2021 will kick off their meetups which are smashing, and there’s different speakers each month and people should head along to that for sure. Yeah, Peter?
Peter Macinkovic:
Oh yeah. We’ve actually been doing it on YouTube every single month during lockdown. So if you want to hear me talk about Shopify or website migrations, I had two of them during the pandemic, it’s all on YouTube. So just search for the SEO Melbourne meetup. And you’ll probably find the YouTube page. If you’re in Melbourne, go to meetup.com, find the SEO Meetup page and just join and then when we’re finally allowed to be humans again and gather around in places, it’s a very welcoming community. It’s a very, very great, very consistent, it’s been around since 2011. There’s basically people who’ve been there forever. We’re very welcoming to new people. But 50% of the people who show up to meetups are first time visitors.
Kate Toon:
Yes. And you were fairly welcoming to me. Not very welcoming, but fairly welcoming.
Peter Macinkovic:
You’re fantastic.
Kate Toon:
I’ll include some links to the meetup in the YouTube channel in the show notes. Thank you very much, Peter. Now it’s the outro for the show, where you just have to sit awkwardly and listen to me finish up. That’s the end of this week’s show. If you have questions about understanding Google’s web speed report, head to my I Love SEO group on Facebook. I’m sure Peter wouldn’t mind your tweets on Twitter or LinkedIn as well, you can contact him there. Now I’d like to end the show with a shout out to one of my lovely listeners. And this week it’s Briony1983 from the UK and she says this is such a handy podcast which is packed with tips and advice. Perfect for listening to on the daily commute. So thank you, Briony, and thanks to you for listening.
If you like the show, please don’t forget to leave a five star rating or review on iTunes, Stitcher, Spotify, or wherever you heard the show. Your review will help others find us and learn more about the lovely world of search engine optimization. Don’t forget to check out the show notes for this episode at therecipeforseosuccess.com where you can learn more about understanding Google’s web speed report, check out the useful links and leave a comment. Finally, if you haven’t checked out already go and listen to the Kate Toon Show. This is my personal podcast about living life as a misfit entrepreneur, my tips and advice on how to be a happier more successful business owner. Tune in on your favourite podcast app. So thank you again, Peter.
Peter Macinkovic:
No worries, Kate. Happy to be here. It’s good-
Kate Toon:
And until next time, happy SEO-ing.
