Improving the overall speed and performance of your site is massively important. Not exactly the hottest take, I know, but it impacts not only your users and how they use the site, but how well and how your site is crawled by search engines.
Users don’t want to use a slow site, and we’ve seen that search engines don’t fancy crawling one either – they much prefer crawling sites which respond more quickly, as there will be an increased crawl rate for quicker sites. Improving the speed of your site might be a bit of a pain, but it’ll be massively helpful for both your site and its user base.
With the importance of improving site speed, the arsenal of performance analysis tools has grown, including the likes of GTMetrix, WebPageTest, Google’s own PageSpeed Insights, and the relatively new Mobile Website Speed and Performance tool, actually powered by the aforementioned WebPageTest.
These tools were covered in our last look at improving site speed.
Google have also brought out a relatively new performance analysis tool: Lighthouse. This has been available for a little while now but has come to the forefront more recently, and has even seen an SEO audit added to it, adding to the buzz.
With all that in mind, here’s a quick overview of the new Lighthouse tool, the new SEO audit feature, and how it can help out when it comes to diagnosing site performance issues.
What Is Google Lighthouse?
Google Lighthouse is a tool which aims to highlight page speed performance and overall website optimisation issues/improvements. It’s available as part of Chrome DevTools and as a Chrome Extension and includes actionable audits of areas like performance, overall accessibility, and Progressive Web Apps.
While its current form (version 2.9 as of now) is rather new, Google Lighthouse as a concept has been around for a little while, with its nascent form cropping up in June 2016, focusing more towards optimising Progressive Web Apps.
The improvements to overall accessibility and changes to the UI have helped it to become more prominent as of late, with the audits also progressing in terms of information as time has gone on, seeing the tool become more widely used alongside other performance analysis tools.
Considering the aforementioned array of page speed analysis tools out there, it’s handy to have another one in the mix which can look at areas not covered in the other tools, or at least provides it in a succinct, easy-to-read way, with it being accessible at the browser level.
It’s also worth mentioning the heightened focus on user-based performance metrics and how important they are in determining the actual performance of a page. This is the primary focus of the Lighthouse report – ensuring that the page delivers from a performance standpoint for all users, and determining how the user interprets speed, using metrics based around that. How well it actually does that, we’ll find out later on.
Lighthouse will aim to simulate a user who’s trying to access the page via a relatively poor connection (a throttled 3G connection on a Nexus 5S), ensuring that it’s accessible and responsive for all users.
This is something that can be done in DevTools, as you’re able to change the connection in which you wish to emulate within the Network tab.
Going back to the focus on user-centric metrics, Google released their own documentation on this subject and the progress they’ve been making towards providing these metrics.
This documentation covers how important it is to focus on when content is available on the screen for users, the time in which it takes for it to actually be of use, and whether it’s easy to engage with.
With this in mind, areas such as first paint, first contentful paint, first meaningful paint, and time taken for the page to become interactive are all focal points of determining the performance of the page. It’s gone a bit Bob Ross with all this talk of paint, but these essentially refer to content appearing on the screen – this’ll be covered in a bit more detail further on when we look closer at Lighthouse and its Performance report.
This is reflected not only in the Lighthouse tool, but in the changes made to Pagespeed Insights as well as of the Version 4 release. They incorporated the Chrome User Experience Index into the report, aiming to give afar better representation of how well the page loads for actual users.
All of this really shows the focus being put towards ensuring that content is being displayed quickly, and users are able to quickly interact with it.
So, now that we know what Google Lighthouse is, what it aims to do, and the general intentions behind it – how do you access and use it?
How to Access Google Lighthouse Audits
Upon downloading the Chrome Extension or accessing Chrome DevTools, you’ll be able to quickly run an audit of the webpage that you’re currently on, focusing on the key areas mentioned earlier: Progressive Web App, Accessibility, Performance, Best Practices, and the new SEO Audit feature – all of which will be covered further on.
In Chrome, open up DevTools (right-click anywhere and select Inspect Element), then head to the Audits tab. From there, you’ll be able to select the options for your audit.
Upon downloading the extension, just click the Lighthouse icon near the address bar – again, you’ll be given the audit options. Generate the report once you’ve selected them, and you’re good to go.
From there, you’ll be given the full Lighthouse audit report for your chosen page.
Another way to run a Lighthouse audit would be through WebPageTest. You can find this under the Chrome tab within the main UI of the WebPageTest homepage.
You’ll note above that there’s also an Emulate Mobile Browser option above – you can combine these two options and get a better understanding of how the site would perform across different mobile devices.
Upon completion of the WebPageTest audit, click the Lighthouse PWA Score in the top right-hand corner – you’ll be taken to a full Lighthouse report.
Using Lighthouse to Identify Page Speed Improvements
Here’s an overview of what you’ll see once the audit process is complete, using the Google Lighthouse page itself as an example:
Note that this is the Chrome Extension version of the report – a DevTools report would essentially be the same, but wouldn’t include the section on the left-hand side. The aforementioned WebPageTest report also looks like this.
You can see the environment in which the page was tested under the Runtime Settings link at the top:
As covered earlier, they’ve focused heavily on ensuring that the page performs well for all users, as evidenced by Network Throttling being enabled, emulating someone on a poor internet connection.
There are also options to export the report, though these only seem to pop up in the non-DevTools version of the audit.
There are also scoring metrics for each of the respective areas analysed within the audit, grading them from 0 to 100. Google have stated that if you’re consistently seeing 0’s, then it’s likely to be an error on their end and not necessarily your site. Also, there’s bound to be some fluctuations that happen each time you test the page.
The first audit area is Performance – the primary overview of any speed or performance issues that your page/site may be facing, and the main focus of any page speed improvements you’ll find within the report.
Initially, as shown above in the overall view of the Lighthouse report, you’ll get metrics related to the performance of your audited page, with a timeline being provided which shows how long it took for the page to load and render fully:
The main metrics here are as followed:
First Meaningful Paint: something mentioned earlier, this is essentially the time taken for primary, meaningful content to actually appear on the page.
First Interactive: this measures when a page is minimally interactive, when most, but maybe not all, UI elements on the screen are interactive and the user is able to actually use them.
Consistently Interactive: this is when the page is fully interactive.
Perpetual Speed Index: how quickly the contents of the page are visibly populated, using a Node module called Speedline.
Estimated Latency Input: how long it takes for the page to respond to user input, with a high latency indicating that the page is sluggish and difficult to use.
These all go into determining how well your page performs within Lighthouse’s testing environment, giving you a clearer picture of how well the page loads for users on a less-than-ideal connection.
On a side note, I’ve seen these reports be completely blank – this tends to happen sometimes when tested in the DevTools version, with Audit Errors being displayed.
This may happen due to external resources such as other browser extensions. If this pops up, try it on the Chrome extension version of Lighthouse, or reduce the number of extensions used in the browser during the audit (possibly via a new User window in Chrome).
Upon determining the score, you’ll be given a number of Opportunities, showing the areas in which the page could be improved.
Image-related opportunities are highly common here, centering around reducing the file size of imagery on the page, as well as serving them in different formats. Offscreen Images is a common recommendation, referring to images that appear below the fold. Lazy-loading images is a subject that has been more prominent recently, as covered by SE Roundtable and the recent comment by John Muller.
Clicking into these will provide examples of imagery that could be changed.
For example, here, we can see the “Properly Size Images” opportunity, as well as the images which could be reduced in file size.
Reducing render-blocking scripts and stylesheets are also common areas for improvement, with script and link/style elements blocking the first paint of the page, delaying the loading of the page and its contents somewhat. Unused CSS Rules is also a common occurrence, where you’re recommended to remove unused rules from stylesheets to reduce unnecessary bytes. JitBit’s Unused CSS Finder is handy to use in correlation with this report.
Google’s Lighthouse page has references on the left-hand side to the reports you’ll find in audits, including what the issue is, and the recommended course of action.
You’ll also be provided with various Diagnostics, giving you more of an indicator as to what can be improved – these don’t actually contribute to the overall performance score given to your site.
Further on from here, there are the Progressive Web Apps, Accessibility, and Best Practices reports, though our focus here is on the Performance section, as well as a new addition to the Lighthouse report…
The New Lighthouse SEO Audit
The latest addition to Google Lighthouse is the SEO Audit feature. In terms of the features provided, it offers a very quick look at some key issues with the page that you’ve run the audit for. There are only a few areas checked at the moment, without a great level of detail provided for each of them.
Here’s what will be checked in the Lighthouse SEO Audit report:
- Has a <meta name=”viewport”> tag with width or initial-scale
- Document has a <title> element
- Document has a meta description
- Page has successful HTTP status code
- Links have descriptive text
- Page isn’t blocked from indexing
- Document has a valid hreflang
- Document has a valid rel=canonical
- Document avoids plugins
- Document doesn’t use legible font sizes
They also provide two additional checks which aren’t part of the Lighthouse audits, but are to be checked manually: whether the page is mobile friendly, and if there is valid structured data. These are to be checked through the Mobile Friendly Test and the Structured Data Testing Tool – two long-standing staples of the auditing process.
The vast majority of these are pretty basic, including the use of a proper title, meta description, and canonical tag, as well as the page actually being available for indexing.
Upon completion, you’ll get the same performance grade as the other audits, complete with the audits that were passed + failed.
Google have stated that they’re continuing to work on what is analysed in the SEO Audit, making further improvements as time goes on. On one hand, that’ll be worth keeping on top of seeing as there isn’t much in this audit at the moment. On the other hand, I don’t want Google stepping on my turf, y’know?
But seriously, for someone that works closely with SEO, you won’t find too much here that you wouldn’t already know about via other tools – they described it themselves as a “basic SEO health-check”, indicating that there won’t be a mountain of information in there. It’s more of a brief overview of some key issues which could absolutely be useful for someone who doesn’t have access to tools like Screaming Frog, bringing up issues like a rogue noindex tag or a lack of a canonical tag.
So, as a whole, Lighthouse is a pretty handy tool when it comes to identifying any issues when to page speed and performance. I personally prefer to use it in conjunction with the other tools listed throughout, such as GTMetrix and WebPageTest, collating all issues together and finding common threads between the reports.
When it comes to the SEO audit… it’s not doing much for me at the moment, as not much information is being provided.
What do you think of the Lighthouse reports? Have they made any sort of difference when it comes to identifying page speed issues?