Google PageSpeed Insights – my experience

Introduction

Alas it’s time for me to talk about Google PageSpeed and my experience. I set myself down this path after my current employer wanted to look at factors affecting SEO.

I’m not an SEO expert but as a frontend developer you’re clued up on SEO 101 – formatting html code ensuring H1, alt/title tags, microdata/rich snippets and so on are present. Apart from SEO looking good in general on the employers website, there were other causes for concern – site speed according to Pagespeed Insights.

This started when Google decided to rank fast mobile websites over slow mobile websites – more on that from the horses mouth https://webmasters.googleblog.com/2018/01/using-page-speed-in-mobile-search.html.

In a brief summary of the linked article, Google decided that a websites performance on a mobile device will affect its mobile search ranking. However that article also suggests, despite a website being slow, as long as the “search intent” is strong, the site will still probably rank high.

p.s. i’m using “websites” loosely here against individual pages – Google is ranking a particular page against a particular search query, not website. Unless I suppose you’re looking for a website? My brain hurts, I’ll leave that for the SEO experts to explain.

Why does site speed matter?

Site speed in general encompasses many things. How quickly did the server take to deliver the page? Did the content load on time? How quickly could you interact? All of these come down to something that’s been hammered by usability pros for 20 years – users want fast websites.

Given that Google decided to include site speed for mobile sites as a ranking factor (desktop sites were already ranked for speed), you may have received an email from Google webmaster tools with the subject “Mobile-first indexing enabled for <your site>”.

What is mobile-first?

Over the past 4-5 years, Google made statements to help nudge developers put emphasis on mobile-friendly websites. That morphed into a sort of “mobile-first” initiative since a majority of users browse on their smart phones these days. No surprise there either, considering Google generates tons of income from Adwords, they want to better milk their target audience (everyone searching for something on the internet).

How does mobile-first impact your site?

Read this article https://www.searchenginejournal.com/googles-mobile-first-indexing-what-it-is-how-you-can-prepare/

What does site speed mean in 2019?

When sites were browsed more often on desktop computers, the key metric for site speed was how quickly the server responded (time to first byte – ttfb) and then how quickly the content loaded. This is still relevant in 2019.

With the advent of high speed internet in early 2000 (ISDN/ADSL/Cable), I don’t recall in-depth discussions about website speed other than ttfb – the hype was around dynamic html, new technology such as Ajax and CSS styling.

To make your website fast in late 2000 you could do the following:

  • Ensure your web server response is fast (ttfb)
  • Enable compression for content sent from the server (i.e. gzip)
  • Set cache headers (i.e. static content expires late in the future)
  • Optimise your CSS and JS code (avoid lots of cascading styles and ‘slow’ or very heavy JS).
  • Dynamically load portions of the page (i.e. ajax content, lazy loading)
  • Optimise payload for HTTP 1.0 (i.e. ‘merge’ multiple CSS and JS files into one).

In essence, all the above is still relevant in 2019 and should be applied to “mobile-first” websites.

Mobile device limitations in 2019

One of the key issues with mobile devices is a hardware performance limitation – a majority of desktop computers (lets say crappy Celeron / ATOM cpu) can easily handle web pages that are quite heavy on javascript & feature content such as videos (assuming the internet speed is consistently fast at ADSL 1 speeds at least). This is where a mobile device may fall short to deliver on performance (not to mention mobile phones CPU/GPU’s running “slower” depending on battery charge or life expectancy).

Another key issue with mobile devices is internet speed. Yes, sure, we’re propelling “wireless” internet speed with the likes of 5G but lets face it, how often have you browsed the internet and the mobile device has fallen back to “slow internet” due to lack of “fast internet” reception? This impacts how fast a website loads on that not so powerful mobile device with a below mediocre internet connection.

Let us assume for one minute the internet connection is fast as hell but the device itself isn’t all powerful. Now imagine loading a website that’s pretty heavy on un-optimised images, lots of javascript, tons of stylesheets, web fonts and so forth. On a mobile device that’s average or below average, the user will have a terrible experience of the website because their hardware or internet speed is lacking.

101 on PageSpeed Insights

Before you read on – I can’t find anything conclusive that confirms Google’s PageSpeed Insights affects website ranking, as in the score created by this tool. However Google rewards ‘fast’ websites. The trouble is what does Google mean by fast? They’re not going to reveal what’s what but they do encourage you to use the PageSpeed Insights tool (and other 3rd party tools) to see where you can improve your sites page speed.

If you head over the PageSpeed Insights, you’ll be greeted with an input box to punch in a URL and run an analysis on that particular page.

Google Pagespeed Insights tool

The PageSpeed Insights API (PSI) reports on the performance of a page on both mobile and desktop devices, and provides suggestions on how that page may be improved.

https://developers.google.com/speed/docs/insights/v5/about

