Evaluating the performance of your own website is very easy today. One or two clicks and Google or another service spits out results with concrete suggestions for solutions. Wonderful. At least for the first optimization run. But at the latest when it comes to fine-tuning, changing hosters or cleaning out WordPress, it becomes important to understand which tools actually measure the loading time and how you can deal with this data.
Recently, a customer wrote to us via the support chat. He had just moved and compared the performance of his siteat the old hostwith his siteat Raidboxes. He told us that migrationwas not really worth it for a performance increase of only 9 points on Google PageSpeed Insights .
In fact, we get such requests all the time. That's why I took a look at what information tools like Google PageSpeed Insights actually provide for interpretation and how they measure performance or loading time. To be honest, the result surprised me a little. Because: the meaning of the values is usually explained very well and in detail. However, the help pages of the test providers do not go into detail on two points:
- Which tool is suitable for which purpose?
- What data can be interpreted and used and how?
Tools such as Google PageSpeed Insights do not measure the speed of your site
It was already discussed in an earlier blog post: tests such as Google PageSpeed Insights do not measure the loading time of your site, but its optimization potential. They determine how well your sitefulfils a predefined set of performance-relevant criteria. In addition, the tests provide instructions for optimising the performance potential. However, there is one thing such tests explicitly do not do: measure the loading time.
On Google it sounds like this:
PageSpeed Insights measures ways to increase the performance of a sitein the following respects:
- Time required to load the content visible without scrolling: Time taken from a user requesting a new site to the browser rendering the content visible without scrolling.
- Time required to fully load the site: Time taken from a user requesting a new site to the browser fully rendering the site
You see: Google does not measure speed, but the "possibilities to increase performance". A crucial difference. And that also means that you cannot read out from the results how fast the site or the area visible without scrolling actually loads.
Performance tools like PageSpeed Insights show where you can quickly gain a lot of performance.
But that is not a problem either, because the tools still provide valuable data for optimization, even if they do not measure the loading time. The statements of such tests have the greatest added value for major optimization steps, such as the use of caching or image compression.
However, as soon as it comes to optimising the loading time of an already optimised site , these tests can only provide limited insights. In such a case, you must carry out a real performance measurement. This is especially true when you change hosting providers. Because no matter how good the web server itself is, if site is full of construction sites, even a change of infrastructure is of little use.
For such a "real" performance measurement, you can use the following tools, for example:
With one of these tests, the customer would have been able to compare exactly which parts of his site had which performance gains after the change.
And that brings me to the second point of this post: Especially tools like PageSpeed Insights tempt you to use values for a comparison that are only suitable to a limited extent or not at all. Because when you work with point scores or grading systems, you quickly get into a situation that I call the school grade dilemma in this article.
The school grades dilemma: grades are not suitable for comparisons
Tools like Google PageSpeed Insights, or Yahoo's YSlow output two types of data:
- a mark for page performance
- concrete advice on how to improve this grade
The scores are on a scale from 0 to 100, with 100 being the best score. So far so clear. And intuitively accessible to every user. Especially because the ratings are supported by a traffic light system.
But when it comes to comparing two sides on the basis of these ratings, interpreting the measurement results is no longer so easy. In fact, it is incredibly difficult, if not impossible. Because everyone can see that the site with the 90 rating is better than the one with the 80 rating. But the following statement can no longer be made: By what factor is the site with the 90 rating better than the other one?
And this describes the problem at its core: Grading systems simply do not allow such statements. You know this from your school days: the person sitting next to you got a C, but you got a B yourself. Even if only one or two points separate you: The result is fundamentally different. And without knowing the grade key of the paper, it is impossible to say how close the result was.
The reason for this limited significance is the so-called scale level of the measurement data. However, I do not want to go into this in detail here. For more details on scale levels and the permissible arithmetic operations, just take a look at Wikipedia.
Back to our example from the beginning: The customer - and no other person - is able to say exactly by which factor the old and the new site differ. Only with a real speed measurement is such a statement possible.
Time measurements provide the best loading time data
The most valuable data for comparisons, the preparation of optimization measures etc. are in any case time measurements. Because these have a zero point to which one can orientate oneself. Thus, tools that measure the loading time allow all kinds of statements and comparisons.
So if you measure a page load time of 2.712 seconds before an optimization measure and a value of 2.133 seconds after the conversion, you can make the following statements based on this data:
- The site is 21 per cent faster after the changeover than before the changeover
- The optimised aspect is responsible for more than one fifth of the page performance. (one of the most important pieces of information ever!)
- All further optimization measures can be set in relation to this value. Thus, an optimization that would bring 9 per cent more speed, but would mean disproportionately more effort, can be prioritised differently than a measure that saves correspondingly more loading time.
If the client from the example case had measured from the beginning with a tool like webpagetest.org, he would have seen that the performance of his site more than doubled in the relevant areas.
Conclusion: Knowledge about the type and quality of measurement data is only the beginning
For a meaningful comparison of two or more pages, therefore, at least the following two conditions must be met:
- The tool used must measure the right things - i.e. the relevant parts of the site in each case. When changing hosters, for example, you should not rely exclusively on a test that primarily looks at onpage factors.
- The data used must allow a meaningful comparison. Normally, one would like to know by which factor an optimization has brought one's own site forward. Only with this information can you make a forecast about the improvement of the conversion rate, for example.
Admittedly: Knowing the right data is only the beginning. Of course, you also need to know how to test the page performance correctly and how to read out the data sets. That's why we'll be looking at these two topics in detail in upcoming blogposts.
However, understanding the data and the permissible conclusions that can be drawn from it is the basis for all further optimization steps. And it helps to take the right and most sensible optimization measures.
