WordPress Site Speed Test tool – Powered by AI

0:00Introducing the WP Speed Fix Site Speed Testing Tool

Hey, it's Brendan here from WP Speed Fix. I thought I would make you this video to talk through our new-ish site speed testing tool. You can access this tool at app.wpspeedfix.com or at sitespeedbot.com. We built this tool because we do a lot of WordPress speed optimization work. We've optimized over 3,000 sites now at WP Speed Fix, so we do speed stuff all day long. The team does speed stuff all day long, and we're using a lot of different tools. We're using five or six different tools to test website speed, and it was getting frustrating and time intensive. There are some great speed test tools out there in the market, but none of them really encompass everything that is important, all the important things on the modern web. So we decided to build this tool to bridge that gap.

We use this tool internally all day long, and it's available free to use out on the web. There are a couple of features, so let me talk through the basic stuff. You can test from four locations right now: Sydney, Singapore, London in the UK, and Columbus in the US. Those are tested from Amazon locations. You can run a test, and it takes 60 to 90 seconds to probe the website and get results. This is a result for this website here.

You can also get the history of tests if you use this URL, app.wpspeedfix.com/domain/whatever their domain name is. The tool stores tests for 12 months, and after 12 months it deletes the tests. So you get the list of tests run, the time and the date they were run on, the load time, the size and number of requests, and the time to first byte. You can click into the page and open up the old reports like this, so it's really handy if you're doing optimization work and you want to see how the load changes over time. So that's the basics of running the tests.

1:35Key Metrics: Page Size, Requests, Load Time and TTFB

When you run the test, it brings back a lot of different metrics. The important ones: page size, so this is how big the page was and how much stuff downloaded, in megabytes. Obviously we want that to be as small as possible. The number of requests, which is the number of files that downloaded to build that page. The total load time. This page is actually quite slow and has some issues, and I'll talk about that in a sec. It's a 13 second load time, which would be considered quite slow. Then the time to first byte. Time to first byte is how quickly the hosting responded, how quickly it sent the first byte to the browser.

When we scroll down here, the tool does a lot of interpretation. It has a lot of data, and it does some interpretation and spits back some results at you telling you what to do. You can actually click into these and get an explanation. You can see here, great, your DNS resolution time is in the 0 to 50 millisecond range, there's nothing to do here. You can actually click into that, get a drop down, and it explains in more detail about that metric. It says that ideally your DNS resolution time should be in the 20 millisecond range if you're using a good quality DNS host. We use and recommend Cloudflare. It's pretty much the fastest DNS host in the world, and you can see DNS hosting providers compared at DNSPerf.com.

Also, an important note, especially with all the metrics here: you'll see here under the "next" section that it says to run this test a couple more times from multiple locations, and if the result stays consistent then you're all okay. That's an important thing to keep in mind when you're doing speed test stuff. The speed is going to vary from location to location and time of day, so make sure you run a few different tests to get an average, because the speed will fluctuate a bit. It will fluctuate depending on the load on the hosting environment, the time of day and how busy the internet is. So don't just do one test and think that's it, you're done. Do multiple tests, because some of these might show red initially, but if you run the tests a couple of times it might have just been a one-off that was slow, or the speed might be okay and it was just an outlier. So keep that in mind.

There's a lot of stuff here. You'll see we basically have it color coded: green, yellow and red. Red is generally a problem, green is good, and yellow is something you might want to pay some attention to, it might be okay. You can see here your load time is over five seconds, you have a problem, and that's in red. This is pretty obvious, and it explains in more detail what's going on. Here, "no next-gen image file formats detected", it explains what that's about as well.

4:19The Remaining Metrics and Explanations

Now if we scroll down, here are the rest of the metrics. If we keep going down you get yes or no and you'll get the different measurements, and again some of these you can click into and get explanations. For page size, it explains page size and how to reduce it. It explains the DNS hosting speed again, and basically all those metrics you can click into and get more detail on. So that's all good there.

4:42Response Codes and Known Slow Hosts

Response codes. Generally we want to avoid any 404s, and everything here was returning a 200 OK message. A 404 means there was an error, so if you have a 404 you need to dig into that with your hosting provider. Next, when our team is doing speed work and someone asks about site speed, we always look at the host that they're on. This part of the tool isn't 100% accurate, because there are thousands of hosting providers out there, so it's not always going to return the right result. If you're using something like Cloudflare, the tool can't see past the Cloudflare server, so you can see here it just returned Cloudflare as the hosting provider.

There are some known slow hosts. I think it probably says you're not on slow hosting, there we go. If your site is using one of those hosts, it'll show in the tool, and it explains a bit more detail about some of those hosts that we would consider slow.

5:27Image Compression Test

