Before optimizing your site, it’s important to get a baseline for where you are starting. Otherwise, you can’t accurately monitor your progress.
We see many running website speed tests the wrong way. When doing so, it might appear that your website is slowing down, but really, it’s just a matter of better understanding how to use the tools. We know it can be confusing, so hopefully, some of these tips below will help.
Speed test tools
Below are some of our favorite tools we use in our daily workflow to run website speed tests.
- GTmetrix: Excellent waterfall analysis and graphs for the total page size and page requests. For example, see the % of how many images or JS make up the total page size. Focus your optimization efforts on the biggest size first.
- WebPageTest: Very similar to GTmetrix in terms of a waterfall analysis. One huge advantage is that you get up to 150 free tests per month. It also has an option to do 3 runs per test, so you can see the average of your data.
- DebugBear: A great way to find your LCP element, what is preloaded and fetched, and probably the best tool for debugging CLS (screenshots and throttled video).
- Yellow Lab Tools: See how much of your font libraries (Font Awesome) are actually used, if you have multiple jQuery versions loading, etc.
- HTML Size Analyzer: Quick way to spot your biggest blocks of inline code and see how much they add to your total HTML page size. Simply inlining everything is bad for FCP and LCP.
- Speed Vitals and Performance Test: Measure your TTFB from different locations at once. A good way to measure the positive impact of Cloudflare edge cache.
Tips when speed testing
When you run a website speed test, make sure you always test the full and final URL. Accidentally testing a redirect (e.g., www when it’s a non-www site, or vice versa) will skew the server response time (TTFB), because it includes the redirect time.
Your indexed links in Google and URLs you share on social should match the final URL. Or rather, users in real-life should never experience your redirect; therefore, you don’t want to measure that overhead.
It’s also important to test your website in its final form. For example, testing your staging or local site might behave worse than your production site, since you probably have features disabled, like page cache and your CDN (Cloudflare). And that’s not what real-users will actually experience. It’s fine to test these environments, as long as you keep that in mind. But for most, it’s usually better to run speed tests with everything enabled.
Checking your speed test data
In these examples below, we are using GTmetrix.
If you see long delays like this below it might mean that you’ve made changes to your site recently and the cache on your site has been invalidated or expired.
You can check the header of the request to verify it.
Click on the request itself and under the “Headers” tab look for anything related to cache status. This will vary a bit based on your hosting provider or CDN. In this example, you can see cf-cache-status . This is a header coming from Cloudflare. You see that the value is EXPIRED . This means the cache needs to properly build back up. Until then, the long delays will occur and make it look like your website is slower.
What can you do?
Whenever you make big changes to your website, especially when doing performance optimization, you need to run a website speed test multiple times. Three times is generally a good number. This will ensure all of your assets cache again. This is also reflective of what visitors will typically see when they visit your site.
Below is an example of the same request after it’s serving from cache. The cache header value now shows HIT. And as you can see, the time for the request dropped significantly.
The same also applies to other speed testing tools such as PageSpeed Insights. If you don’t run a speed test multiple times, you might get a “Reduce initial server response time” warning.
