7 Things Google PageSpeed Insights Doesn’t Tell You
View the original article published here.
Google PageSpeed Insights is a fantastic free resource for being able to understand how your website is optimised for speed. However, the biggest flaw with the tool and others like it face, they don’t take context in consideration.
One of the beginners mistakes in conducting a Site Speed audit is first not understanding the actual architecture of the website in question.
Understanding who built the website, the platform it uses and the unique challenges it holds allows you to conduct a site speed audit in a much smarter fashion. For example, avoiding situations like telling your development team for the 5th time they should use Image Sprites despite your server actually being on HTTP/2 which theoretically makes their existence redundant.
The aim of this post is to run you through 7 common speed tactics suggested by Google PageSpeed Insights and help you put them into context or action – as again the tool doesn’t offer much guidance by way of implementation.
It’s perfectly sound advice, however front-end developers are increasingly using open-source, externally hosted libraries and templates to ensure modern web standards and of course, to make their coding life a little easier.
- CSS: Bootstrap, Google Web Fonts
I would recommend avoiding combining these files. It’s a smarter practice to keep them externally hosted and allow your developers and users to benefit from the latest codebases – whether it’s security or code efficiencies.
Outside of Google, Kangax has developed a HTML Minifier that can be found on Github and for smaller scale sites Minifier.org you can simple copy, paste and convert your CSS / JS code on the fly.
6 – Compress Your Images
“Your images aren’t compressed” said every site speed audit ever written by an SEO consultant. Image optimisation can lead to both the quickest wins and gains in site load time, however it is again a job that can be hard to tackle at scale.
Google (surprise) has recently started advocating it’s open-source lossless image format WebP as a potential solution. According to their own data, the WebP format is often upto 26% smaller than PNG files and delivers even better results of upto 34% smaller for JPEGs. WebP is already natively supported in Google Chrome and the Opera browser, offers a number of utilities to automate the conversion of existing image libraries and there is even a photoshop plugin.
7 – Serving Scaled Images Could Save KiB
Image Credit: Tay Benlor
TL;DC – Google Page Insights doesn’t account for retina-display compatible images served at an appropriate scale.
Following on from the above, Images served on webpages are quite often served at a different height and width than the raw file itself. For example, a file called logo.png published on ilovetowinlinks.com might be 660 x 330 pixels but only served at 120 x 110 pixels – so the real image is bigger than what a user actually sees.
Of course, this can be wasteful and is a poor practice when it comes to image compression. However, ever since the introduction of iPhone 4 and it’s accompanying MacBook Pro with Retina Display, the concept of ‘Retina’ images is an increasing trend.
Computer displays that can serve upto 2 x more pixels per inch, require a higher quality of image to keep it crisp. There are two solutions for this that are widely accepted – use vector images or SVG files where possible, or alternatively create an image at 200 x 200 pixels and use CSS to only display at 100 x 100 pixels. Google PageSpeed Insights doesn’t account for this widely used solution to serve higher resolution images.
Bonus – Things You Can Ignore Thanks to HTTP/2
Overwhelming, the majority of site speed tactics that have been advocated over the years exist due to the limitations of the HTTP/1 protocol. Last year, I published an in-depth guide to HTTP/2 advocating every single brand to start using it. As of writing, still only 12% of websites utilise HTTP/2.
As touched upon in that guide, there are additional common PageSpeed Insight suggestions that can be ignored as they are effectively eliminated when you have HTTP/2 in place. This includes creating Image Sprites, Domain Sharding and combining CSS / JS files which all exist as ways to reduce the number of browser requests, but result in resources that might not be rendered on a page a user is visiting.
I’ve love to hear about other people’s implementation strategies around site speed, especially on larger scale sites – feel free to tweet me on it.