WordPress Site Speed Test tool

We’re not using Google Pagespeed Insights or Lighthouse engine

You might have noticed when you search Google for site speed test tools that they all roughy look the same with the same recommendations. Our tool is different. Unlike most of the other WordPress site speed tools ours does not rely on the Google Pagespeed Insights Lighthouse engine and is specifically built for WordPress sites.

It has a basic AI engine that we built up over time providing our custom recommendations for various tools and plugins that we’ve built after optimizing 5000+ sites.

A note on information, warnings and errors in speed test tools:

Many marketers and web developers using site speed and SEO tools often take recommendations as fact but that’s a mistake. The recommendations our speed test tool and any other software you’re using like SEO audit tools needs to be interpreted in the context of your site.

Just because a tool provides a recommendation doesn’t necessarily mean you should take action. For this reason, as much as possible with SiteSpeedBot we’ve aimed to avoid things like scores and errors. 

When reviewing and digesting the recommendations from SiteSpeedBot please interpret them in the context of your site and what you’re looking to achieve. 

What Is Our Speed Test Checking For

Here’s some of the key things SiteSpeedBot checks for and why they’re important:

404 Errors

404s or file not found errors are bad for speed, they’re bad for SEO and bad for users and are problematic all round.

If we detected a file that’s 404-ing it means the server can’t find it. In some instances especially where you have a custom 404 page that’s going to add big delays into the page load and it’s going to take much longer to load.

Speed isn’t the only reason to get this resolved. You should fix broken internal links to help Google to crawl and index your site. Any broken external links should be fixed as well.

In the waterfall view towards the bottom of the speed test results you’ll be able to see files that are 404ing. The 404ing file(s) will have a red dot next to it in the waterfall view.

CLS or Cummulative Layout Shift

CLS is a Core Web Vital metric that measures how stable your site layout is while loading. This is a computed metric not a speed score. It needs to be under 0.1 in order to be considered “good” by Google.

You would experienced CLS before when you go to a site and you go to click on a link or menu item and suddenly the layout of the site shifts and your mouse is no longer in the right place, thats layout shift.

Connection Speed

We measure how quickly the browser connects to your hosting. Problems with network bandwidth or server configuration probably often manifest as high connection time and will show here. If it takes more than 100-200ms to connect to your hosting then there may be a network or web server configuration issue.

DNS Hosting Speed

We probe the speed of your DNS resolution or your DNS hosting. Nearly everything on the Internet starts with a DNS request. DNS is the Internet’s directory and if your DNS hosting is slow, your website will be slower to load.

Before a browser can load your site it needs to turn your website address into an IP address. That’s done via a DNS lookup. If you have slow DNS hosting then that can often add seconds onto your load time. If you have really bad DNS hosting then the DNS lookup may fail entirely throwing an error in the browser.

This post talks about the best DNS hosting in more detail.

Canonical SEO Tags

Canonical SEO tags are critically important for avoiding duplicate content and ensuring you don’t waste search engine crawl budget. They’re even more important in the AI era where Google and other search engine’s understanding of your content is critically important.

We check to ensure canonical tags actually exist and whether they match the URL tested.

Does your site support Next-Gen image formats?

The “weight” of size of a page is important in both the context of site speed and SEO. Generally speaking we want our pages to be as small as possible and that means we want images to be as small as possible.

Webp images are typically, but not always, small than their gif, png or jpg counterparts. 

We check for the existence of what are termed next-gen image formats, file formats like .webp and flag it as an issue if we did not detect them.

FCP Timing (Core Web Vitals)

First contentful paint or FCP is an important metric as it’s the start of the site render and is when the user sees something happening.

This timing is the data Google has on the average FCP for this page or the entire site if page level metrics are not available. The data is data pulled directly from Google’s Core Web Vitals API. A FAST score here is under 1.8 seconds

FCP time encompasses a number of elements and there are many ways to improve this metric including reducing DNS lookup time, reducing TTFB, minimizing or eliminating render blocking CSS and Javascript as well as reducing the weight or filesize of elements “above the fold” on a page by doing things like using Lazy Loading and Nextgen Image Optimization.

In most cases your FCP time should be lower than the Fully Loaded Time, if it’s not usually the culprit is excessive amounts of javascript causing high CPU usage.

This article goes into detail on how to reduce your First Contentful Paint or FCP Timing

First Input Delay (Core Web Vitals)

First Input Delay (FID) measures interactivity or how quickly the site responds to the first user input. Good is under 100ms, 100ms-300ms needs improvement and 300ms+ is not great.

Fully Loaded Time (largely deprecated)

