Episode 126: E-commerce SEO: page speed and performance with Nathan Lomax

Play this episode:

Or get it on:

• Apple iTunes
• Anchor
• Breaker
• Google Podcasts
• Overcast
• Pocket Casts
• RadioPublic
• Spotify
• Stitcher

What's in this episode?

In this episode, you will hear Mark Williams-Cook SEO with Nathan Lomax from Quickfire Digital, an e-commerce specialist build agency about SEO for e-commerce brands talking about page speed and performance

They will cover:

• How much of a ranking factor is page speed?

• What is the difference between performance and speed?

• Why are Core Web Vitals special?

• How do you go about improving performance?

• and much more!

Transcription

MC: Okay, welcome to episode 126 of the Search with Candour Podcast recorded on Friday, the 27th of August 2021. My name is Mark Williams-Cook. And today, I'm bringing you the next edition of our SEO for e-commerce series with Nathan Lomax from Quickfire Digital, who are a Shopify specialist agency. So we've had a few of these now on the podcast. And in this episode, we're discussing page speed or rather performance and SEO. We covered the common mistakes, like people making their sites drown in hundreds of plugins, and go into a little bit of detail about Core Web Vitals, how important they are or aren't, how you can measure them, and of course, how you can go about improving them.

Before we kick that off, I want to tell you, this podcast is kindly sponsored by our friends at Sitebulb. Sitebulb, if you haven't heard of it, is a desktop-based Windows and Mac SEO auditing tool. And, this week I actually got an email from a friend of mine, they actually, many, many years ago used to be an SEO client, they're working in e-commerce now. They're a very, very accomplished digital marketer. And I got this message from them saying, "Hi Mark, hows the UK? Just wanting to let you know, and feel free to pass it onto Sitebulb," which I'll do, hopefully, they're listening, them sponsoring Search With Canada podcast and your growing endorsement, got me to use it as a trial. And now I love it. Couldn't do without it and have become a paying member. Have also started recommending it to others down here in Australia.

Now, this surprised me because this person, as I said, is a very accomplished digital marketer. They know their SEO inside and out, and they hadn't tried Sitebulb. And as you know, if you've listened to the podcast, I've used Sitebulb myself for years. We've used it in the agency's one of our main go-to tools. I think, what they do there, isn't a desktop tool that does it better. And it just really surprises me when there are these really experienced marketers that, obviously, like many of us do, we get into a groove of using certain tools, that haven't tried Sitebulb. So this is what I'm going to ask you, if you haven't tried it, do go to sitebulb.com/swc. There's literally no downside. You don't have to enter payment information. It's a free trial. So if you don't like it, you just delete it. But if you haven't used it, I think you're going to be pleasantly surprised. So sitebulb.com/swc.

NL: Good morning, and welcome to the next in line of episodes with myself, Nathan Lomax from Quickfire Digital, Mark Williams-Cook from Candour. Good morning, Mark. How are you?

MC: Hi, Nathan. Good. Thank you. Thanks for having me back yet, again.

NL: No problem at all, becoming quite the habit. Now this morning, we're going to be talking in part five of the series around page speed and experience. And this is something we are often messaged about or asked about. And I thought, well, why not just address it head on and tackle some of those topics that come up. So the usual format for those that are joining us in the audience, please do ask your questions as you go. We will get through as many as we possibly can in the 45 minutes to an hour that we've got together this morning.

Now I'm going to start, Mark, with page speed, is one of the most talked about aspects of websites and every quote or proposal we get in, one of the main things on the brief is always, what can you guarantee about page speed and why is it so important? So let's start with that very question. Why is page speed so important?

MC: Yeah. That's a really good question. And I think it's interesting because I'm going to be really picky here. I think some people say page speed and they mean performance. And some people mean performance and they mean page speed. People use the terminology for different things, but they're not the same. So if we're going to talk about page speed, we'll end up talking about Core Web Vitals and stuff, and that's all about performance.

So page speeds are looking at how long it takes a webpage to load. And it's not even that simple. Because again, when we talk about Core Web Vitals, we're actually going to talk about perceived speed, which is when the user feels things are loaded and when they're satisfied, versus when the whole page is finished loading. So you can already see we scratched the surface and it's like, "Oh, it's not quite as simple as how long does it take for this page load?"

