SEO & Web Speed - How to Optimize Your Web Performance

Welcome to a new special edition of Crawling Mondays. Today is going to be a very, very special edition because we are going to talk about one of the hottest topics nowadays: speed. Your website speed. Joining me today is the awesome Jamie Alberico from Not a Robot. She's a technical SEO and founder. And Dave Smart. He's a developer and tech SEO Thank you very much for joining me today, Jamie, Dave.

Thank you for having us and not putting a CAPTCHA before we got in.

Indeed, all the bots here right away.

All the bots are here.

Yeah.

What are the most common web speed issues that you find on websites again and again and again? Every time that you audit a website, there it is, these issues right there.

So many different sites. are out there with so many different issues. But the big one is just they send so damn much across the wire, you know, huge payloads. And there's some truism that less is always more with things. So massive, massive overload of things like JavaScript, images, things you don't need to. And then there's some of the more or less mundane stuff, you know, there's to slower servers. There's running some large site on some small shared server somewhere and just not looking at the overall performance before things get to you, and then not taking care of what's getting to you. There's, you know, things like looking at time to first byte and stuff that's older, sort of more speed-related stuff is often neglected, maybe a bit less so now. But one of the biggest kind of issues that I tend to notice now is where people forget about that part. They might have fettled the servers. They might've got stuff sent across. Then it's just, it's gone now. It's not my problem. But there's so much more to speed and performance than just that initial first byte. And that seems to be being ignored quite a lot really.

I thought that you maybe will talk about CSS that are overused and not necessarily used. every particular page or something like that. So I like how you took another side of things and yeah, of course, JS, all the fault, all the fault. But Jamie, I think that you were going to mention it maybe?

Oh, I was about to whip out my handy-dandy Go-Go-Gadget soapbox and say perhaps if you want to have a really performant site, you go ahead and weigh the 4 megs of tracking pixels being constantly fired against the user experience. This is one of the most common things I see, and when I'm under the hood, when I'm collaborating with the team, the likelihood that that data is lacking integrity or is not readily actioned is really high. So we set up this thing, we were sold this tool, it's a plug-and-play, go-go gadget magic solve-all marketing cure that isn't accurate, that isn't complete, that is not actioned.

All loaded synchronously, of course.

Mmm, right in the feels!

Yes.

One of the most common things I see is you— a site relying on a third party. You are relying on them to execute any time you have a synchronous call. So if you're asking a third party for CSS, for JS, for a handy-dandy bit of font, you have to wait for them in order to render to your users. Do you really know them like that? Do you really trust them like that? Maybe I just have trust issues. I don't.

Great point for sure. You know what? It's funny that you mentioned this. I was thinking of something even less sophisticated than that. The other day I was scrolling the website, the first thing that I noticed, images of 10 megabytes. It's like, why?

Dang!

Why?

High quality, right? Like, but compression, you know, fundamental even, best practices have gone. I don't know if because we are focused on so much sophistication using frameworks or trying to add So many additional functionalities in the UI that we haven't even forgotten about the very basics of feed, isn't it? Even with images.

Oh, you've got a tag manager.

It's fine, we'll put it in there. Tag managers are like the gremlins of the internet right now. Add a little water, suddenly 500 pixels.

What would you say that are usually the top things you would recommend also websites to go and do right now to check? to improve their website speed?

First thing is look at what you're loading. Look how much stuff you're sending through. And that comes down to third-party resources. It comes down to everything like your CSS. It comes down to your images. It can even come down to fine-tuning that by looking at how things like your DNS— how long your DNS name servers take to respond and things like that. But normally for a simple view, it's just back to the basics like you were saying earlier. Don't send more than you need to. And then the other part of that is looking what order are you sending those through? Are you sending stuff you don't need to create the initial view until after that? So, but the first thing to look at is just do a quick audit. How much stuff are you sending through that you actually use, and how much stuff? is really needed. So look at those third-party resources. Have a look at your image sizes, your CSS sizes, and see what you need to do there. See how you can feather those down.

Very much going to echo this. One of my favorite things to do when I'm brought in to help with rendering is a content inventory where I literally break down line by line everything called. And there is a bit of sadistic glee In making product owners sit there and stare at the monstrosity they have created. When you finally see everything on the page, how bloated it is, it's very, very eye-opening. One of my, one of my second go-to here is going to be creating a clear measurement and communication of what page speed is, and the acknowledgement that speed is not performance, and it really is more about this devil in the details about how we assemble things than it is about how quickly. It's like you go to IKEA and you buy a bookshelf. The goal really isn't to assemble a bookshelf as quickly as possible. The goal is to have a single functional bookshelf, not a wobbly bookshelf, half an ottoman, who knows what that is.

Is it a meatball?

Why was it in my bookshelf box?

I love that you You touched a very important point. I think that it's important to have like a standardized type of understanding that is like what good speed is. Because of course we have so many metrics nowadays and we have Core Web Vitals now and then—

