Dont Associate Load Speed with a Green Score
Page speed tests are being misused by agencies and business owners since a little bit of pressure from the worlds leading search engine sparked some fear into the people.
We find it a little bit funny that the main offenders that slow down a website page load speed are in fact Google properties and code snippets.
This is especially true for digital marketers who may have tested their site using a few page speed benchmark platforms. Google is the most prominent of them all and this is simply their means to encourage the creation of high-performance websites.
Getting a low score in these tests shouldn’t keep you up all night and shouldn’t be the number one basis for your site’s wellbeing.
Google PageSpeed Insights tool is the most brutal reporting tool we have come across yet. Mobile and desktop scores are really in essence just scores and not the end of the world.
When we dug down into the nitty gritty of why we were seeing so many poor scores using this Google supported tool we found the following very interesting:
- Google uses a suboptimal testing environment for each test submitted.
- Tests run use a very low CPU bandwidth per test.
- We estimate tests running on 1.7mb per seconds. This is very poor.
Any business offering a free to use tool will make sure that there are some limitations on bandwidth and resources used when operating the tool and especially at the scale the Google page speed test tool runs.
We took the time to debug several of the leading page load speed tools to see how each one measured the same set of test sites and we found some very interesting data.
Page load speed shouldn’t be a universal solution and here are several reasons why.
These Tests are for Developers
One thing to note is that these page speed insight tests are tools made for developers and programmers. This means that they are not intended to be used by just about anyone that does not speak code. Although any individual can read through the reported documentation, not everyone has the technical know-how to make sense of it all. We have heard some very silly claims and seen some absolute shockers of results from developers/agencies taking the auto-generated report and working to fix problem A, B and C without actually looking up and assessing the real-world impact of a 2.7 second load time.
Professional web developers know which metrics are important and which ones they can safely ignore. Users may leave if a page loads in 3+ seconds but in situations where they need that information this can be an ok score, if users are visiting an interactive page we found the average time before people leave that page is 8 seconds. Thats just some background to help understand auto-generated tests don’t take into account real-world factors.
If you’re qualified to read a speed test, you’d be able to answer the following questions:
- What is a TTFB?
- What is first paint?
- Which items are crucial on the waterfall?
- How would you know if a CDN is helping or hurting asset loads?
- What is HTTP/2 and what is its main benefit?
- How far should the speed test server be from your web server?
If you’re unable to provide a solid answer for these questions, then you’re simply not ready to tackle a speed test yourself. The best advice is to get help from experts who are familiar with page speed insights. We can help you with a full page load speed analysis and help correct any sub-optimal results with our internal development team.
How Do We Measure Up?
Below is our page load speed test result. Its actually not as bad as it looks considering the amount of marketing functions, conversion tracking and Google properties that we are using to present the website we look pretty good. Getting a Green A score is nice for the ego but non essential to operate online and still make sales.
Speed Tests Lean Towards Optimising for Scores Rather Than Users
Working on page speed makes it very easy to fall into the trap of optimising a website for speed scores instead of doing it for the users. In terms of digital marketing, it’s similar to writing content for SEO purposes than writing for human beings. One would think both can be achieved equally but that’s rarely true. The same is true when it comes to page speed tests and user experience. What a speed test crawler may find “fast” may not be the same for an actual person.
The simple fact here is that when you optimise for users, you’re doing it to deliver the intended experience in the quickest load time possible. Whereas when you optimise for speed tests, you often do it with as little assets as possible to get the fastest load results.
And this is where the tricky part comes in. You see, you need certain assets to be available in order to create a specific user experience and automated tests aren’t that advanced to recognise them. They will simply recommend you to reduce as many bytes as possible to make way for performance. These tools rarely are capable of accounting for things that affect direct user experience.
Speed Testing Doesn’t Account for Certain Website Needs
Consider for instance two people both carrying heavy backpacks. One of them has a bag that weighs 10lbs while the other has 50lbs. Is the second person really carrying too much? What if the first individual had to walk 10 kilometres while the second only had to go to his friend next door?
The same can be said for page speed tests. If the results come up with your site’s images being too heavy compared to another website, is that really bad right away? It depends. For e-commerce shops or image portfolios, you need to have images that are of high quality. For small blogs then maybe smaller photos would be ideal.
An automated tool doesn’t see things this way when it lacks the perspective to judge what a site is and how it’s unique from others. These applications look at websites equally and scan them according to a set standard. The main point here is that something that might be considered “negative” for one website may actually be “ideal” for another.
Speed Tests Are Faulty
Page speed tests are faulty and a lot of people aren’t aware of this. These tools make people feel bad about their website on certain aspects they shouldn’t change. A couple of examples include:
Obsolete Recommendations – many page speed tests fail to account for modern web server technologies. These can come in the form of GZIP recommendations when Brotli is already used or reducing HTTP requests when HTTP/2 is already present.
Third Party Request Penalties – speed tests still highlight things such as the slow load time for external requests. Such items are acquired from a different server which is something the user doesn’t control.
Page Speed Tests Fail Eye Testing
Eye tests are basically a way for a person to judge if a website is ideal by how visually fast it loads up. If it does, then there shouldn’t be anything to worry about since the things that load up in the background don’t affect the user experience. Eye testing should be the first way to test how fast a page loads as it is the closest to real world times as possible.
For people who aren’t well versed in using these platforms as they lack the knowledge of being a developer or programmer, you might as well forget about them. It doesn’t help to try chasing a score that doesn’t actually matter. What you can do instead is to focus on making your website load up as fast as possible visually while giving a great experience to your users.
We do provide a page load speed optimisation service and you can order these by clicking on the get started buttons. This works to improve page load speed for most users but in some cases we just dont have access or a magic paint of coat to help old buggy and chunky sites. But we can help you just contact us for more information.