Speed is money, affecting customer conversion rates, Google organic search results, ads and tons of other things. This article is for frontend developers and customers with tech-knowledge, who want to know what it takes to get sites to score 100/100 on Google PageSpeed Insigts. Here is my opinion on chasing this 100/100 PageSpeed grade from Google.
Google PageSpeed Insigts on “Rooty on Speed”, an online store adapted for PageSpeed.
What’s up with Google PageSpeed Insights?
To be honest, I am not fan of Google PageSpeed. For a start, it focuses on a grade and some very specific factors, instead of the total load time of the website. Which means that 2 websites that are coded the same way, can score the exact same grade, but have a very different load time because of the data and the amount of resources used on the website. This forces the customers focus on the grade rather than load time and the benefit/cost of changing things. And on top of that, it gives very bad grades for using tracking tools such as: Google Analytics tracking (or similar tracking tools), which all serious online stores use today. Which makes the 100/100 grade almost impossible to reach. I prefer Pingdom or WebPageTest, which I think you should try as a “second opinion”.
But for customers, it has become “The“ standard for checking the speed of a website and beyond that point, it gets very technical and hard to understand for people without tech-knowledge. Which is a pity, since many of the bad scores are generated by the content creators themselves.
So – to sum it up, I will recommend looking into solving the warnings that Google PageSpeed generates. But I will not recommend chasing 100/100. Instead accept that all warnings are not worth solving, while thinking of the cost and what is a realistic goal to attain. Remember to also use other tools and compare your load time and score with competitors.
The Google PageSpeed warnings one by one…
I have described the warnings and their influence on the PageSpeed score below.
Google wants you to load these resources asynchronously, to not block the loading of the page. We have therefore put the app.js in the bottom of the BODY. But for CSS, this is not a good option. We believe that a more standardized solution for loading CSS resources asynchronously will be made available in the near future. But as a theme developer, there are work-arounds.
Leverage Browser Caching
Ironically, your site gets this penalty if you use external scripts like Google Analytics. Which means on a modern website today, it is hard to prevent this penalty.
For a start, it’s important to understand that these external scripts should be minimized. It’s therefore important to check which ones are included, and consider if they are worth it.
From there, you only have 2 ways to fix this issue, since the scripts are loaded externally, and cannot be controlled by SmartWeb:
- Remove them – or as many of them as you can.
- Host it locally, and control the cache headers yourself. It’s not a painless process, since you also need to update the script to get the newest updates from ex. Google Analytics. It will require setting up a cronjob, which needs to be set up on an external server, since SmartWeb does not support that functionality. For Google Analytics you can see the process here.
From my perspective, you need to accept this warning. Until new web standards can solve this issue.
Prioritize Visible Content
This warning is about the structure of the web page – the code. Google wants the above-the-fold content in the top of the HTML document, so that it will be loaded and shown to the user first.
Also read the guidelines about this topic from Google:
This one is for the content creator. They need to consider the balance between the quality of the images in relation to the compression rate. Your images will not look as good as they could, if you want to please Google. Remember to always use JPG images.
To solve this warning, you need to do 2 things:
- For thumbnails that are generated by SmartWeb, it’s possible to change the quality through the Design Manager > Settings on your active theme(s) > Thumbnail Quality. After this, you need to delete all thumbnails through settings in Control panel. In our tests, 85 % quality seems to be right.
- For all other images, ex. inserted directly in content, you need to optimize them yourself. There are many services and software solutions for this. A popular one is the payed solution; Kraken.io. It can handle many images at the same time, but also costs a fee. Another option is Optimizilla.
Improve Server Response Time
This warning appears, if the server-load of the page is above 200 milliseconds. To be sure it was not a spike, you need to run the test a couple of times.
Our standard themes load in about 70-150 milliseconds. But with more data in the store and more features added, it will get slower. We are constantly improving the load time of SmartWeb, but it is impossible to be fast in all scenarios. Which is why we offer caching on Smarty level. A good place to start with Smarty caching is on general things in the theme like:
- Dynamic theme content in boxes, footer etc.
- In general content or elements that are repeated on each page.
Rooty on Speed – what we did
To show that it is possible to get 100/100 score, we made this showcase online store:
Page Speed link: https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Frooty-on-speed.smartweb.io%2F&tab=mobile
Online Store link: http://rooty-on-speed.smartweb.io/
We did the following changes to the Rooty theme:
- Image optimization - optimize all images with Optimizilla.
- Move CSS – to solve the render blocking CSS files, we moved them to bottom of BODY.
Be aware of, that we did not inline CSS on this showcase, which makes FOUC still a problem in some browsers. Look up in the article regarding this.