The reason I think it's so important is, it's a universal shared experience or a universal shared pain. Everyone understands what page speed is as a concept or performance is as a concept. Everyone's had that experience where a website had the audacity to make them wait more than one second for something to load and they click off and go somewhere else. And it's something that's constantly evolving. Expectations are constantly increasing in terms of page speeds. I remember trying to use WAP internet on a Nokia and I was majorly impressed that pages were loading in 20 seconds. And it was just text. And now, I'm annoyed if a whole e-comm site doesn't load pretty much instantly. From the business point of view though, it dramatically impacts your bottom line. So there's a really great website if people haven't seen it, which is called wpostats.com, and its web performance optimisation stats.

And they just give very short snippets of real life case studies of when companies have improved performance and the impact it had. So I pulled off a couple here, because I put some actually like you in a proposal a few days ago. So Vodafone increased their page speed by 30%. And that sounds a lot, but it's probably in fact only a second or two, and this gave them a 15% increase in their lead rate and an 8% increase in sales. Bridesmaid dress retailer Revelry launched its e-commerce site on an updated version of its e-comm platform, it's just smaller images. The site loaded 43% faster, and their conversion was up 30%. And fashion retailer Missguided, who probably a lot of us know, removed something called BazaarVoice, which is a plugin that pulls together user-generated content. Took that off and it improved their page load time by four seconds. That increased their revenue by 26%.

So imagine increasing your revenue by 25%, by doing one thing. It's huge. It's absolutely huge. And I've had clients in the past where I've asked them, I've said, "Okay, I think we can increase or decrease your page load time from," it was pretty bad is at eight seconds. And I said, "To about five. And this is going to cost about three grand." And they were like, "Mmm, no, thank you. That's really expensive." And I was like, "Why aren't they doing this?" And I came back to them and I was like, "I think I can add about 30 grand onto your business per year. And it will cost three grand." And they were like, "Well, yeah, of course." It's like, okay, well, these are the same thing. I'd obviously explained it badly, but that's why it's so important to users and businesses.

NL: Well, let's just build on that because many clients, whether you be on a WordPress or a Shopify or any of those platforms, will go along the line of adding apps for extra functionality and everything else, but they're trying to have their cake and eat it right? They want all the functionality. So, great example with Missguided, they've added this BazaarVoice for Android visitors because they think it's going to help the user experience and everything else, but actually, it's helped over here, but it's a bit like a game of whack-a-mole. It's now caused a problem over here. What is your recommendations to people when it comes to adding lots of functionalities. It always just get a business case. The number of people I talk to go "I was down the pub last night, and someone mentioned that they use this app. Can we try it?" And you're like, "Yes, but have you thought of the implications that might have two other metrics that you're trying to satisfy?"

MC: All functionality does come with some cost, whether it's user experience complexity or like we're talking about performance now. And I think this is the pros and cons of various platforms. So Shopify is one of the leading e-comm platforms for a reason. It's really quick to get set up. If you start going to the extreme end though, which is you need lots of tied in functionality with any system where you're using extensions, add-on plugins, it can be difficult, because they all operate in their own silo. So you got three plugins and they all work separately. You can have two and three or one and three or just two. If you really want lots of complicated functionality, then sometimes it's normally a big step up in budget, but that's when you start looking at bespoke builds to tie these things together.

Otherwise, like with any platform, any system you're on, you do have to make a decision. And my advice would be to listen to your developers and test things before you put them live. You can test how it's going to impact your performance before you put it live. And then do a test on your revenue, on your bottom line. So like Missguided saying, "well, you know, apart from the bottom line impact it's having, how is say Bazaarvoice helping our marketing, and is it driving new traffic to us? Does that outweigh short, long-term that the extra conversion we've got?" So it's a really difficult, complicated question, but yeah, I've experienced that as well, which is you certainly shouldn't just be like, "Oh yeah, we want our site to do this. Whack this on. Whack this on. Because you will get yourself into debt.

