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.

As an ex-front end developer myself, I can understand the rationale behind why certain decisions are made around the utilisation of HTML, CSS or Javascript that might result in PageSpeed Insights wagging it’s finger at you.

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 5^th 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.

1 & 2 – Combine CSS and Javascript Files

The logic behind this suggestion is to reduce the number of resources a users browser has to request from your websites server. The action is to reduce the number of CSS and Javascript files being loaded and combine them together.

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.

Examples:

• Javascript: Angular, React, jQuery, D3, Grunt, Gulp.
• 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.

The same logic also applies to any additional CSS or Javascript generated by CMS plugins. For example, many of the most popular WordPress, Magento and Drupal plugins have accompanying CSS/JS. If these files are manually combined, it will make automatically updating the plugin more difficult.

Lastly, I’d also leave any analytics tracking Javascript files separated. Google Analytics has a habit in particular of changing how it tracks things.

3, 4 & 5 – Minify Your CSS, HTML and Javascript Code

Minification is the process of removing unnecessary white code from CSS and Javascript files to order to marginally improve load speed. Again, it’s a valuable best practice but the challenge is scale, what do you do when you have millions of URLs?

There are a few interesting solutions for this. Google has two server-side modules that can potentially automate the minification of content. Firstly there is the PageSpeed module, which can additionally optimise images and extend browser caching (two more ticks off the list that you’re usually given when running the tool). Separately, there is the Javascript Closure Compiler that also wields the power of minification.

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.