Fully loaded time is the point where the “Onload” event fires AND there’s been no network activity for 2 seconds. Generally we don’t use this metric any longer and we recommend you don’t either.

Other metrics such as TTFB, FCP and LCP are much more important. Generally speaking you should use the LCP metric as your benchmark for speed. A fast or good LCP time is where 75% or more of your visitors have an LCP time of under 2.5 seconds 

HTML Download Time (TTFB + time to download HTML)

Here we’re measuring something we call HTML time. This is essentially your TTFB (time to first byte) AND the time required to download your HTML file combined.

Your HTML needs to download before your site will render so the faster this happens the faster the actual AND perceived load time will be for your visitor.

We measure this because poor quality or overloaded hosts will cause the HTML download time to be slow.

There are also scenarios where aggressive HTML minify can slow down HTML speed and in some cases excessive inlining of CSS and JS can cause a very large HTML file size which will make it slow to download.

If you’re using Wordpress then you pretty much MUST use a caching plugin to get reasonable time on this metric and overall good load time for your site.

WP Rocket is an excellent option here and if you’re DIY-ing or less technical will usually be the best caching plugin to use.

We often find that when people DIY their own speed optimization they blindly follow recommendations from online tools (many of these out of date) and end up generating huge HTML files that take a long time to download so this could be an issue too.

The smaller your HTML file the faster it is to download.

This article details how to improve your time to first byte and server response times.

HTML File Size

Here we’re measuring the size of your HTML file. This is really important because the HTML file needs to be both downloaded and parsed in order for your site to render.

Broadly speaking, smaller is better but over 200kb will start to be an issue for site speed and potentially SEO. 

If you’re inlining CSS, Javascript or images then typically we’d recommend only inlining very small CSS and JS snippets and letting any larger CSS and JS (say over 5-10kb) load as separate files.

HTTP/2 Push Detected? (deprecated)

HTTP/2 Push is a feature of the HTTP/2 protocol. With HTTP/2 Push in place, files and resources required to render the webpage are automatically sent to the visitor before 

they even request them.

HTTP2 has been superseded by HTTP3 and we no longer recommend HTTP2 push as other techniques like speculative loading and just in time preloading achieve better results in the context of WordPress site speed.

Is the HTTP2 protocol supported by the server?

In this test we probe your web host for HTTP2 protocol support.

HTTP 2 is a newer version of the HTTP server protocol and dramatically speeds up how quickly files are downloaded by your website visitors.

This protocol has been available since mid 2015 and by now your host should have upgraded your server to support it.

The HTTP/2 protocol and support for it supercedes older speed recommendations you’ll fine around the web such as domain sharding and parallelizing downloads across hostnames.

This video highlights the difference in speed between HTTP 1.1 and HTTP2: https://www.youtube-nocookie.com/embed/vhbYWKLMeSM

If you don’t pass the HTTP2 protocol support test you should log a support ticket with your host and ask them about it. If you get no success there then you should look elsewhere as hosting speed is likely not a priority for them.

Typically you’ll see a site load anywhere from 30-100% faster with the HTTP2 protocol in place as it speeds up how quickly browsers can connect to your hosting and download files.

If you need a standalone http2 checker try this HTTP2 Checker at SimpleUptime.co

Note that there is now also a HTTP3 protocol which is even faster again and generally will offer another 10%+ speed gain over HTTP2. Adding support for HTTP2 to a web server is much more simple than HTTP3 as HTTP3 will typically also require some firewall changes as it uses the UDP protocol vs TCP.

Is HTTPS enabled?

Your site should be running in HTTPS secure mode to ensure data between visitors and the website is encrypted while in motion. HTTPS is also required by browsers in order to use the HTTP2 and HTTP3 protocol so ensure your site loads only over HTTPS is better for security AND speed.

Note, we do not currently check for HSTS support but we do recommend your also enable HSTS headers to further increase your security and site speed.

LCP or Largest Contentful Paint Timing (Core Web Vitals)

Largest Contentful Paint (LCP) is a Google Core Web Vitals metric. It measures when the largest content element in the viewport becomes visible. Broadly you can consider it the render mostly complete and the visitor perceiving the page as having loaded. Google considers an LCP under 2.5 seconds to be fast. 

Over 4 seconds is bad. If this shows a zero there may be an error happening under the bonnet, e.g a 404 or JS error.

This article provides a detailed guide on reducing and improving your Largest Contentful Paint timing.

Last Hero Painted (deprecated)

Last Hero Painted is a render timing metric. Render metrics are important because they relate to how your visitors perceive load time and their overall user experience.

This is a synthetic metric in that it’s a close approximation of when the user will experience the render above the fold (the viewable area of the site) complete.

