PageSpeed is dead

If you are like most shop owners or webmasters you have run the Google PageSpeed tool against your site. Sometimes the results are great, other times they are pretty dismal. Still developers are trying to appease the tool to get higher scores. In reality the scores that PageSpeed puts out are a bad metric to judge the speed of your site with. Let me show you why.

Breakdown of a PageSpeed score

The PageSpeed score is broken into two sections. The top section is what optimizations your site needs, and the bottom is the optimizations that have been found on your site already. Seems pretty straightforward doesn’t it?

Looking at that score, it looks like things need work. You can see there is render blocking Javascript and CSS, the server response time does not seem to be that good, it gets flagged for it, the images could use some optimization, and the HTML needs to be minimized. Not a terribly bad score, but not that great of a score either.

Now let us look at a Shopify theme and see how it scores. The image below is the scoring for the Shopify theme Debut.

You can see with the Shopify demo it finds the same flaws as it did with ours, but they are a little worse which lowers the score. Well, there is one difference actually, the prioritization of visual content has been added in their test, and the reducing server response time has been removed.

With thirty bees and Shopify down, let us have a look at how the new PrestaShop 1.7 theme fares on the page speed test.

PrestaShop 1.7 fares about the same as thirty bees does on the PageSpeed test, only a couple of points lower than thirty bees. The test still picks up many of the same things that the other two tests do as well.

So who wins?

No one wins this test. The PageSpeed test uses methods that are not based around meaningful metrics to users or site owners. Looking at the tests in further detail you can start to see. All of the three sites were hit because of the render blocking CSS and Javascript. What does that mean exactly though?

The idea behind the render blocking CSS and Javascript is pretty simple. CSS stands for cascading style sheets, it loads in a cascading downward manner. So say you have a menu height set on line 100 of a style sheet and then on line 900 you set the height to something else. The browser will first load the menu at the height set on line 100, then it will update the height to what is set on line 900. This is called a repaint. Render blocking CSS in Google PageSpeed actually does not take this into account. What it takes into account is the size of the CSS files, not how optimized the CSS files themselves are. The initial view of the site could be loaded in the first 100 lines of the CSS file, and paint almost instantly, but PageSpeed would still ding your score if the file was too big.

At the same time, image optimization was dinged on all sites as well. What does that mean though? Is it really viable to site performance? I think on some levels it can be, but on others it is just a meaningless metric. The Shopify demo site shows that the images can be compressed to lose 66kb of data. Do we know if the compression metric they are using accounts for artifacting? You could very well reduce the sizes of the images by having a poorer image quality. This is not a good practice for anyone though. Also, what is 66kb of data? I had to actually break out a calculator for this one, but to download 66kb of data using a 10mbs connection will take you .05 seconds. If the Shopify theme had better image optimization it would speed the site download up by 1/20th of a second. For the effort that optimization does not seem worth it to me, but it reflects heavily in the score.

Some of the other dings the tests picked up were to minify the HTML and the Javascript. These, like the images, will help a site load literally fractions of second better. Going back to the Shopify theme, the PageSpeed test picked up 6kb of compression that could be saved on the Javascript files. This would result in a 1/200th of a second speed increase for the site. Not ideal for the amount of work it might entail.

Poor metrics like these is why PageSpeed is a doomed metric that is soon being replaced. It was a good idea at one time to help developers by nudging them into the best practices, but now the results that are flagged on most sites are antiquated.

More meaningful metrics

There are more meaningful metrics out, and it looks like Google themselves are pushing for them. Since the PageSpeed metric is only high level metric that has a tendency to be wrong, its no wonder that Google has already started phasing it out in favor of metrics that can better help developers create faster loading websites.

If you are not familiar with it, there is a tool called Lighthouse. It is a Google sponsored project, you can read more about it here. Lighthouse gives a view of performance that Google PageSpeed could never give. It does not rely on metrics of arbitrary values, it relies on the one metric that your users notice. How long does it take to load a page. With Google PageSpeed it is possible to have a page that takes 5 seconds to load and to score a 90. It is also possible to have a site that loads in .8 seconds and scores in the 60’s. With our tests earlier, here is a Pingdom time score of each site.

thirty bees

Shopify

Prestashop

Looking at the pure load time scores above thirty bees wins. Shopify gets second place, and PrestaShop third place. But remember the PageSpeed score? PrestaShop beat Shopify by 6 points in that score. If you were a site owner would you want a 6 points better score or a site that loaded 1.2 seconds faster than your competition? I think most site owners given the choice would not care about the score and would like the faster site. This is something that Pingdom can show you, but it also exposes a weakness in Pingdom as well.

The timing from Pingdom is the just the time it takes to download all files associated with your site. Nothing more, just the straight download time. It does not mean the metric is not useful, because it is, but it is not perfect. One huge factor that Pingdom misses in the equation is rendering. When is your site rendered where people can use it? does it matter if something at the footer takes 5 seconds to load, if the browsing user never realizes it?

Lighthouse

This is exactly what Lighthouse takes into account. How long it takes a mobile user to be able to use your site. Since mobile traffic is over 50% of the web traffic and most mobile optimization practices work for desktop as well, this is the best approach. It is what I would call a real world approach to the speed of sites. It measures exactly what matters to your users, how long it takes your site to load on their device.

Let’s look at the three demo site’s results that have been run through the Lighthouse test, the testing metrics and the results are very different than the other two tests we have looked at. Also, one thing to note about the Lighthouse metric is they test things such as your site being a progressive web application, accessibility for disabled people, and for best practices in terms of development. Below are the three demo sites run through Lighthouse.

thirty bees

Shopify

PrestaShop

These results are very different from the results that either of the two previous tests had. One thing I will say, about the metrics, with these three demo sites, the Progressive Web App test does not matter. None of the sites are progressive applications. The main test we are focusing on is the performance test. But why are they so different from the other tests? thirty bees and Shopify loaded in close to the same amount of time, yet there is a big difference in the testing results. If we scroll down on the test to the performance section we can see a bit better. Below are the breakdowns of the three tests.

thirty bees

Shopify

PrestaShop

Looking at the break down of the three tests we can see where the emphasis is placed. The tests are testing the rendering time of the pages. This is what users notice. They do not notice the cache life you have for a font, they do not notice that you can optimize an image and reduce 6kb of data. They notice how long your web page takes to render on their device. And if it takes too long, they leave. It is actually pretty cut and dry.

Examining these tests actually provide somewhat of surprising results. Prestashop beat Shopify in the PageSpeed test by 6 points. But looking at the Lighthouse tests we can see that it takes over 2 seconds longer than Shopify to render the first meaningful paint. As a side note, a meaningful paint is the rendering of the page and all the elements on it, where a user can tell what your page structure is and start looking for information on the page. The first meaningful paint is the key metric. That is why we have tuned thirty bees around having a low paint time. This reduces the bounce rate, while at the same time it leaves users with a feeling of responsiveness and snappiness while on your website. What would you rather have? A better PageSpeed score, or would you rather have a site like the thirty bees demo that is fully rendered and ready for input before the PrestaShop site has even rendered in the browser?

Using Lighthouse

To use Lighthouse is simple. If you are using Chrome 60 or above, you can right click on a page and select Inspect Element. Then click on the Audits tab and you will be able to perform an audit on the page with Lighthouse.

If you are not using Chrome 60 yet, you can download the Lighthouse extension from the Chrome App Store here.

Hopefully now you can see why PageSpeed is a meaningless metric and is not long for the development world. Like everything else about development, times change, the tools change, and better practices come into play. If you have questions or comments we would love to hear them, just comment below, let us know what you think.