How Important Is Optimizing Page Speed For Ranking?
Web page load speed is a Google ranking factor, but is it as important as other factors? Here’s what you need to consider.
Video Transcript:
David: Okay, well, so Onawa, you had asked me a question about page speed. Do you want to elaborate on that?
Onawa: Sure. How important is, in general, page speed and optimizing page speed? I mean, I understand images and all of that, but beyond that, and specifically the Google page speed itself, but also like speed in general.
David: Okay, great. So, first of all, it’s important to remember there are 200-300 ranking factors, and speed is one of them. But we don’t know to what degree speed is, the first most important issue, or the 200th, or where in between. But one thing we do know about speed as a metric is it’s not really about speed. When Google or people talk about page speed as a ranking factor, they’re using a shorthand for what Google calls the three core web vitals. Okay, those three core web vitals, let me just put it this way, Google doesn’t sit there with a stopwatch and check how long it takes a page to load because that function is dependent upon the Internet connector, the browser, the computer that you’re using, or the phone, if you’re on 3G, or 5G, Wi-Fi, GigaFiber… So, the bot that is going into these websites to evaluate for ranking factors, well, that’s pretty lightweight, and it’s going through pretty fast servers because it’s not really going to load the page on a 3G network. So, Google said while they want pages to load fast, they’re not measuring them by time. They’re measuring them by these three core web vitals. I should say by fixing these three core web vitals that, you will consequently have a faster website. I just said it wrong there for a moment because Google doesn’t rank websites. Google ranks web pages. And that’s important to remember, too, because this is a factor on a page-by-page basis. So, you can’t just optimize your homepage for speed and think you’re done. We really have to worry about all your pages. But it’s these three core web vitals that matter because that’s how Google can objectively measure speed without using a stopwatch and without considering that some people are on 3G on a mobile phone and some people are on GigaFiber on a desktop system with the latest processor and a ton of RAM and not using Chrome.
Onawa: If you’ve got those other things, you can still be in it.
David: Yeah, exactly. So, focus on the three core web vitals. In fact, as of January, they’re replacing one of the core web vitals with a different core web vital. But the best place to get the definitive resource on this is web.dev/vitals. So that will explain the three, including the one that’s being replaced and what has to be done on each page of the website to ensure you can pass the core web vital test. What does pass mean? Well, each one of these three core web vital metrics has a different metric, and they’ve divided these into three categories: red, yellow, and green. Green means if you achieve a green score on each of the core web vitals, you will actually get a ranking boost. To what extent? We don’t really know. But the green gives you an advantage of some sort. Yellow means you are no advantage, not terrible, but it could be better. Red means a lot of room for improvement, maybe a little disadvantage. So how do we know what the core web vitals are? Well, we can go in with every single page of our website. Number one, we can use the PageSpeed Insights tool from Google, which, again, page speed is a little misleading, and we can look for the scores for the three core web vitals. Two, we can open up our Chrome browser, and you can use Chrome developer tools, which will tell you the score for each of the core web vitals. So that’s how you do it without a developer site where it’s hidden. Three, if the site is live, your search console will give you the core web vitals for all your pages, each page individually. And it does something really nice. It actually says, okay, these pages seem to be built on this same template. And it assumes that if you improve a template, you will improve all those pages, which is probably true. Sometimes, you can have an extraordinarily large image on a page, and that might be a poor-performing page on an otherwise good template. Image, as it relates to page speed, does affect page speed because if you got a 10MB image, it’s going to download all that. And then the other thing with images is one of the three core web vitals is called Content Layout Shift, CLS. What that is, it’s honestly not even a page speed thing. It’s something where when you load a page, Google does not want to see it shift immediately on loading. And what you have to do is you have to tell Google before the image loads what the size of the container that has the image will be. So that’s why we go into websites, and we’ll optimize images and say, okay, this container is 816 pixels wide. We’re going to shrink the image down to 816 pixels. That way, the Content Layout Shift doesn’t happen as long as the template is coded to say this container is 816 pixels wide and tall, whatever that aspect ratio is. Now, I say all that to say, remember, Google is mobile first in its index at this point. So, it’s evaluating the mobile versions of our pages to decide whether it wants to rank the page. So, when it comes to speed and core web vitals, we really are looking at the mobile core web vital score. And to get a good mobile core web vital score, typically, the best way to do it involves deciding to design a site by starting with the mobile version first and building up to the desktop. You will end up having a better-performing website web page with the core web vitals. But if you start from the desktop and you break it down and only show things on mobile, what ends up happening is those big things on the desktop might end up still loading in the background. We don’t see them on mobile, but they have to load on mobile. And that’s how you get bad mobile core web vital scores because you’re hiding or removing or turning on the hidden element, and that really is there. It’s just hidden. From a coding perspective, what that means is in a default style sheet, the style sheet without the media queries should load the mobile version of the site. The media query should say oh, and if it’s a bigger version, then do this. That’s part of mobile-first web design. A lot of developers are so used to thinking of the desktop first, and sometimes even clients will say I don’t even want a mobile website, but we know we have to give it to them, right? And so, what we’ll do is we’ll show them the desktop, and they’ll approve that, and then we go to mobile because that’s how our processes are built. But in reality, what we should be doing, even if the client doesn’t care or want the mobile, we should start with the mobile and then show them that you build it up to the desktop. And what will happen is, consequently, just that new way of thinking about the site, it will be a better-performing page speed core web vitals website because of that fundamental shift in how we think about designing a page. And so, in summary, mobile-first means mobile design for the three core web vitals, which aren’t necessarily really about speed, but specific measurements of specific things on a web page. Does that help?
Onawa: Yes, definitely.
David: Do you have any questions?
Onawa: I think I need to read further before I can get some questions going. I think I have a very good starting point.
David: Bryan, as another developer, do you have any thoughts, questions, or arguments?
Bryan: No. If Dave’s good, I’m good too.
Dave: I’ve got a couple of thoughts. One is some of the SEO stuff that I looked at before we went through the click-minded course, which was really good. One of the things that they were talking about is when you go to some of those page speeds and stuff like that, and you try to go for something that’s at least good. To try to get something at the really high part could take a ton of effort that may not be necessary. And I think the reason is because, as David said, page speed is only one of the concerns. So, I think when it comes to all these ranking factors, if you focus your energy and your time on just one thing, you could be ignoring the other ones to your peril, as well. And you can look at some of the high-ranking websites for things. You look, and their vitals aren’t very good at all. Right? Take how much importance you put on that with a grain of salt. And so, that’s why they talked about just getting it to be where it’s good. Not like, amazing, just to where it’s good. And the other thing, too, I think, to consider is the user experience. You want to make sure that things are fast enough so it’s not inhibiting somebody from making a conversion. Right? So, if it’s a five-second page load, and it takes them 5 seconds to interact with your site, that’s probably not a good thing at all. But if it’s like 2.1 or three and Google still doesn’t give you the A, well, it may be good enough, and move on to other things.
David: Yeah. I wish I could quote the actual statistic, but the faster a web page loads, the higher the conversion rate.
Dave: Yeah.
David: And there is an absolute correlation.
Dave: Yeah. And probably at some point, it’d be interesting to see what the graph is because, probably at some point, if you go from 1.5 to 1 second, it probably doesn’t make any difference. But there are probably some points where it really does.
David: Right.
Tricia: You’d probably see a steep drop-off.
David: Yeah.
Tricia: And I know sometimes, especially if you’re on mobile, when I’m doing it, if it takes a while, in my mind, I’ve got a bad connection, I need to wait, and then I’ve forgotten it when it actually could just be the website.
Dave: Yeah. And I think the other thing to think about, too, Tricia, related to that, is it all has to start with who’s your ideal client. And part of that, if most of the people that are buying your stuff are in areas where they’ve got a good internet connection, well, it may be less of a worry than if you’re selling feed for cows. Well, chances are people might be looking at that, and they don’t have as good an internet connection.
Tricia: That’s true. Yeah.
David: Lidija, have you played with this before?
Lidija: I have, absolutely. I am optimizing my site. It’s very interesting what you said, and that’s the truth. When I was first doing training, they would explain mobile first. This is not what I do, actually, and I will try to think about how that could be changed, I think. I’m always showing the desktop first and perfect the desktop because, for me, that’s more complex design-wise, and then I make it look good on mobile.
Dave: Yeah.
Tricia: I think that’s how a lot of people do it because that’s the way it’s always been. And mobile then became more used, and now Google is doing mobile. So, I think a lot of designers still do it that way. I think only some are starting not to. I’ve gotten away from designing sites, but the ones I last did it was desktop first. So, I can understand it’s hard to change that process because that’s a big change.
David: Well, I like introducing the concept of mobile-first because I’ve seen good developers deliver websites to me, and they even go to the point where they worry about content layout, and they said, well, the image on the mobile version is only 200 pixels wide, and on the desktop version it’s 800. And to create this beautiful mobile version, they were loading both images at the same time. It’s like, oh my God, it took us a long time to figure out why it was underperforming speed-wise, and then we realized, oh no, you’re loading both images. You have a beautiful mobile design, and you’re loading the image. It wasn’t loading the image. He was using that image here, but still, the other one had to load, and he was loading two images at once, which made it even slower. But that’s why I want to think about it that way because I’m not a developer. I’ve created my own WordPress theme, and I know a little bit, but I find that whenever I write up a spec for a developer, there’s usually another way of thinking about it that I don’t know about that I have to add later because that was a poor development decision. I have somewhere in Curious Ants a series of guidelines for new website builds and stuff like that. I keep them updated because inevitably, every time a new website gets launched, it’s like, oh, I didn’t know you could even do that or that you would even want to do that. And now it’s new, don’t do this enlist thing. Anyway, I hope that helps, but I think I completely agree with Dave. Getting at least a reasonably good score, and I say reasonably good, is the high yellows. It’s the bare minimum out the door. When we’re using content management systems like WordPress, it can be even harder because there are a lot of extra things going on, extra JavaScript being loaded that you don’t know about by plugins. But if you’re building a from-scratch site, somehow, it’s a lot easier because you are in complete control of everything that loads up. But yeah, it’s not the only thing. It is a thing, but it’s still a thing that we should consider.
Dave: We do not do mobile first. And Bryan, you and I have talked about that, and I think we need to revisit that and actually how to do it.
Bryan: Do you mean we start the design on mobile?
Dave: Yeah. But clients are in love with desktops.
Tricia: Yeah, that’s how they want to look at it.
Dave: Yeah. And so then, how do you transform it? Does that mean we have to do two different designs, so to speak? I’m not sure. And then practically, as far as implementation goes, it’s one thing to do design, but then to do the implementation where it’s mobile-first, that’s a whole other thing we have to think about.
David: Yeah, I think there’s a couple of ways I’ve seen it done well, where clients always, every iteration of the design phase, they’re receiving a mobile and desktop version. So, during the design phase, the designers are thinking about both versions concurrently. And so, yeah, the client might focus on the desktop design and have most of their input on that. But by presenting them both, you, as the designer, are inherently thinking, okay, they will change this on the desktop. How does that affect the mobile design? And then, we fix the mobile design so that it would work on the desktop. But I’ve seen it done well that way. The other way to do it is just to work from a mobile-first perspective but show them the desktop version only because we’re talking responsive website builds, right? We’re not talking about two different versions with a responsive website. It should be virtually the same content on mobile as on desktop. It’s just how it’s arranged, right?
Dave: Yes, in a lot of ways. But then it’s the implementation that ends up being different.
David: Right.
Lidija: I sometimes have a feeling that I don’t spend enough time on mobile, so it suffers, whereas it’s very important how the site looks on it. I mean, I make them decent, but I don’t spend nearly as much time thinking about mobile as I do for desktop.
David: One thing that helps is to go into your Google Analytics if it’s an existing site and see how much traffic is mobile versus desktop. I’d suggest most of the time it’s 50/50.
Dave: Yeah, it can depend upon the page too.
Bryan: I think what’s hard there, especially if you do remember the nightmare project that we’ve had, Dave, before. Not going to go into details, but remember that nightmare project where there’s like a difference?
Dave: Which one?
Bryan: There’s that one thing where the filter is different. It looks different on mobile as opposed to desktop. But anyway, at least from my perspective, the way I think about things when building websites is they are like a series of boxes that are stacked on top of each other. So, suppose you have the phone number on top. It’s basically like a box that contains the phone number text, and then followed by, say, your logo on the left side, which is a box that contains your logo, and then the menu on the right side, which is another box. So, how it behaves on mobile is that as you make the screen size smaller, the boxes just stack on top of each other unless they’re overridden by JavaScript or CSS. But by default, the behavior is that they stack on top of each other. So, that’s how it’s supposed to be, or that’s how it works.
Dave: Yeah. Okay, now I got it. Okay, I’m following.
Bryan: What made it difficult is that considering what I just described earlier, where elements on the website are like, if you imagine it, it’s actually like boxes stacked on top of each other. So, suppose you have the phone number on mobile on the first row, and then suddenly, your client wants it to be like the fourth row on the desktop. That’s where things get complicated. It’s like you either add some CSS override that most likely will end up in problems in the future, move things around with JavaScript, or create a duplicate section that has the same content, where you just hide one section on mobile, show the other section on desktop, vice versa. So that’s what we did with the filters, where it’s actually like two containers that have the same set of filters. It’s just that, like, you hide the other one from the desktop and show the other one on mobile. So, that’s where things get tough when you do totally different layouts on mobile and desktop. Sometimes that’s just something to consider.
Dave: Yeah.
David: Now you know why I don’t do website development. I let all of you do it.
Bryan: I’m not sure all of us remember, but remember, I’m not sure if it’s still a thing, but Google launched the app thingy, where it’s supposed to create a super-fast mobile version of your website using their JS, where it strips your website of unnecessary code. But I didn’t think it did fly that well.
Tricia: I think I know what you’re talking about.
David: It’s called Amp.
Bryan: Yeah, Amp, where before they tagged websites with Amp if you look at the search console, then it says Amp thingy, but now they’re not doing it anymore.
David: Yeah, exactly. The lessons learned from Amp are valuable because a while back, Google had this certification called the Mobile Website Developer Certification. It’s an excellent certification. I took it a couple of times, and one of the things it talked about was how the fastest element to load on a web page is the element that doesn’t live on the web page. In other words, is it so worth having that slider box at the top of your page that you’re willing to have a slow website? Is this widget that the client’s adamant about so valuable that they’d be willing to sacrifice conversion rate because the website takes forever to load? And so much of the Web Developer Certification that Google used to offer was about the psychology of how you explain to your boss that you can’t have everything on the page. And that’s what Amp was really good at because Amp basically trimmed the site so that you really were bare bones.
Bryan: Right.
David: And I think that’s why people didn’t like it, because they’re like, oh, but we have to have this very complicated pricing widget and a slider and all kinds of fancy things. The bigger the company you work with, the more people put their fingers on a website, and the harder it is to actually build. Right?
Tricia: I think it’s with everything.
David: That’s true. Website by committee usually is pretty poor.
Tricia: Try getting a social post. Four posts with images took three months and never got approved.
David: Yeah, I’m working with a client right now, and I’m begging them.
Tricia: They already have.
David: Please only allow two people to weigh in on this website, or you’ll never launch.
Bryan: Yeah.
David: Oh, let me just ask… No, don’t ask anybody else. Tell them this is what they’re getting. You’re the boss. Stop asking people. Listen to me. All right, well, now, does everybody feel sufficiently discouraged about their mobile speeds on their web pages? Frustrated with their completely new way of having to do web design that changes everything that you’re used to? Damn suggestions. David just sits here in the ivory tower and says what you should do but doesn’t have to live with the consequences of it.
Dave: Yeah, it’s not the meaning sucks. You suck.
David: Blame David.
Dave: That was a good question. That was a good question.
Tricia: Yeah. I was taking notes because I know we’ve talked about this, but having the whole for core web vitals built for mobile first, I don’t know that that’s really stuck before, but for some reason, that part of it now has registered. Of course, I don’t build websites, but when I talk to clients who are having them built, that would be useful for that part.