Oh, praise be!

And then the metric that we now have and see as a reference there that is taken into consideration from Google is the Largest Contentful Paint, right? And we see that Anything more than 2.5 seconds is not considered to be ideal, to be the best. But realistically, a lot of people use time to first byte, first contentful paint, or whatever else. There are so many tools out there. So I think that the effort that Google is putting on having standards of metrics to better understand the impact on speed, also from a user experience perspective rather just for the bot or crawling, et cetera, is excellent. Which, from your experience, is the best way to measure it or good signals, good metrics to have as a reference without, of course, obsessing with them because that is never good. Of course, it's good to be reasonable and prioritize here. But yes, which are the metrics that you tend to focus on and work with?

I do think the Web Vitals are a great step forward for that because it gives you some clear signals. It gives you the Largest Contentful Paint is about Speed to a large extent. FID is about experience in terms of you know has the JavaScript finished? Has it running? And then you've got CLS, which is pure user experience. You know, is this satisfying the user? Is it jumping all around them? So it's a fairly good base. You know, it's it's a fairly good base to start from. Obviously behind those are a whole load of metrics. You know, there's TTI, there's time to first byte, there's total blocking time, which is kind of, you know, a good proxy to use for FIB. But if you concentrate on too many, it's like you said, if there's so many acronyms, so many little words here, you get lost. And I think have an oversight of those top-level ones and keep your eye on those, and you're not probably going to go too far wrong. You know, there's, there's Many things. There's first contentful paint, there's first meaningful paint, there's, you know, first paint. And the difference between— is it a pixel? Is it a breadcrumb? Does it matter? No, it doesn't. Concentrate on the things that actually matter for people and concentrate on what actually matters for your people as well. Um, for some sites, if you're a news article, for example, you're a publisher, largest contentful paint is probably one you really want to concentrate on. Maybe a little bit more than FID because people want to be reading stuff, they don't want to be interacting. If you're a site that does something, FID might be a little bit more important. So pick those metrics. Those are, you know, the Web Vitals stuff are great because they're 3 clear signals. They're everywhere as well, so they're really ones to look at for me.

So Dave just gave us so much to unpack, and the short version is I agree with all of it. I love the focus towards user-centric metrics. For a long time, we've been focused on, ah, how my server does, how the DOM does. Those aren't humans, and those aren't humans on devices on the go. If you are an SEO out there, I really encourage you to go on holiday and to pay for international data out of your pocket. It will give you a new perspective and value to how you interact with content and with data. First Contentful Paint— can I see the thing I came here for? That's beautiful. Focus on that one. Second one, Total Blocking Time. These are both weighted at 25% in version 6 of Lighthouse. That is, can I do the thing I came to do? If I'm a news site, yes, I really care about being able to see that thing. If I'm an e-commerce site, I care about being able to see that thing and hit that button that says Add to Cart. You're doing yourself a favor. You are doing your business a kindness. By focusing on your users and not on whatever monstrosity of tracking pixel you are loading. Stop it right now.

Thank you. And you know what? I love that you mentioned the user impact of all this because speed had been one of the metrics that since a few years ago they had confirmed they took into consideration as a signal. But realistically, the understanding in general is like, this is a small, slight signal, not necessarily one of the top things and understandably, right? Like when you start optimising a website, there are so many things wrong that you need to prioritise, right? So if you are linking to 404 pages or going through redirect loops or things like that, you start fixing those rather straightforward and then you end up leaving speed rather Right? Not necessarily at the start, unfortunately. And I love that by this announcement of Core Web Vitals along already page experience metrics that had been taken into consideration until now, like mobile friendliness, they are all now going to be taken into consideration as a unified type of signal from next year forward.

Well, I think we're giving them a little bit more altruistic credit than Google deserves. Because honestly, tech debt's a thing. Executing JavaScript is hard and they don't want their servers running forever to go out and keep loading these pixels. Well, thank you very much. If you can't render, you don't exist.

I think particularly with things like moving past the actual speed metrics, things like CLS, which strictly speaking don't impact how much power it takes, it's very much also focused on that it's not altruistic from Google. They're after satisfying their users, the people who search for stuff. And if they're sending people off to rubbishy sites that, you know, the content's not rendered down left and right, that's not a great experience for their searchers as well. So there's the technical aspect of it, there's their overheads of rendering, you know, 4 or 5 meg of JavaScript. But there's also some elements, I think, that they actually want to start satisfying users themselves and keep people keeping using Google. So No, it's totally—

This is going to climb up. It's 5% right now. It's 95% of the reason I'm going to leave your site real fast. Stop it. But that's going to keep growing. It's going to be more of the interaction-focused. And I think it's part of that— we know when they render, they're using a Chromium instance. They have the web rendering service. They grab that moment in time and that's what your site index is based on. Well, if that moment in time also keeps flipping around, keeps flitting and changing and shifting, that's not good understanding for them because it's probably going to be inconsistent across pages and for users it's just truly annoying.