NL: I mean, I like the idea of a bit of an app audit where you just essentially have your apps and you say, "Okay, we need to look at page speed as a metric, as a whole, let's go through our apps. Which one is absolutely critical and we can't live without? Which one could we try living without? Well, let's disable it for a week. Let's have a look at impact and revenue. Good, God, it's gone through the roof. We're actually very little difference. Therefore, let's turn it back on and let's try it with something else." Again, something that many retailers should look at because these marginal gains of which make all the difference. They assume compound. And before it, you've gone from a 2% conversion to a 4% conversion or whatever, that could be a massive impact on the bottom line.

So certainly one to pick up now, building on the topic we've just discussed, as you know and would have seen, the web has been awash with chat around Core Web Vitals, right? And every man and his dog wants to know about Core Web Vitals. Just for those that perhaps are new to the concept. And if you are new to it, I'd ask where have you been in the last however long, but perhaps you haven't heard of it. Mike, let's just give a quick overview of what Core Web Vitals is, and then we'll dig in in a bit more detail.

MC: Sure. So Core Web Vitals are three metrics that Google has put forward to measure user experience. Okay. The three metrics are LCP, which stands for Largest Contentful Paint. That's a speed metric, like a page-view metric. And it's an indicator of what I mentioned earlier, which is perceived load speed. So it's basically when most of the pages loaded for the user. And they give us like a traffic light system for if it's good, if it needs improvement or if it's bad. And the second metric is FID, which is First Input Delay, and basically, it just measures interactivity. So it's the delay in milliseconds before a site becomes interactive. And again, we've got this traffic light system of, if it's less than a hundred milliseconds, that's great. If it's more than 300 milliseconds, it's bad, it needs improvement. And lastly, there's one called cumulative layout shift.

These all have really complicated sounding names, but they're all things you'll be familiar with. So cumulative layout shift measures when a page loads, and I'm sure we've all experienced this, when things jump around as it's loading. So the big culprits of this, or always like the "See what this celebrity looks like now" slideshow type thing. And then you go to click next and then it jumps down and you've clicked on an ad. That kind of thing. So Google doesn’t want your page to jump around. Now what's special about these three metrics is that they can be applied to any website. There's no special case where, "Oh, in this situation, it doesn't matter if CLS is high or if perceived page speed is high." And that's a really difficult thing to do when you think about it. If you try and think of any other metric to measure user experience that can be applied to any type of website, whether it's e-comm or Wikipedia, that's a very hard thing to do.

So they're very interesting metrics from that point of view. Google gives you two different ways to measure them as well, which we won't get into that right now, but there are tools out there that you can literally measure on any sites. The other difficult thing about web performance stuff is actually what tools you use to go about measuring it. And again, in the past, we've had clients saying, "Well, we've run this report from this tool, and it says it's good. And then this one says it's bad." And they're all measuring in slightly different ways. And they're measuring may be from different places in the world as well, which all has its impact. So yeah, core vitals, very special because it covers not just page speed. It covers the whole bag of performance and they can be applied anywhere.

NL: So Mark, it'd be a miss of me not to ask what tools are you guys recommending when talking to clients around where to begin when testing Core Web Vitals, whether that be on their own store or competitors stores, or perhaps on a new store?

MC: When it comes to Core Web Vitals, there are two ways to measure them. You can use what's called lab data or field data. In your Google search console account, you'll have access to what's called your field data. And this is data coming from real people's browsers. Okay. And why this is important is it's reflective of how your actual visitors are experiencing the site because there's no objective. Your site has scored this, for instance, on Largest Contentful Paint on page speed, because if you run a test from the UK on a fiber connection, you might score really well. But if all of your customers are somewhere else in the world and the internet speeds a lot slower and they run the test, you're going to score badly. And of course, you need to build your website for your audience.

So it's no good doing your test locally. And then looking at the field data and being like, "Oh, actually most of our customers are in this country and the web slow, so the website's bad." So I would always start by looking at the field data because that's your actual data from your real users. And again, you can really get into the long grass and decide, "Okay, well, we might actually have two different versions of our website. One may be for people in the UK or in Western Europe, and one for where our users are connecting from where the Internet's slower perhaps. That's going to improve your previous scores, but actually improve the experience of the user. The lab tests are ones that you can run anywhere at any time. So the most important to use is Google has what's called a page speed insights tool. That will give you your core vital metrics. So you can just Google page speed insights. Things to be aware of is, as I've said, it matters where it's run from. That test. And also if you just run it twice in a row, you may get slightly different results. So nothing is living in a vacuum and [crosstalk 00:16:25].