The analysis make take a few minutes as the PageSpeed Insights benchmarks both a mobile and desktop version of your website.

It’s worth mentioning PageSpeed Insights is using their Lighthouse automation tool to conduct the test: https://developers.google.com/web/tools/lighthouse/.

Based on the above google has summarised the key points into sections:

Google PageSpeed insights for gurdeep.ninja

Field data

Field data is a real comparison of the insights against other websites that are also benchmarked based on “Chrome User Experience”.

In short the results you’re seeing are isolated to Chrome Users and not Safari or Firefox. It’s then comparing your site to other sites that have also been PageSpeed tested. I don’t see this to be a major problem unless Google are using PageSpeed insights results to rank websites – it’s a good indicator of how your website performs against every site out there.

Origin Summary

Is an aggregate of every page on your website and how your website performs in general rather than a single URL. Again this is helpful if you want to see how your entire site ranks with PageSpeed against others.

Lab Data

As suggested, this is not field data but based on an isolated controlled environment using the Lighthouse analysis. This analysis is a little detailed but I’ll just stick to FCP (First Contentful Paint) and FMP (First Meaningful Paint).

FCP is how long it took to display something such as the dom and FMP is a little more complex as it depends on context. i.e. if you have a blog website, the first meaningful paint could be “how long did it take to display the article body to read” rather than “how long did it take to load all the styles/css/images”.

Why is FCP and FMP important?

Let’s completely forget Google PageSpeed Insights and touch on user interaction and user experience. How often are you frustrated to visit a website on your device (Desktop or Mobile) that takes a while to render each page. You click the link, wait for the server to respond and see a blank page and wait for something to appear.

Depending on how long you wait, the “wait” has now shaped the user’s experience with the website to some extent. The user will either perceive the site to be slow and may abandon it, or fast and hopefully stick around. If something appears quickly, that is positive for the user.

The second milestone to overcome is how quickly the user can start interacting with the site. We have all been there, visited a site which appears to have loaded the header, but something has stopped the entire page from loading – which adds a delay for user interaction. And to some extent also creating a slightly frustrated user.

Passed Audits

If we ignore the “opportunities” section for a minute, I’m going to talk about optimisation I have made to my website to achieve the current passed audits:

Google PageSpeed insights for gurdeep.ninja

How I got here

Since this website is using WordPress, I was able to enhance PageSpeed using the following methods:

  • CDN enabled for static content
  • WordPress Plugin – Simple Cache
    • Improves TTFB by serving static HTML pages instead of hitting PHP
  • Google Nginx Pagespeed module
    • Lazyload Images
    • Optomise images (Webp/Jpeg/PNG)
    • Minify CSS/HTML/JS
    • Flatten CSS @imports
    • Inline CSS/JS
    • Pre-resolve DNS
    • Prioritise Critical CSS
    • Rewrite CSS
    • Strip image meta-data
    • and many more…

^ In general all the above are standard out of the box settings with a few tweaks I had to made so my site behaved nicely. To view exactly what’s been enabled, view the source of my homepage and scroll to the bottom: view-source:https://gurdeep.ninja/?PageSpeedFilters=+debug

As you can tell the Google Nginx Pagespeed module did a lot of optimisation automatically without the need to do anything manually

The end is there, nearly

Despite all the above, PageSpeed does flag up some issues that can’t be resolved by using plugins or modules. For instance, my WordPress website setup current loads all CSS/JS regardless of what page you’re on. For example, I have WooCommerce installed that allows people to download my Free Magento 2 Theme – however most of the WooCommerce styles are loaded for Posts / Pages. That’s because how WordPress & WooCommerce is wired in general. The same applies for probably all WordPress plugins I have – loading CSS / JS when not necessarily required.

Here is a good theoretical example to optimise CSS / JS files – to only load the styles or javascript required for that particular page. Take for instance the WordPress login page – we don’t need the styles for that page as a global style, so why load it? Same applies for Javascript – why load Javascript libraries on pages that don’t require it.

The solution is quite straight forward but the implemtnation is not – that is the tough part. I haven’t developed enough for WordPress to understand how to solve this problem.

I personally don’t think it’s possible for most websites out there to truly and fully optimise their websites for ultimate performance or usability unless the site is completely bespoke – defining a mobile first approach and then implemented the best practices highlighted by Google PageSpeed.

The future? PWA (progressive web app)

Imagine your website performing just like a native mobile app. PWA will do that. Can you imagine how fast your website will run if your website is based around the progressive web app paradigm? i.e. a user visits your website, the PWA downloads a version of your website that works fast on the device your user is using. Now imagine the user loses internet connection but is STILL able to browse and use your site? Off the rails? Nope, it’s a reality and it’s the way to go. Though it will take me a while to turn my site into a PWA unless there is a WordPress plugin that does it easily…

… puts on the kettle, it’s going to be a long night.

The bar chart graphic in my cover photo is by Lokas Software

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.