Which would you say are those tools that you rely the most when doing web speed optimization analysis auditing?

It's twofold. There's lab testing, there's tools that— particularly Lighthouse. Lighthouse is amazing for it. You get a lot of stuff there. But that's kind of good at looking at something from a technical aspect. It's great at looking at it while it's still in your possession. You can have a look at that. You can have a look at things like CLS. You can have a look at things like, you know, LCP. And you can simulate that in a lab test fairly well. And you should do that. And you should do that to everything you kind of release if you can. You could build it into your release schedule. And then you can let it out in the world. And then it's on to the real-world measurements, which can be quite sobering sometimes because something can be brilliant in the lab, you can send it out, and then it's all over the shop. So that's where once again PageSpeed Insights, if your site is popular enough, you've got crux data, which is what people have actually got. That's what's actually happened in someone's device. So that's invaluable. If your site's new. If your page is new, you might not have that. And CrUX, you're probably waiting 30 days to start getting the full picture on that. So there's other tools as well that you can integrate. The Web Vitals has released a brilliant JavaScript wrapper for the APIs and start collecting those real-world figures for yourself as well. So you can get a little bit of oversight. What are people seeing way before it ever comes Search Console saying, hey, I'm a bit rubbish on this. You know, you can start getting your own data first. And there always will be those URLs that fly under that certain level that CrUX is going to give you that data. So kind of twofold, but Lighthouse, brilliant. And there's also Lighthouse CI, which is worth looking for, which you can build into your build process. And those will give you those baseline figures.

Oh, Praise be, Lighthouse, full of grace. I love it in the lower environments. If you run it before release, if you run it in your lower environments, you can run it on localhost. You know what it behaves like in a petri dish. Then, when it gets out into the world, particularly if you've got load balancers, you've got CDNs, you've got a lot of other pieces in play, that baseline data, at minimum, now helps you kind of know when you compare it field and lab data, where is something running amok? What is this? I find that in our performance analysis and chasing these wild and surly bots, there are things you would not expect as an SEO to be a problem in your world. Like, oh, load balancer 3 was like, nah, I'm not doing AMP today.

Bye.

But these data metrics are really important, even if you may not actively move on them, like 5 megs of marketing pixel you're already shipping. These are very small XML files that you can look back to and you have a sanity check baseline to go ahead and action later on. Also, huge fan of webpagetest.org. Love those guys. Their calculations are actually part of Speed Index, which is, you know, in your performance score from Lighthouse.

I love how they actually already integrated the Web Vitals Metrics. One of the— yeah, very fascinating. And I love also the waterfall visualisation that they have.

Yes.

I am a very visual person, so right there you can easily see where is the bottleneck sometimes. So yeah, I love it too. I love it too, for sure. To start finishing a little bit the episode already, which would you say that is that aspect or that tip that you would like to share with the audience today of something that I haven't yet asked you? Anything that you think that is super important that you cannot finish today's episode without mentioning?

Dave, what you got? You're brilliant, don't hide it, come on.

Lazy load. Just please lazy load. You know, things like images, but iframes too. That's an instant saving right there. You don't need to load those other 20 images when people aren't looking at them. So please, please use lazy load. Use the native support.

And it's native.

Yeah.

I was going to say that. There's no excuse anymore. It should be much more straightforward.

And then move on to your more exotic kind of, you know, fettling of the things. But yeah, use lazy load. That's mine.

All right, most important thing I want to advocate for here: site speed is not performance. There is a big gap between them. Create baseline metrics and an understanding of how you measure. When you have that consistency, you're able to go, hey, this lower environment, this is kicking up our Total Blocking Time substantially, there's something in this new release. This lets you know ahead of time. It creates a communal understanding of what these mean and how they impact. And guess what? When you're working with developers, because you're going to have to, to improve your site speed, creating measurable metrics and showing results, they love it. They get to see the work they did made an impact. Everybody loves that feeling.

It's true. It's important to communicate those wins and to show the evolution and to do a consistent job again and again and again. Because this is, at the end of the day, how you achieve results. It's not by— very unlikely— just tweaking one single thing. So thank you very much for your time. I love your ideas, contribution, actionable tips. You're amazing. But of course, you already knew that, and now all the audience knows it too. And if you have any questions, if you have any doubts, please make sure to leave them in the comments here below. I'll make sure to ping Jamie and also Dave so they can come back and answer any questions too. And of course, if you like the video, please like the video. There are going to be many more episodes like this with special guests coming over, so make sure to subscribe too. And thank you very much for watching. And again, Leave your comments, leave your doubts, and I'll make sure to follow up also with Jamie and Dave. Thank you very much, and thank you very much, Jamie and Dave.

Thank you, Aleyda!

Yay!

You're amazing!