NL: Why is it that you get two different results when you run one now and one in five minutes time?

MC: Depending how your site's set up, even if you're sitting on your own server, it's not always going to respond. It's going to respond as quickly as it can, but there might be network traffic between what you're doing the tests from and there. The site may be busier. The internet isn't just sitting, waiting blank for you to do something. There's lots of traffic being routed around. Lots of systems doing fallbacks and trying to get everything as quick as you can, but it will be slightly different every single time. You wouldn't expect major differences unless, again, you've got maybe some issue with the server. If you're doing those lab tests as an agency, or if you've got developers in-house, what you would actually do is you would set them up to run automatically a few times a day, because then you get a fair average of what's going on.

If you haven't got the ability to do that with a development team, there are tools, like I mentioned before on the show, like Little Warden, and Little Warden would actually monitor your site and do Core Web Vitals tests. And it will send you email alerts on if you change the threshold. So we mentioned there's that green and the red threshold system that Google scores us by. So if your site on average moves from green to yellow, or hopefully from a yellow to green, it will send you email alerts. So that's a really good platform if you don't have dev at your beck and call to set up that kind of monitoring, because the only problem with the field data is, while it's reflective of the user experience, there's like a month lag on that data.

We're at the midpoint in the show, so I want to give you an update from our podcast sponsor Wix. You can now customise your structured data markup on Wix sites. Even more than before. Here are some of the new features brought to you by the Wix SEO team. Add multiple markups to pages. Create the perfect dynamic, structured data markup and apply it to all pages of the same type by adding custom markups from your favorite schema generator tools or modify templates by choosing from an extensive list of variables. Easily switch between article subtype presets in blog posts and add quick links for structured data validation in Google's rich results test tool. Plus, all this is on top of the default settings Wix automatically adds to dynamic pages like product, event, forum posts, and more. There's just so much more you can do with Wix, from understanding how bots are crawling your site with built-in bot log reports to customise URL prefixes and flats URL structures on all product and blog pages. You can also get instant indexing of your homepage on Google while a direct partnership with Google My Business lets you manage new and existing businesses things right from the Wix dashboard. Visit wix.com/seo to learn more.

NL: So Mark, let's say we carry out a Core Web Vitals report and we're like, "Okay, now we need to dive in and fix pages." When you're putting in the URL into the Google page speed tools or insights, do you just put in the homepage and it does the whole site. Do you need to put it on each individual page? How does it work?

MC: Yeah. So the page you put in it is just going to test that page. Now in terms of performance of a website, normally you can break that down by template, meaning the homepage is normally unique. If it's an e-commerce site, you've most likely got categories, maybe subcategories and products pages. So at a minimum, I would test a few variations of each template of page, because if there are systemic issues that you can fix. So they're the ones that are going to have the biggest impact. So if you fix an issue on a template, it will be present then all versions of that template. So you've made quite a lot of gain, and that's how you're going to discover it. Of course, there might be outliers where someone has uploaded a 10-megabyte picture on a single product or something. And that can be picked up through more automated monitoring.

But if you're running these on-the-spot tests, you need to identify what the different templates are and do a range of tests on those. In terms of the field data you've got as well, from Google search console, it's super smart, because it tries to group that performance by the template as well. So Google is obviously reading your code and looking at your site and it's saying, "Hey, these 200 pages are very similar, and we found this issue across what we think is a template." So actually the tools are pretty good in terms of field data. It's trying to help you with that. I keep talking about field data. I'll give a caveat though, as well. You need to have a fair amount of traffic to your site before you get that field data. So if your site's new and you've only got a hundred visitors or few thousand visitors a month, you might not have any field data, because Google doesn't have enough averages to give you good numbers. So it might be blank. So you have to do lab tests.

NL: Mark, the question just in. Would you start with a homepage, product page, category page, or another?

