 What do you think are misconceptions about page speeds, and especially is page speed and ranking? Well, a lot of people think that it's a big ranking factor. In fact, I was literally looking at a document that a company had produced. This document actually talked about SEO, and it had section on SEO, which is good. They're at least thinking about it. But the first thing they listed was page speed, and they were actually quite insistent in the write-up that it was the most important ranking factor. Oh, no. And I was like, okay, I've got to find the right way to tell them that I want them to deal with this. Because it's really important, and it clearly impacts user engagement and conversion. No, it doesn't mean you're going to move up three spots in the halls. Hello, and welcome to another episode of SEO Mythbusting. With me today is Eric Enger, and would you like to introduce yourself, because you're doing so much stuff? Sure. What is it that you're doing? Well, you know, I'm a general manager of part of the digital marketing team at Profession Digital. And altogether we do, let's see, SEO, content creation, content marketing, pay-per-click, analytics, conversion rate optimization. Trainings, Twitter, conference speaking. Yeah, that's a fair amount of stuff to keep us busy. A fair amount of stuff to keep us busy. But today we're going to get busy talking about page speed. It's a great topic, because so many people get it wrong. Oh, yeah. It's quite a deep topic as well. Yes. So what kind of questions do you have around ranking factor page speed and page speed in general? So let's actually start in general, and just talk about why page speed is important. How's that sound? That sounds fantastic. I think if you look at what you're trying to accomplish is you're trying to accomplish that you're building a good website for your users, right? Right. So now, how many times have you been on the metro or in a car or somewhere in the countryside where you didn't have fantastic reception on your mobile phone? And you were basically just like really quickly trying to find something out, and it just took ages for the content to actually show up. That's painful, isn't it? It is painful. And in fact, on some sites that can happen when you are in a place where you're a perfectly strong signal. That's actually true, yeah. And that's not so frustrating. Right. And you don't want to frustrate your users. And we as a search engine do not want to have users frustrated when they see content. So for us, it makes sense to consider fast websites a little more helpful to the users than very slow websites, right? It does make sense. And I guess my thought process in this has always been that, well, yes, it's likely that you're using at some levels a ranking factor. But you can't make it such a strong ranking factor that you won't show the most relevant content. Oh, yeah, absolutely. So yeah, if you have bad content, if you are the fastest website out there but the content is not great, then that's not helping you. Right, right. I mean, to get the content you don't want quickly is probably not what the users want. Exactly. Like, I have a blank website. It's the fastest website ever. Yeah, well, yeah, exactly. So, but it does make sense to consider it at least at some level. And there's actually a fun pair of statistics. I think they're both from Google. One is that something like 53% of sessions are abandoned. If it takes longer than three seconds for the page to load. And then the companion statistic is, and I think it's a little bit old, but still the average page takes 15.3 seconds to load. Oh, yeah. What a frightening combination. It is frightening. It's frightening. And it's so many different factors, right? Sometimes it's servers, but sometimes it's just like the server responds really quickly. But then there's a ton of JavaScript that has to be processed for some. JavaScript is a very expensive resource because it has to be like fully downloaded and then parsed and executed. Right. But yeah, so we keep seeing this. And everyone knows this. And anecdotal evidence is there as well. You have studies. You have the anecdotal evidence of you sitting in front of a website going like, ugh. And just imagine being on a metered connection where you actually pay by megabyte when you fly or something. It's like, you can buy 20 megabytes for 10 euros or something. And you're like, oh, OK. Open one website. You said, what was it, 15 megabyte? Is the average or something? Well, it's 15.3 seconds. I'm sorry, 15.3 seconds. But yeah, so you can't just imagine how much data you were pulling in these 15 seconds. Yeah. In fact, I did see, I really was looking at this just yesterday. There is this data from, think with Google, where by market sector it shows the average web page size. And they're all in the megabytes in every market. And I think your recommendation is 500 k bytes or less. Yeah, the fewer the better. The fewer the better, really. Of course, right. And just think about it. I grew up with entire video games on two or three floppy disks, which each fit a megabyte and a half or something. So why are we doing this on the web now? What a great idea. Well, maybe we should help people speed their sites up. What do you think? That's the thing. And that's why ranking these by speed is also an important factor. But as you say, content still is king. There's no question about that. Right, absolutely. How do you think people are thinking about page speed as a ranking factor? What are they trying to do when they are trying to optimize for it? So well, in terms of what they try to do, I think there's a few things that people are really good at thinking about related to page speed. So I think almost everybody recognizes that images are a potential issue. And certainly, pre-sizing the image rather than making the browser do it, for example. And things like that. And so they get to that first level of optimization. But I think there's other things that they find a lot more difficult. So for example, the idea of not loading the content below the fold until the content above the fold is present. Of course, that's a little harder to implement. We have native lazy loading for images now. So that's something, at least. Yes, it is something. And then I think another thing that they have trouble with is, and you actually mentioned in a moment ago, the idea that the way you're hosted and the way your CDN is set up can be big factors if those aren't actually set up properly. First of all, they might not have the CDN. Oh, yeah, yeah. But they may have it and it may not be properly configured or caching and stuff. We've seen all of this. Yeah, exactly. And then it could be as simple as I need more memory in my web server or a dedicated server when I'm on a shared server connection. All of that sounds pretty solid. But is there any misconceptions or moves that are going around where like, what's happening here? Where is this coming from? Is that true? So I do think maybe I could state the myth almost as an inverse is they're too focused on just a few surface level factors. Oh, yeah. And they don't realize there's other layers to this. There's layers to this, yes. Although there's another thing I can suggest actually as a myth, if you will, which is if I go into and get my Lighthouse Tools report on a page and I see it says, oh, this will cut six seconds out of the load time. And then they do that thing and the page didn't speed up by six seconds. And I don't think people realize that some of these things are threaded. Oh, yeah. So yes, I did something good, but I have four other problems that also need to be. Yes. So I do see a lot of people getting touched up on that. Yeah, and Lighthouse is a tricky one to begin with because people are getting confused by the idea that what they're seeing in Lighthouse is what users are seeing and that's not the case because you are literally testing from your machine, from your browser, from your internet connection and not necessarily what real people are experiencing when they're on their mobile phones on a spotty connection out there. So I think it's important to remember Lighthouse is lab data and it makes predictions on what you can improve, but that doesn't necessarily mean that, oh, now you're all doing fine. Do you also think that people are paying too much attention to the scores itself because I hear that quite a lot? Yeah. So like the myth is like, oh, we're using the Lighthouse score for ranking. That's not happening. That's not what we are doing. Right. No, exactly. In fact, they get too attached to that score. And sometimes it misleads them in thinking that they're doing just fine when they actually still have problems. Yeah. And another area that I see people running into is it works fine from my phone, but the user doesn't have such a nice phone. So you have to remember that there's different devices. Yeah. And you could see that in Google Analytics. You can actually figure out what kind of devices you're seeing on your site. And then you can specifically try to understand, best way would be to buy one of the phones that is most prevalent on your site. Yes. And I have a look. A very interesting idea. And I actually shared a slide in one of my presentations recently, which showed data actually for CNN.com processing. And it was around three seconds for the high speed phone. But by the time you got to a user with a less than $100 phone, it was 15 seconds to load. And you just really need to remember that the users have all different manner of devices. And you probably want to do a good job by the great majority of them. Absolutely. And you want to be aware that a slow phone on a slow connection is the worst situation you can probably run into in this kind of situation. And you can use things like web page test to get a better feeling for how that was feel. You can test from different locations and different network connections. I would definitely recommend doing that. There's so much more that you can do. And also, if you have a website that is listed in Chrome User Experience Report or CRUX, then definitely use that as well. And I think not many people are trying that out. Right. Well, it's good to get real world data. Real world data, real user metrics. Absolutely. Absolutely. Well, in fact, you can broaden that piece of advice of well beyond the page speed conversation, by the way. Because it relates to all manner of aspects and things around mobile, for example, because we have everybody who designs for a desktop and then tries to slam that down into a mobile phone format, maybe design for the mobile and then it's kind of easy to figure out how to render that on a desktop. Exactly. You have more screen estate. Yeah, I know exactly. But for the page speed conversation, absolutely, you just have to do that. Definitely. Right. And yeah, I mean, it's such an important thing and people, do you remember the entire controversy when people are like, AMP is a ranking factor? Oh my. Yes. It's not. And then people are like, and page speed pays into that as well. Right. AMP gives you a certain expectation that you can have for your sites in the search results. And I've seen good, fast websites rank higher than the AMP equivalent. So like, maybe it is not the most important ranking factor, but it's definitely an important one, as in like page speed is an important ranking factor. Right. And not so much. AMP is just like this little batch that gives the user an expectation that they can have about it. But page speed does matter for your conversions, as you said. Like sometimes it's configuring your CDN, getting a CDN, configuring your CDN, making sure that caching is done right, and making sure that you architect your websites and web apps in the way that they are fast by default. Right. Absolutely. And if you can do that without AMP, then that's fantastic. AMP is a fantastic tool to help you do that if you don't know how. Yeah. And you can go with progressive web apps as well, by the way. Yes. Yes. Which are very nice because of their ability to preload content into the cache on your phone. So by the time the user requests the cache, it's content is there. Yeah. Yeah. That's true. Yeah. So that's another way to scan a cat. No, I'm not supposed to say that. Because that's really uncomfortable for cats. It's really uncomfortable for cats. Yeah. So take it the way I meant it. I get it. I get it. So anything else around page speed where you're like, what's happening there? Any questions you have on page speed? I mean, really, I guess it's reasonable to presume that there's not any prospective Google dialing up that ranking notch. It's basically you're kind of set with what you've done. I mean, I know the algorithms change all the time. I would say it all the time. But just from the logic perspective, the issue that we talked about already between the relevance of the content being, well, content being king, it's still going to be king. Absolutely. Absolutely. You have to deliver the right result. You want the relevant content first. If you have five right results and maybe it nudges something up. Yeah. Like if you have two results that are basically doing fine content wise, we would probably get the one that is faster, more, more prominence in the search results. Yeah. And also I think it's important to understand that we are not doing it by score or lighthouse or something like that. It is more we are bucketing pages into like this is a programmatically slow one. This is an OK one. And this is a fast one. You see that in the speed report as well in the search console. Right. So I think people need to just like figure out if they have really slow pages that how to make them faster. And probably if they're in the middle bit, you also want to go to the fast bit, but it doesn't matter if you have a lighthouse score of 90 or 95. That doesn't really make a difference. All right. Eric, thank you so much for being here and talking all things page speed with me. That was amazing. And I hope that everyone liked it and leave comments and likes with us. And thank you very much. Hope you all enjoyed it. Bye. Hey, everyone. So next episode is going to be with my fantastic guest, Rachel Costello. And Rachel, what have you brought for us? We're going to be talking about canonicalization and URL deduplication. Sounds really cool. Don't miss it. See you then.