Welcome to Marketing Labs. This podcast is brought to you by Marketing Labs, an expert digital marketing agency based in Nottinghamshire. If you're a business owner or marketing professional looking for straightforward non-salesy tips and advice to help grow your business online, then this podcast is for you. Strap in because we're about to reveal the things that other agencies would rather you didn't know.
Hello and welcome to episode 29 of the Marketing Labs podcast. I'm your host, Tilly Hayes, the SEO exec here at Marketing Labs. Did you know there's a 20% drop in conversion rate with every one second delay in page load time? In this episode, we're going to discuss common cause of slow website load speeds and how to optimise your website for lightning fast performance. Joining me today is our web development specialist, Josh Stapleton, our CEO, Matt Janway, and our creative director Tom Haslin. How are we doing guys?
I'm good. Yeah, pretty good, thank you. Yeah, very good. We've had a nice exciting morning.
Yeah,
So it's always good to do a pod after.
Always nice to visit a client. For those that don't know what an exciting morning is, we visited a new client, LNAA. What's that stand for? Josh
Lincoln Knots Ambulance.
Congrats.
And we saw the huge helicopter. We saw ABI copter, a helicopter.
So first off then, what are the most common culprits behind a slow loading website?
There can be a few, but I guess most often it tends to be poor optimization, like old outdated software. It's quite a big one. Also, you tend to find this a lot more kind of after a website has been around for a while, but it's having a server that's not quite adequate for the use case. So you might start off on a pretty small shared cloud server and you just outgrow them eventually, and a lot of people tend to not factor that in when they're allocating resource to things like this.
Budgets especially, I think maintenance budgets, it is one of those things a bit like security. It only really gets taken seriously when it's too late, but maintaining a website makes a big difference to its performance. Josh said servers. Absolutely. Websites get more bloat over time as well, so the longer it's live, the more of an issue that might become. But also on top of that, one of the most common mistakes we see all the time is just people uploading full size media. If you've got an image that's two megabytes, by the way, we've seen images that are 20 megabytes, but if you've got an image that's two megabytes, really that's loading 20 times slower than it needs to, if you can aim for 100, 200 kilobytes each, sometimes you won't be able to and that's fine, but the difference between 200 kilobytes and two megabytes is literally 10 times larger, so it's going to take 10 times longer to load. So images is a big culprit as well as video and things like that. Media,
I think a big one that I was going to add was plugins and things like that. We see, I am speaking from a WordPress perspective here. There are other CMSs that use plugins and things, but you tend to find that the more plugins that you instal, the heavier it is on the website.
Yeah. Also what those plugins are doing, and you can easily instal multiple plugins and I dunno, one plugin might be able to do the job of three in some cases
Or even out the box sometimes, actually.
Yeah. Often
We do see
That people adding plugins to do stuff that's just already a feature,
They
Just don't like the way that feature works,
For example, or they don't know it exists maybe or how to use it or find it, but that is interesting. That happens quite a lot. In fairness,
The best case is though you've got a really good looking web developer internally that could manually code something that a plugin does. Phoney . We had one of them
Outdated theme outdated like CMS, just in general. Also like your server, if your server's not being kept up to date, that can also make a bit of a difference, although depending on your level of technical knowledge, that might be a bit out of your reach. You might want to speak with your hosting provider about something like that.
But PHP moves relatively fast, doesn't it? And if you've got an extension or a plugin that's designed for WordPress that is designed to run off PP seven within a couple of years, you could I think, well, what are we on now? PHP 8.8.
Point three,
Yeah, so I mean there are plenty of plugins still that'll only work on PHP seven point something, so it does get slightly complicated at that point because you really need to update the server to work with the latest version of PHP, but sometimes plugins are a bit behind.
You just end up being in a constant loop of PHP being outdated with the plugins and then the plugins don't work with other plugins. And then
This is why maintenance is so important because if you're not maintaining the website, they're always out of date and you end up in situations where there can be conflicts and WordPress will want to update the core files. If you're on WooCommerce, they'll want to update and you've really got to keep them all running quite smoothly, haven't you? I
Think WordPress has actually started making auto updates, mandatory major updates anyway. I'm not sure about their minor updates, but that can be pretty problematic if your plugins are really outdated, WordPress has a massive update and then suddenly all systems have shut down pretty
Much. And conflicts, conflicts themselves are probably quite a large source of slow websites in fairness, aren't they? You do see it where there's two things trying to do something and they conflict or they share the same potentially sometimes the same code or the same files. They're just not compatible and that can cause performance issues.
You just get a load of plasters everywhere, don't you?
Yeah, basically. Yeah.
About excessive redirects and things like that as well.
Yeah, yeah, that's a good point actually. Or
Chains.
Yeah, chains. Because if a websites, obviously each redirect chain, the server needs to process that, so it doesn't happen instantly, and that does slow down the user as well as Google bots and so on. But the interesting thing about that is if it's quite an old website, quite an old CMS, these things build up over time, don't they? And quite frequently you'll find it where a page no longer exists, so there's a redirect that redirect points to a new page, but then over time that page no longer exists and then you go again and again and again and yeah, that can really slow things down.
Do you see it often where sites will become immediately slow after a migration? Sometimes?
Depends really. I mean it could. We've not done it maybe, but yeah, maybe if we've not done it, usually we'd be pretty on top of that kind of stuff. It is probably possible if you were scaling down your server, for example, whilst doing the migration, you could probably see something like that
Or an over complicated instance of
Yeah, if you've thrown up a load of new features onto it, it could very easily happen. Usually we tend to advise actually not doing that. Basically if you're going to migrate to a different CMS or something, try and keep it exactly the same because then you're going to know whether the migration itself is the cause of any issues or whether any additional plugins or features that you might have added to on new pages could be slowing it down.
That's a massive thing actually, isn't it? It's amazing when there's a migration. Migration covers lots of things, doesn't it? So it could cover changing your domain name, could cover a website redesign, could cover moving to a new CMS new URL structure. The more of those things that you add into place as part of that migration, firstly, the more you have to analyse if things don't go well, but secondly, the less confident you can be on what the issue is that might be causing it. Generally though, when we do a migration, will do benchmarks before and afterwards and make sure that it's not really deployed until it's performing better ideally. But it does depend, like Josh says, there's a lot going on, isn't there?
Most of the time though, you're aiming for better, bigger, and
Better. What would you say the main consequences of a website? That isn't? For me,
I think the first one for me would be user engagement or bounce rates maybe. I think if your site's loading slowly, people are getting lazier and lazier, aren't they? Nowadays. They're not willing to wait around, so they'll just go somewhere else and you
Lose span are so low.
Yeah, it's crazy.
Yeah, you're right. Yeah, this is the thing actually. I think there are so many consequences. UX is the big one, so that impacts conversion rates, bands rates, affinity with your brand, how you are seen, how you're portrayed, but even coming outside of the customer side, obviously a big impact on SEO. I don't think it's great for much to be honest. It is one of the things as well that coming back to the point about maintenance, how it's only usually taken seriously after it's needed, a bit like security. It's the same with speed actually. I don't think too many businesses are proactive about speed and they probably should be because it has an impact on everything. If you're advertising, let's just say someone's running Google ads and they have a budget just for simple mass, let's just say a thousand pounds a month, it drives a thousand clicks and the site speed is causing the conversion rates to be lower than they should be actually just by fixing that, okay, it might cost you a couple of hundred qui just to maybe a bit more to upgrade the server or to do something about it. Actually you are converting more of those a thousand clicks without spending any more on your marketing.
Yeah, I was going to say you're going to be losing sales on conversions big time. If your site's slow the user, like I said, it is not going to stick around, are they? No, you're going to lose them.
Yep.
It's hard enough getting them there.
Well, this is the thing. Yeah, digital marketing is not easy, is it? Everyone wants those clicks and everyone wants those customers. Yeah, it's not a good idea to waste them when you do get them.
No, I was just going to say, not to mention the long-term effects it has on SEO. If you are actively trying to increase your SEO performance and you've got a slow website, think about the actual boost that you could be having if you had a fast website and you were also putting these efforts in,
You're pumping all this money into something and then for it to not perform, it's not good enough. I'm trying to think. I always use a car analogy. It's like you're paying all that money for a car and then you're not going to put any fuel in it to look after it and what's the point
You've
Got to maintain. It's like a car, isn't it really? You've got to look after the brakes, there's lots of moving parts.
Yeah, no, for sure. And consequences as well. From an SEO perspective, you've got direct consequences and then indirect consequences. So the indirect consequences are things like ux, so the signals that users will be passing back to search engines, which do directly impact rankings, but it's an indirect impact of a slow site, but then you've got your direct impact like core with vitals and those things, which again directly come back to speed and performance. So yeah, it can make a difference for
Sure. Quick question from me. Does a slow load insight actually affect crawl rate as well? Like from Google
Site? Yeah, waste resource. Yeah. Yeah, waste resource even more so getting a bit more technical, but even more so when the website uses JavaScript to render pages is very difficult to render and not necessarily to crawl JavaScript, but it slows the process of rendering and indexing down substantially.
I know you try and stay away from JavaScript quite a bit, don't you Josh?
Well, I dunno. I suppose technically when it's not needed, that's the main thing and most of the time for most of the visual things that you're looking at, it's not needed. You can animate with JavaScript, you really shouldn't know,
But it's quite a simple one. Something like HubSpot for example.
A lot of their forms of JavaScript
And is that going to impact?
They're heavy as well.
Yeah, that's what I mean.
It's complicated as well because not only are they heavy and not only do they slow your website down, but those files aren't hosted on your server so you can't really control them too much.
There
Are a few tricks you could probably place Josh, Mike mention a couple, but generally unless you are hosting that file, you can't really control how much resources is being put behind that loading, so you're just relying on another server for a file that you arguably could do without. Anyway.
A lot of that logical stuff though you wouldn't be able to do otherwise, let's say without just relying upon them unless you're making custom systems on your own.
Yeah, this is the point that I'm trying to make though is that a customer or a client might be wanting to use HubSpot without knowing that it's going to affect their site
Speed. Yeah, definitely. It's
Just something as simple as that
And a lot of times the kind of flexibility that's offered by systems like HubSpot or another one like MailChimp or something like that or just anything that's collecting data and shipping it off elsewhere, nine times out of 10 you could be collecting that data yourself. It'd be a hell of a lot quicker on your server and also you're in control of it. You've got no third party involved
Or all the cost. I think it's convenience often, isn't it that causes this. It's like okay, we can just use a platform,
But even with a little bit of technical knowledge, you could still collect all that data yourselves and then just set up a crunch drop or something that's occasionally just shipping that out to your third party rather than being loaded on the site all the time
Or a good partner that has the TE knowledge
To do that
For you. Yeah, it's not that complex is it? In reality also some of these, but not bashing HubSpot by any means. I think it sometimes does an extremely good job, but there can be quite costly as well, so it is costly on so many fronts, it's costly on ux, potentially it's costly on SEO potentially it's costly on your bank for sure, both for the cost of HubSpot but also the cost of the impact of lower conversion rates and things. So these things really need thinking through I think instead of just jumping into them no big time,
I'll give credit where it's due though. There are a lot of features to software like that and if you are taking advantage of all of them, it may make sense
For sure.
I don't want to completely bash it and just say don't use it because there are circumstances where it will
Be official, especially sort of business crucial processes that involve other departments and things like that, but it just needs weighing up, doesn't it? That's the thing. You just got to decide how valuable those things are and also whether you can circumnavigate them by doing something else.
Just going back to service for a minute, I know we mentioned that we shouldn't be underestimating maybe upgrading your server and how little that may cost you to do so what's the role that servers play in website speed?
What's the role they play? So servers, a little bit of background, a server as a computer, just in case people aren't aware, the idea is that a server is purpose-built to host websites rather than from games if you're me or right word documents or things like that. If your server's slow, if the hardware's slow, your website's usually going to be slow. You're usually renting a server and you're usually renting just a little portion of a server when you're starting out. They're relatively cheap, but you can go for larger servers as well where you are getting dedicated resource. So it kind of scales with how much money you spend on how much resources you're going to get and that kind of equates to how quick your site's going to be. There's a lot of other variables to throw in there as well though, so it's not always just throwing one a server and it'll run quicker
Specialisms as well, I guess. So for example, you might have a server that specialises in one in a particular CMS like WordPress and everything about how that server is set up is designed to work well with WordPress and if you just plunk a different CMS on it, it wouldn't be as efficient. It's a bit like using the computer analogy, it's a bit like a gaming computer versus a non-gaming computer. Chromebook. Yeah, exactly. Yeah, so they're still both computers, but if you wanted to run a game on the computer that for example just wasn't really built for gaming, it probably wouldn't happen in some cases. Definitely wouldn't happen at all. It's a similar thing really. So
What I find a lot of the big players in Houston, when I say big players, most commonly used ones like GoDaddy for example, you'll see a BOG standard server that goes for maybe four pounds a month or something like that, but then because it's a word pressed managed server, they charge more for it because they know most people will use WordPress, but even though on the standard one they're probably ever going to get, people won't understand that. You can still use WordPress with that.
It's like dark pricing models, isn't it? They lead you into certain directions.
Again, you are also paying for convenience in a lot of these cases, most of these WordPress, WordPress instals will be pre-configured and one click instal kind of thing, so you just hit the button, click buy, and then you are redirected straight to a WordPress login where you can get
Started even more convenient if you've got your domain name there as well. It's literally just a case of, okay, here's my domain name, do you want to serve with WordPress optimised server and oosh?
They're ideal for getting started with and I don't think any of us would really knock that, but when you are a larger business and you've got a lot of products for example, or if you are actually getting a lot of hits on your website, they're probably not going to work for you for very long. They are
What I mean
Quite minimal.
It's about how that scales up because you start off and you only have maybe two, three pages in three, four years time. You might have a full product range and 50 pages, do you
Know? Yeah, because that kind of sets up. Yeah, absolutely. That kind of setup's only useful for two. I can only think of two users to be honest. Like Josh says, it's not the kind of thing you're bashing. It's a good starting point, but at the same time it's useful for a blog, a small blog
Or a
Landing page, A landing page slash 3 4 5 page website really, and even then it'll probably be quite slow, but it's a starting point.
It's worth knowing that each every server that you buy as well has different levels of storage. I'm not as technically attuned with this than Josh, but they all have different storage levels.
In fairness, a lot of those basic cloud servers like your five pound a month ones will offer unlimited storage, but you're never going to use unlimited storage. Mean you if you wanted to kind of take the Mickey a little bit, but realistically you're not going to have enough stuff on there and not want to move away because the other resources are holding you back, if that makes
Sense. That's the funny thing. It's actually quite clever because if you think about it, if you needed more storage, your website absolutely wouldn't be on that server. Probably not
Unless you're using it very responsibly.
Yeah, because if your website is big enough to need that resource, really it's not going to a server that's just not going to cope, is it?
What are the other types of servers that you can get? I know you can obviously get shared like BOG standard shared server, but there's a couple of others aren't there?
I guess there's four types, isn't there really? You've got cloud servers, you've got shared servers which also crossover with cloud servers, but they're not always cloud. Then you've got VPSs and then you've got fully dedicated servers. There are others aren't there, but that fits most.
Yeah, I mean you could also talk about clustering stuff with load balances and expanding out, but realistically if you are doing that kind of stuff, you probably don't need our instructions on how to do it.
No, exactly. I think the vast majority of instals would fit into those four categories and dedicated servers like fully dedicated servers, even they're not relevant for the vast majority of businesses. They can be very expensive.
We
Need one of them. Would we?
No, no, definitely
Not. Josh would like on that. Yeah,
We could have one. I mean
Home to be fair.
Yeah, you could run one. It is just the cost of doing so doesn't really necessarily equate, I guess VPs is and cloud hosting are probably the two most common.
So we've mentioned large image files and things. What about video? I know a lot of clients have asked for videos recently from us, so what would we suggest in terms of page load speed and things like that? I'd say
It depends. Yeah. The first thing that I would suggest though, if you can help it is not directly uploading that to the server or the media library or however you want to call it. If you using a CMS and uploading it to WordPress Media Library, I wouldn't recommend doing that. If you can externally host it and pull it through, then that's better. So you could use something like, I dunno off the top of my head, Vimeo or we used one, we tried one, we used a I or io, I can't remember, but we've trialled a few, but I would lean towards trying to do it that way if you can.
I'd say that also depends. You can do that. You'll probably save a bot on storage space and things like that, but you also run the risk then of you relying on a third party and depending on how quickly they can actually serve, that file could restrict you. So if you are trying to load that in the hero section, for example on your website, you want that to be loaded as quickly as possible and if you're relying on a third party resolving, then you're relying on that before your page can load really. So if you've got it further down in the page, that probably makes a bit more sense because you can set it up to call that file when it's needed, like lazy loading, not quite lazy loading, but you click play and then it gets pulled in.
You just have to get the export of the video as low as you possibly can
With the high quality quality balance,
Get the balance right because you don't want to do export it as the 4K, you don't you want to be like seven 20 p probably even lower, do you know what I mean? And try and keep it as low as possible while still maintaining
Another tip that a lot of people overlook if you're using. So this will work in a hero section as I was saying a second ago, this maybe won't work in other areas, but I dunno, you can use your own common sense with this export with no audio. Why waste file size on audio if it's going in a section that's never going to use it. Yeah, Josh's
Top
Tip. Yeah, that's a good tip. So my answer to that, just to expand on Josh's, it depends. Nobody likes to hear it and it depends, but if answers were so easy it didn't depend
Would be your hours as well
Explaining it. Yeah, exactly. And also if it was that easy people like us wouldn't be in jobs. These things do depend. So I think the first thing you have to figure out is what is the purpose of the video? So if it is in a hero section, actually you'll get a different answer to if it's a video that's embedded in a page,
So that's going to load on page load for example. You need to be a bit more particular about how that works. As Josh said, if it's embedded into the page later down the page somewhere, so it doesn't necessarily need to load until you click it and it's sat there and then your browser starts processing it once it's clicked. So it does depend and there's a lot that goes on it. I think Josh, that's a great tip from Josh about audio. If it doesn't need audio, that saves some file size. The other way of saving file size, and we'll have all seen this before, especially in hero images, you'll go on a website and they'll have a video and it'll be on a 1 2, 3 minute loop and absolutely no one has sat there above the fold on one page just waiting for three minutes. It's not happening five seconds, 10 seconds, 20 seconds, that's fine. 2, 3, 4 minutes is just so unnecessary.
I think we've used this example before and I'd say there's probably a couple exceptions to what you've just said, and that's if you like GoPro
For
Example, and your whole thing is like video,
Is that Yeah, for sure like DJI and the drones and that kind of stuff. I think 95% of the time it probably works not to have that kind of length, but there are some occasions. So again, that just lends itself to the depends answer.
I've got another tip actually. And this one applies to images as well as video, and that's using the right formatting. So you could export your video in a multitude of different formats, but some of them will be much smaller in file size than others. H 2 65 for example, is I think it's somewhere like half the file size of H 2 64. You have to bear in mind though, H 2 65 I believe doesn't work in some browsers still unless that's been updated recently. But having a bit of knowledge about file formats, there's no idea as it is, can help you massively.
And images too PNGs for example. So PNGs can have transparent backgrounds for people listening who didn't know, the problem is not every image needs to have a transparent background. Okay, fine a logo, but Josh would argue an SVG is better, but you might have a use case on the website for an image where it needs to have a transparent background and that's fine, but if it doesn't need to do that, PNGs aren't very efficient compared to WebP JPEGs and so on. So file sizes is super important and it makes a big difference. By the way, if you have a colour rich image, A PNG could literally be 3, 4, 5 times larger than like a web P jpeg sometimes even bigger actually.
They're more suited to different applications. And if you understand what those applications are, you can easily google this information. If you understand what those applications are, you'll be able to use them a lot more effectively.
There are another tip that I would say is that you can instal plugins on your website to help with image optimization and things like that, but I tend to do it off site on my Mac. I use an app called Image Optum and that really helps just get it down and compress it while still maintaining the quality.
There's also a tiny PNG or tiny jpeg, which is a
Web
Tool. You got I want to say like 25 free image uploads a day on that. That can be a good start as well.
It's definitely worth noting before optimising the image though, to make sure that it's already the right size,
It
Is better to get the right size and optimise it and compress it than it is to compress it and then change the size.
Yeah, because realistically if you're getting a photo back from a photographer or something, it's going to be at least 6,000, 8,000 pixels wide. You're going to want to get that down to at least 1400.
Yeah. If it's from A-D-S-L-R, you're talking at least nowadays, 20 megapixels, aren't you?
Yeah, man.
And you don't need anywhere near that. You could chop that in an eighth and it would be fine for most applications on the web.
I think I uploaded a 70 mega image once. I think I did at least five. I think I would've. You wouldn't still be here. No, but back in all those days, you just telling Matt, now back in all those days, I'll have a hundred percent uploaded images that were like 10
Meg. You get videos smaller than that.
I know I would've done it. I wouldn't have optimised 'em at all. It's a bit mental.
The thing is if you don't know, you don't know.
Yeah,
Exactly. It is very easily done. We see it all the time.
If you've got a large video image and it's not above the fold, does that delay rendering at all?
It depends on size. Depends. It
Depends. So this actually brings onto a really useful tip and that's lazy loading. And for people that don't know what lazy loading is, it's anything, any assets that are above the fold. Above the fold means the first thing that you see on the website that's above where you have to scroll. So anything that's below the fold doesn't get loaded in When the page loads and as you scroll down, those things are loaded in sequentially. So your hero image might be up there and that loads in, but then anything later on gets called in afterwards and that doesn't count towards the page load time, which helps speed things up a bit. But yeah, in answer to your question about the size of them, you probably don't want 'em to be large anyway because they still need to be loaded in and it's still going to take time for that to get loaded in. So make them optimise anyway because it's good practise, but it wouldn't affect page load time.
And a note on that as well, so we're talking about load times where by default we spend most of our day at our desks and a lot of businesses do, not all of them, but a lot of them do. This gets even more important for those who might use their phone and be on say, a 4G signal or a 3G signal in an office. If you can download it, 100, 200, 500, a thousand megabytes a second. It's less important if you're on a phone and you've got a two, three megabyte speed, this especially video, that could really become quite frustrating.
That's why it's good when you run your test to do it on a worse or mid case, use it on an iPhone 12. Do you test on an iPhone 12 with or 3G I've upgraded now you have now. Yeah.
You can also, again, if you're a little bit more tech savvy and you know what? The browser console is throttle using the browser console. So you might have gigabit internet if you're looking like us, and if you do, it might be trickier to test for those lower speeds, but you can throttle in the web console and basically limit yourself to a 3G connection and see how things are performing on that. Yeah.
Just going on to a common issue that we see with clients, what would you say about
Caching? There's a few things that kind of fall into this. If you are on one of those 500 a month servers that we were on about before your shared hosting thing, they might come with a pretty basic cache just out of the box and usually pre-configured and they can work. Okay. In some cases, you tend to find though that more specialist caching software tends to work a little bit better. It can vary massively depending on what your server is like, who it's provided by and what kind of features they're running. But a lot of the options that you have will allow you to configure it in a way that you, nine times out of 10 going to get much better performance using something a bit more specialist.
I think it's probably for those listening who don't necessarily understand caching, there are different types of caching. So you've got server side caching, which is the responsibility of the server, and what it does is it stores frequently loaded pages files ready to serve basically, so it doesn't have to go and fetch it all the time, but then you've got your own computer slash browser based caching. So if someone's using Chrome and they've already visited a website, Chrome might save some of those <
p>resources. So next time you visit, it loads quicker. So if, obviously here we're mostly talking about the server side caching, but that also is quite a complex thing because again, there's compatibility, compatibility with plugins, with extensions, with cms, with servers, with the technology,
With code. Even one of the biggest issues you'll probably find when you're setting something like this up is the plugins that you have or the theme that you have might just completely stop working with certain settings applied. And it can be a bit of a nightmare to debug though sometimes figuring out what does work and what causes problems.
That in itself is a service. It's a service in itself for speed optimization. Caching plays a big part of that, but the setup is very meticulous. You have to make small changes, lots of testing, then small changes, then lots of testing. Sometimes you have to take a step back and go again, it can be quite time consuming.
There's also one thing that often gets overlooked is cing database queries. So on WordPress for example, when you are looking for pages or product information or things like that, your database is being queried each time. I'm not going to get too technical with this, but basically information needs to be retrieved. Those queries are searching first off, and so you can cache those searches and the results that they bring back so that when those searches are made again often in the near future, then they're able to be served a lot quicker. So for example, on a product page on the website, and it's just pulled back a load of details about that product, like variables and things like that, you go away a few pages and then you end up coming back to that product because you found it interesting. That query doesn't have to be run on the database again. It's already sat there just in the cache waiting to be served straight away.
What would we say then are the best tools for measuring website load speed?
My first one would be, well Google have one called Google Page Speed Insights
Used to be called Lighthouse.
Yeah, so that's one. If you want to just test how efficient or fast or quick your site is at loading. And that's one. There's also one called GT Metrics, which is good, and you can test that on like an iPhone 12 with 3G as well. So you're testing the mobile page load. But yeah, there's two from me.
Pingdom is okay as well. Pingdom iss not bad, and I usually jump between GT Metrics and Pingdom, but we don't have a paid account at Pingdom. We do at GT Metrics, I'd probably use that slightly more. And the main reason for that is it's probably slightly quicker and easy to use, but they both do the same job effectively.
You can also get a lot of valuable information from the developer console. Again,
Like
Right click inspect, if people don't know where the developer console is on pretty much any browser, you can see all the network requests for example, and specifically what files and things are taking a long time to resolve in a long time to actually get on your website. Usually image files and big things like that. But occasionally you'll find things like JavaScript files, which are maybe hosted externally on third parties, HubSpot for example, and others, not to name a shame, but yeah, you can track down things like that that are slowing things down very easily from there.
That's why I quite like the waterfall view in GT metrics. So again, for listeners, what you can do is as you are checking your website speed, you can literally see each file that's loading the order they're loading in, but also how long each file is taking to load. If we were talking earlier about resources that are loaded from other servers, it's quite frequent. You'll see actually probably quite a small JavaScript file, but take longer than files that are much larger just because you are not in control of how that's loaded. So the Waterfall feature is really useful to see what's slowing things down.
And then finally, obviously if you're wanting to optimise your images before you upload them, you've got Image Optum, which is a Mac desktop app, and obviously Josh mentioned Tiny PNG. Are there any for Windows?
There will be. I don't know. I can't think of
Any off the top of my head.
Yeah, it's been a while since I've used Windows.
I'm not too sure personally, I just use WebOps to do it. Tiny PNGs much
Easier. If you're not a Mac user, then just don't buy Windows.
If you're not a Mac user, buy one. Use
Linux. Sorry. Yeah, well if you're not a Mac user, then just buy one, but if not, then use tiny PNG.
I was also going to say as well, if you just want a quick visual snapshot, search console console is pretty good for cowe vital image on there,
And that's based on real life crawl data as well, which is always useful. So yeah, absolutely. Nice.
By the way, we haven't even mentioned an example of what we did with the site when we took it from one server to another
Cloud tech. Could you use
That example and the speed differences? So we
Had, when you take this seriously, you can really achieve things.
Yeah,
You really can.
We upgraded the server for a client of ours called Cloud Tech, and they're an IT company, so they're very techy like us, and we upgraded their server and I can't think the stats off the top of my head, you guys might be able to help, but we took them from a standard server to A VPS, I believe.
I think their average load times were between eight and 12 seconds.
That's quite long.
It took way too long. Yeah, way too long. When we moved, the average was N 0.5 to N 0.7
Seconds. That's mental
Huge. It wasn't just a survey, it was a server that played a big part, but Josh also spent quite a long time optimising everything from caching to so many things. Actually, hundreds of things.
Just goes to show though, with a lot of effort that you put into it that you can get those kind of changes
And coming back to the main point that has a huge impact on conversion
Rates. Yeah, huge.
It's literally generating you more revenue, more inquiries. If you have the volume, it's absolutely worthwhile doing. In fact, I wouldn't say it's worthwhile doing. I'd say if you have the volume, it's actually very wasteful, not optimising for speed. You're just literally leaving money on the table. Nice.
That's all for today. Thanks to the ML team for sharing their expertise on slow running websites and how to optimise them for speed. Tune in next time. For our season finale, we discuss the team's predictions for digital marketing trends in 2025. See you soon.
Bye.