It goes hand in hand with the first contentful paint metric (the start of the render) and its essentially the end of the render as the user perceives it.

It’s important to note that this metric can be inaccurate if you have popups, slide-ins and other animated or moving elements that impact the render of the site or the feeling of “load complete-ness”.

This metric may also report zero if the tool had difficult rendering the site due to javascript errors or other errors that interfere with the render for example 404 errors.

You can learn more about this metric at this blog post

Is Image Lazy loading detected

In this test we’re probing for lazy load support. Lazy loading defers the load of files that sit outside the initial viewable area on your website or elements that are “below the fold”.

This speeds up the initial load of your website as there are less files to load. As the visitor scrolls down the page files and other resources are loaded as the come into view.

This optimization is particularly useful on image heavy sites, pages that are really long with a long of images and pages with a lot of embedded content like several Youtube videos.

Best Lazy Load plugin for Wordpress

If you’re using WordPress, two easy ways to implement lazy loading for images, videos and Youtube embeds and iFrames are using either WP Rocket or PerfMatters.

We use both WPRocket and PerfMatters but prefer PerfMatters. for lazy loading as it’s more Core Web Vitals friendly as it allows us to exclude the first X number of images on the page from lazy loading as we want to avoid lazy loading images (we usually set to 4 or 6 images) above the fold. We strongly recommend excluding your logo image from lazy loading as that will help improve your FCP timing too.

Read more about PerfMatters lazy loading features here.

For additional information on fixing this error and reducing page sizes see this blog post titled How To Fix The ‘Avoid Enormous Network Payload’ Warning In Google Pagespeed Insights

Document Load Time

This is the Document Complete or Window Loaded/Onload event timing. A fast site will be between 1.5-2 seconds, lightning fast under 1.5. If you have a lot of third party code like ads, affiliate code and marketing pixels, this is a better metric to focus on than Fully Loaded Time. If this shows a Zero your site probably has some sort of Javascript error happening under the bonnet.

We typically don’t use this metric any longer in our speed work and instead focus on Core Web Vitals Benchmarks and specifically LCP for the load time.

Meta Description – does it exist yes/no

In this test we’re probing for the existence of a meta description. If you’re getting an error here we couldn’t detect a meta description on this page.

High quality, well written meta descriptions are essential for SEO and in some cases a well written meta description can dramatically increase the CTR (click through rate) from Google search. If you can take the CTR from 2% to 3% with a better written meta description that’s 50% more traffic from the same rankings.

Number of CSS Files

Here we count the number of CSS files your site or page is using. CSS is required to render the page so the more lightweight and the fewer the number of CSS files you have, the faster your page will feel to visitors. This “feeling” of speed doesn’t necessarily show up in speed test tools.

CSS files need to load in order for your site to render (display to the visitor).

Generally less is better here but there is not a specific number of aim at.

Number of Javascript Files

Here we count the number of Javascript files your site or page is using as more javascript means a slower site. 

Generally you can improve how fast your site feels by moving your Javascript from the header of your site to the footer which causes it to load later in the loading and render process.

Defering or loading Javascript asynchronously can also help minimize it’s impact.

A simple action step you can take is to analyze the waterfall view below and identify any software or tools you’re not actively using and remove those from the website – often marketing and analytics tools were installed years ago and are no longer in use.

If you’re using WordPress and injecting code using plugins often you can squeeze a little more speed out of your site by implementing Google Tag Manager and using that to fire third party scripts and code.

Number of admin_ajax.php requests

This is a Wordpress focused test. Here we count the number of admin_ajax.php requests your page made. These are requests the browser makes in the background and can be simple actions like fetching the number of items in your cart or more complicated tasks like changing the page currency.

Often these requests can be quite slow and heavy so we want to minimize them where possible.

Requests made via the admin-ajax.php library are usually quite CPU intensive too so we need to be mindful of them. There isn’t a specific action item here but anything more than 1 or 2 admim_ajax means something needs to be looked at.

Number of requests for resources not on the tested domain

In this test we count the number of file requests that are not on the domain or web address you tested.

When we look at site speed we typically break the site into two:

1. Your WordPress Core and everything that comes from your hosting
   2. Third party files and resources.

We have almost 100% control over WordPress and related files so they can almost always be heavily optimized but generally only a small amount of control over third party files and resources.

We want to limit third party files and resources as much as possible as typically they’re much slower to load than files loading off our WordPress core.

Click play on the video below to learn more about this metric: https://www.youtube-nocookie.com/embed/uuKiXrTe4l8

We built this tool based on our experience optimizing thousands of WordPress websites through our speed optimization service.

The video below walks through the various features of the test tool and how to see your test history. It’s well worth a watch if you haven’t used the tool before.