Using Google Lighthouse for page speed

March 5, 2018

Creative , Technical ,


Google wants a faster web, and they’ll stop at nothing to get it. They’ve recently made announcement after announcement that shows that improving the page speed of the web is one of their top priorities.

First, they’re making page speed a ranking factor. They also announced that they’re deploying a specialist team to accelerate the development of the WordPress ecosystem.

Even the sheer number of tools they’ve released to help improve page speed is impressive. There is the good old PageSpeed Insights, and more recently a feature for Winning On Mobile.

Finally, there is Lighthouse. Lighthouse is a tool that was primarily built to help support the development of Progressive Web Apps. But we’ve actually found it much more useful as a tool to help expand our Site Speed Audits.

Usually, a Site Speed Audit would be built around PageSpeed Insights. A classic Google tool, it’s been around for a little while. Combined with other tools like WebPageTest and GTmetrix, forms the basis of most Site Speed Audits.

However with PageSpeed Insights, while detailed, many suggestions will be impractical, if not impossible, for webmasters to implement.

For example, we’ve tried to optimise towards 100/100 on our own front page. But even though we stripped away basically everything, and hardcoded it in static HTML, we were still only able to achieve a score of 91.

This is because PageSpeed Insights is essentially flawed in the way that it works. Some of the metrics that it pulls out, especially for the Harvest homepage, are impossible to do.

Insights has marked us down for not leveraging browser caching. Seems legit. But when we look further into it, we can see that the resources that need caching are analytics tags or social resources. It wouldn’t make sense for us to cache these any longer.

Google Lighthouse

Lighthouse, on the other hand, is much more practical. Google has built it to re-enact real-world situations. It simulates visiting your site over a throttled 3G connection from a slightly underpowered device, to replicate real-life scenarios.

Lighthouse puts more emphasis on not just the site being fast but also feeling fast to the user.

And this is what makes them different. PageSpeed Insights is about the speed of your page, whereas Lighthouse is more about what users notice. Users aren’t going to notice the length of a cache life. All they care about is the fact that the page has loaded.

To that extent, Lighthouse has a bunch of completely different metrics to PageSpeed Insights. And it’s important to know which parts to pay attention to.

Lighthouse Metrics


Performance is your key group of metrics to pay attention to here. It’s split into Metrics, Opportunities and Diagnostics.


Lighthouse uses the following metrics to measure the performance of your mobile site:

  • First meaningful paint – this determines the length of time it takes for some substantial, noticeable content to appear on the screen. You should be aiming for a low score here.
  • First interactive – this shows when a page first becomes interactive, even a little bit. It’s judged by whether or not UI elements are interactive, and if the screen responds to user input at all.
  • Consistently interactive – this shows when a page is fully interactive.
  • Perceptual speed index – the speed index measures how quickly the contents of a page are populated, and visible to the user. Your target here is a loading time of under 1,250ms.
  • Estimated latency input – this metric shows how long it takes for your page to respond to user input. You should be looking to get this as low as possible. Google’s target is less than 50ms.
  • Critical requests chain – this network waterfall shows what resources are called on in order to render the page. You should prioritise asset loading in the critical rendering path to speed up the page.

Once you’ve mastered these metrics, you’re able to draw a lot more insight for your clients than you would do from the more basic PageSpeed Insights.


As well as scoring your site against the above metrics, Lighthouse also gives you a list of opportunities to make your site speed faster by optimising certain resources. These include render-blocking stylesheets, render-blocking scripts, resizing images and fixing offscreen images.


Diagnostics gives you a bit more information about how well your site performed. These audits can be quite useful, especially parts like Critical Request Chains. Other audits, like Minify Javascript and Optimise images, you can get from PageSpeed Insights.

Progressive Web App

The Progressive Web App section is obviously what Lighthouse is pushing you towards, but we don’t really use it.


This section covers how easy it is for people to use your site (or web app). It’s more of an extension of previous Google WebDev tools, e.g. measuring when buttons are too close together.

We’ve been big on accessibility for a little while, so seeing that Google also measures accessibility somewhat validates a drum that we’ve been banging for a few years now.

Best Practices

This section covers what Google refers to as ‘recommendations for modernizing your web app and avoiding performance pitfalls’. Some of the audits here are useful but don’t get too hung up on the score here.

Audits such as Uses HTTPS, and Uses HTTP/2 for its own resources should be easy to pass, but one of the audits in this section will always be failed, especially if you’re using WordPress, and that’s fine. This is the audit marked ‘Does not open external anchors using rel=”noopener”’.

This is to prevent Reverse Tabnabbing. WordPress adds these tags by default, and some webmasters have also adopted it. So don’t worry if you fail it.


The SEO section is a new feature and is still incredibly basic. It features 10 basic SEO audits, including whether the page has a title.

If you’re not scoring 100 on this section already, I’m worried for you.


Once you’ve got all your feedback, you should be looking to work these into various audits for your clients. Don’t simply focus on PageSpeed – even though it’s the primary reason you’re here. We use the accessibility part of Lighthouse to run UX audits, for example.

How to use Lighthouse

To work with Lighthouse, you simply need Chrome 60 or higher, and you can get it as an extension. For those of us who aren’t developers, this is the easiest way to get a solid Lighthouse report. All you have to do is press Generate Report!

Lighthouse can also be run as a node module if you’re into that kind of thing. You can find the instructions to do that here.

Another tool for the toolbox

We’re not saying that Lighthouse is the one site speed tool to use above all others. But it’s definitely a good step up from simply using PageSpeed Insights. Using Lighthouse, alongside tools like GTMetrix and WebPageTest, can really help you drive the most value for your clients.

Comments are closed.