MC: I'd probably start with the templates where I'm getting the most traffic. So I would guess that's going to be category pages in most cases. In terms of what would I fix first? There isn't a high cost actually running the tests in terms of time or anything. So I'd test them all, but then in terms of what would I fix first, it would be where the greatest impact would be for the lowest cost. Anything really you do in terms of a site like that, you're trying to make a business case for why you're going to make a change. And that normally starts with, how you mentioned with the plugin audit. You would do an audit of your templates and then you would have a little look and identify if you are scoring badly, try and see if you can work out why you're scoring badly, and then what you think the impact would be if you fix those things, and how difficult they are to fix. Because it's all well and good if you think, "Okay, you know, this thing, if we fix it, we'll have a really big impact, but we have to rewrite half the site to do it. It may not be worth it." It may be doing something that will have a smaller impact, that's one line of code and the template you have to change.

NL: Mark, where do you sit in terms of, if someone's had a site built in the last six months and they listened this morning and they go and run the test and it's not scoring as they'd hoped, where do you sit in terms of, well, is that their problem? Is it the developer's problem? That surely is a real gray area, right?

MC: Yeah, it's really interesting. Firstly, I'd say don't worry if your site's not all green. So the majority of sites I look at are amber and red, that's really, really common. The other thing I would say is that as I said, technology and expectations change. So even if a site was built six months ago, it's very hard for a developer to say, "Oh, well, it's going to score like this on Core Web Vitals." Because as I said as well, it depends on the connection speed and technology of the person that's actually doing the test and the people that are using the site. So it might score really well for the developers, but not for the actual end-users, and the actual technology of how we can optimise sites is always changing. Several years ago, we didn't have all the services like Cloudflare, now offering various types of caching and CDNs.

There wasn't native support in HTML for lazy loading images. A lot of this stuff didn't exist. Especially if your site's a few years old, the way I would recommend all businesses view their website is that it's never finished. So the environment in which your website is living is constantly changing, that's constantly evolving. You should be thinking of your site in the same way. So how can we keep our site up to date and meeting expectations, meeting these technological changes? Not "Let's build a site and then don't touch it for five years. And then in five years, everyone agrees is rubbish and then start from scratch and build another one." You should be looking at this continued improvement.

NL: Definitely. Now in terms of, you mentioned there about caching, you mentioned there about lazy load. There are obviously a couple that almost apply to every site, right? And normally when you go and do an audit, you can almost guarantee that those two will be relevant in terms of improving performance. Are there any others? Low-hanging fruit that almost without looking at an audit, these are the typical things we see, scripts not being magnified, et cetera, et cetera.

MC: Yeah. That's a really difficult question because when it comes to improving the scores, I think a lot of people underestimate how difficult this can be. So it might be like, "Okay, well, we just need to do caching." And then it gets into the conversation, "Which kind of caching, and which parts of the site." And then, as anyone that's been involved in development will know, caching can become very tricky with people's cache sticking or expiring. The amount of times I've heard, "There's an issue with this website." And then half an hour later I heard, "Oh, it's a caching issue," is too many times to count. Common issues that always crop up, for instance, are things like JavaScript. Sites being really heavy with JavaScript libraries. And this is because there are lots of frameworks out there and CMS systems. CMS is that try and do lots of things and therefore come packaged with a lot of JavaScript, so they're quite heavy.

And there's a process you can go through called tree-shaking, which is essentially looking at which JavaScript, which files are actually used by pages. And then if they're not used, stopping them loading, but again, that's a very technical process that you don't want to get wrong and can cause issues. We mentioned lazy loading. So that sounds like that's really obvious to do right? It's got native support. Lazy loading for those that don't know means that you don't load the images basically until the user scrolling down to them. So it saves that initial load time. So you think "Brilliant, we implement lazy loading." What you're probably going to do then is make your cumulative layout shifts score worse because as you scroll with the page, it's going to resize to load in images because you forgot, apart from lazy loading, you also need to put placeholder images in, because that then keeps the page structure the same when you move it, so you're not ruining your cumulative layout shift score.

