The speed at which your site loads, (or page speed) has been considered one of the more important ranking factors in Google for some time already. With Google’s focus on the user experience, a fast site is seen as being more user friendly, and therefore more deserving of a higher ranking.
To help website owners and developers achieve the best possible speeds, Google makes one of their own tools available. This is PageSpeed Insights, and anybody can run their site through it to get some suggestions on how to make their site load faster.
Page Speed Suggestions
Google’s tool suggests doing things like compressing your images and JavaScript, leveraging browser caching to reduce how much needs to be downloaded each time, minifying things like your CSS, etc.
As part of our efforts to ensure the best user experience, and the closest possible adherence to agreed on best practice, we naturally want to make sure our sites loaded as quickly as possible. But we just couldn’t get a perfect score, and as far as we could see, it was Google’s fault.
So we set up a test with a simple page so we could eliminate the variables involved in a normal site. And what we found out was that Google wasn’t following its own advice.
Best Practices
One of the best practices that Google suggests is using the Google Tag Manager (GTM) to manage any codes that your site uses, such as Google Analytics, or Remarketing codes.
There’s only one problem: You can’t cache the GTM code, or the Analytics code. And that means you can’t get a perfect score on PageSpeed Insights.
Before GTM: Desktop & Mobile
We set up this page without the GTM code. As you can see from the image to the right, we’ve got a score of 100/100 for desktop.
We ticked every box that the PageSpeed Insights tool recommended. We have no landing page redirects, and no render-blocking resources above the fold. Compression and browser caching are both enabled.
CSS, HTML and JavaScript is minified, images are optimised, visible content is prioritised and our server response time has been reduced.
As one would expect, we achieved exactly the same result for the mobile PageSpeed test, scoring 100/100 on the same basis as for the desktop test.
But there’s one essential component of a website missing from the page at this stage. We haven’t yet inserted the Google Analytics code. And it’s no exaggeration to say that Analytics is an essential component of any website. Granted, it’s possible to use other 3rd party tools which perform the same function, but Analytics is free and ubiquitous.
So let’s add in Google Tag Manager.
After GTM: Desktop & Mobile
As you can see from the image on the right, as soon as we added Google Tag Manager to the site, and put our Analytics code in it, our score dropped from 100/100 to a mere 98/100.
Now 98/100 is still pretty good. But it’s not perfect. And there is no way that we can make it perfect either, since the GTM code, like the Analytics code, is controlled by Google.
As you can see in the image, Google’s PageSpeed Insights tool is telling us that we should consider fixing this by implementing browser caching. But the GA code can’t be cached, because it’s something external.
Now, there are ways around it. It’s possible to store the Analytics JS locally, and then update its contents with a chron job or something similar, either manually or automatically.
But Google recommends against storing it locally for various reasons, mostly of accuracy.
There are also filters that allow you to run Analytics asynchronously, but that type of filter is experimental, and sometimes classified as a risk.
So as things stand, it’s impossible to get the maximum score for page speed in Google’s own tool for helping you speed up your site, if you use Google’s tools for analysing your site.
It’s not a serious shortcoming, but is it too much to ask that Google make allowances for their own code?