If we go down here, the image compression test. Again this isn't 100% accurate, but it's a good guide. There are 21 images on this page, they were 600K, or 0.6 of a meg, and potentially compressing them aggressively would reduce that by 50%. That's not always doable or possible, but it's just a rough guide for how much optimization opportunity there is in your images. In this particular case there is a lot of opportunity. It's a new website, it's a photographer's website, so obviously it's going to be very image heavy.

6:15Reading the Waterfall View

Now let's look at the waterfall view. This is really important. On any speed test you need to dig into the waterfall view to see what's going on. It's not good enough to look at the raw numbers. If you saw at the top there, the load time for this page was 13 seconds, which on face value is a problem. Now if we look at the waterfall view, we want to break the site speed down into two. We want to look at stuff that's loading from WordPress and out of the hosting itself. I'm talking about WordPress here because this is a WordPress site, but the same sort of concept applies to any type of site or CMS. We look at the core of the site, so anything that's loading off the hosting, out of the CMS. We pretty much have total control over that. We can change it, optimize it, move it around, so that's easy enough to optimize. Then we look at all the third-party stuff loading off third-party sites and servers.

7:01Reading the Timeline: Core Site vs Third-Party Code

You can see the timeline across the top here in the waterfall view. In a perfect world we want the website loading under one second. That's where we're pretty much guaranteed to have that snappy, instant load feeling. So watch that 1 second mark. If I hold the mouse here and scroll down, you can see here that the site is actually loading really fast. The stuff coming out of WordPress and the hosting just crossed over the one-second mark. If I look at that, it's loading in about one and a half seconds, I think. That's the two second mark there, so one to two seconds. We have a lot of photos here, so that's what's blowing us out into the two second mark. The core of this site is actually loading in around two seconds.

If we scroll down further, there's a whole bunch of Facebook stuff loading here, and that's actually a Facebook chat widget that's blowing out the load time. You'll see this across the web: there's all sorts of third-party stuff that really blows out the load time. In this case, what we would do is move that live chat widget into Google Tag Manager and add a five second delay into it loading. That allows the website to load really quickly, and then five seconds later, once the user has been on the page for five seconds, the live chat is loaded through. That's one technique to speed up those third-party services. There are a lot of different other ones. One is just removing them entirely. Quite often a site has lots of third-party stuff installed that was used once upon a time, like heat map tracking codes, but they're not being used anymore, so it's simply just removed.

In this particular case the core of the site is loading in two-ish seconds. It's really all that live chat stuff that's blowing it out and taking several seconds to load on top of that. So that's really important: look at the waterfall view whenever you're looking at speed tests, and don't just look at the raw numbers.

8:55Content Size, Requests and Domains Breakdown

If we keep scrolling down we get a breakdown of more stuff on the site, and this can be useful. The content size by content type, you can see here, actually has a lot of JavaScript: 1.26 megs of JavaScript, which is more than 50% of the file size that was downloaded. In this case that's going to be the live chat widget from Facebook, it's going to be a lot of that. So again, if we lazy load that in Tag Manager, we eliminate that from the initial page load and the page is much lighter.

Here you get a similar breakdown, but it's the number of requests. There are 123 requests on the page, and 76 of them, nearly 62% of the requests, were the JavaScript. So again, the live chat is a problem. Then we have the requests by domain. These are all the different host names or domains or sites that stuff is loading from, so this is a really good way to dig into that core versus third-party stuff, those sorts of optimization opportunities.

You can see in this case more than 25% of the site by file size was from facebook.net and facebook.com, and 31% was loading from Facebook. That's 600 kilobytes plus another 150 or so, so that's quite a lot loading from Facebook. Again, the chat is a problem. You can see here the number of requests: 30 requests from facebook.com and 4 from Facebook on that, so that's 34 from Facebook. ManyChat is actually the chat application that's pointing through the Facebook stuff, so you can see there that's a lot.

To optimize this site, an easy way would be to compress the images, so run them through a compression plugin, and then lazy load that live chat. That would make the images much smaller and it would remove a lot of that JavaScript. You would load the JavaScript later, which doesn't really interfere with the visitor's perception of speed, because that chat widget will load in the background, whereas when it loads with the page it actually makes the page load feel much heavier and slower. Especially when the user is clicking through the site, the live chat is loading with every page. If we added a delay in there, then it's going to wait for them to sit on the page for 5 seconds before it starts loading.

So that's pretty much it. That's an overview of the tool. I hope you found this useful. I'm happy to field any questions you have. There's probably a comment section below the video, so if you need more detail or have any questions on how the tool works, I'm happy to hear it and happy to answer any questions. If you want to send us an email, head over to the WP Speed Fix website and send us an email through the contact form there.