So like you said, it's almost like sometimes whack-a-mole with these optimisations and trying to get everything to work. Yes, there are other basic things like we mentioned before. If you are uploading products, making sure you're optimising your images or making sure your CMS optimise your images for you is a really basic one. We mentioned that in the web performance stats website as well. I think it was 41% I think we said faster, just because they made their images smaller. But it's definitely something I would go to the developers about, and you need to get a price and make a business case for it. It can get quite technical, is the only thing I'd say. But this is, again, when I gave that first anecdote and I said we made some changes and it was going to cost the client three grand because it was a lot of work, but it was worth that several times over in terms of revenue. I think the most important thing business owners need to [inaudible 00:29:07] is the value of performance, which is very high and immediate.

NL: Yeah. So in terms of website speed, Mark, for years people have said it's a ranking factor. Is it a ranking factor? Is it not a ranking factor, Google Core Web Vitals suggest that maybe performance is a ranking factor, but speed itself, is it a ranking factor? Is it not? And how can we just get this myth sorted once and for all?

MC: Yeah. So pre-Core Web Vitals. The answer was not really. Google specifically said "If there are two sites and one load in six seconds and one loads in three seconds, there's basically going to be no difference there." Of course, if you had a site that's really slow, taking 15 seconds to load, then yeah, you're going to get a problem. So they used to have this fairly binary system, it seemed, of if something was really bad, then you got a mark against your record and you might find you're not ranking as well. Now they have a page experience algorithm that includes a whole bunch of things. So Core Web Vitals is one of them. Things like non-intrusive interstitials. So they don't want people whacking up massive hard to close pop-ups over the content. And there are several things that go into that algorithm of page experience.

Yes, web core vitals is one. And one part of web core vitals is this perceived loading speed, this Largest Contentful Paint. Now, when I talk to clients about this, I actually tend not to talk too much about SEO, because as we've just been saying, this perceived loading speed has an impact on the bottom line, that's quite measurable and really important. So I treat the fact that "Hey, we might rank better," almost as a bonus. So, it is a ranking factor, but again, if we think about just ranking, we only need to be better than our competitors. You don't need to run faster than the lion. You just need to run faster than the other person. That's pretty much what you can say in terms of that as a ranking thing, but it stands on its own in terms of the conversion rate and bottom line.

So that's why I would focus heavily on it. And then you've got this argument about, "Well, it passively affects things, or it affects things indirectly, because if people like your website, they're more likely to share it, link to it, do all the good stuff that you want people to do on a site." So yeah, performance is one area, especially if your competitors aren't, that you can stand out. It's one of the reasons why, even though lots of people complain about Amazon and tax and things like that, they still use it because it's so convenient and so fast.

NL: Yeah. Mark, last question for today, really keen to find out from yourself, what are the three practical things website owners should take from today regarding page speed and experience moving forwards?

MC: Yeah. So the first is if you haven't done it, or if you don't have one, make a Google Search Console account. So Google Search Console is your diagnostic dashboard. It's your direct line to Google. It's free and look at your field data. So this is the actual people. If you're seeing lots of red on there, then it is definitely worth a discussion with someone to work out what you can do. The simplest thing, and the thing that I still see, is what we mentioned about image size. So we still see loads of e-comm sites uploading these working, great images that aren't optimised. You can compress images losslessly really well nowadays. The user can't see that there's any quality difference, but you can massively reduce file size. And these should be optimised for different devices as well, so you're not loading in working, great images for mobile.

And if you're not on one, looking at a CDN or Content Distribution Network, something like Cloudflare or similar can really, really help you. So that's going to make sure your assets are served as locally as possible to visitors. Especially with paid versions of CloudFlare, you can do some really good stuff with caching, which means that all of your performance metrics should improve in terms of, we're not having to query databases. Everything's just there and it's ready and it's fairly easy to set up. So yeah. Check Google Search Console. Really make sure, go back to basics. You've got your image size gain sorted. And if you're not on one, look at CDN services.

I hope you enjoyed that recording of Nathan and myself and found it useful. If you want to get involved in these, we do them every couple of weeks on LinkedIn Lives. You can actually join in and ask questions and we'll try and do them as we go. Or you can submit questions early. You can add me on LinkedIn, Mark Williams-Cook if you do want to get involved. Apart from that, I will, of course, be back in another one week's time, which will take us into September. So it'd be Monday, the 6th of September we'd be back. I hope you tune in. If you are enjoying the podcast, please tell a friend and I hope you have a brilliant week.