7 Things Google PageSpeed Insights Doesn’t Tell You

View the original article published here

7 Things PageSpeed Insights Doesn't Tell You

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 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.

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.

poly background

Get a monthly roundup of our insights in your inbox

Comments

Latest Blog Posts

Why We Do Kaizen Skooling Sessions

For content marketing specialists, speaking at events is an opportunity to share our knowledge and overcome those public speaking jitters. Back in March, we gave each member of Kaizen, who had yet to speak publicly, the opportunity to conduct a Lightning Talk in the Pecha Kucha (PKN) style. “PechaKucha (Japanese: ぺちゃくちゃ, IPA: [petɕa kɯ̥tɕa],[1]chit-chat) is […]

Destination Imagination: A Behind-The-Scenes Look at Transforming Kids Drawings to a 3D Visualisation

Recently, we released a campaign where we tackle the design challenges of bringing kids drawings to life in a 3D world. How did we achieve this? If this question sparks your curiosity, then here we will have a peek into how we managed to pull it off! After collecting the kids’ drawings from Ardleigh Green […]

Anger and Engagement – The Currency of the Attention Economy

How playing with fire can make or break your campaign On the 10th of March, 1977, the Sex Pistols staged their signing to A & M records a few hundred feet before the gates of Buckingham Palace. Their already palpable notoriety had reached a form of zenith, with the pure indignation they provoked only lifting […]