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 also how well your site is crawled by search engines.
Users don’t want to use a slow site. 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 users.
With the importance of improving site speed, the arsenal of performance analysis tools has grown. This includes 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 previous 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.
With all that in mind, here’s a quick overview of the new Google Lighthouse tool, the new SEO audit feature, and how Lighthouse 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, providing actionable audits of areas like performance, overall accessibility, and Progressive Web Apps.
Lighthouse is also accessible as a Node module. More information can be found on Google’s own Lighthouse page, as well as Lighthouse’s Github page (as it’s an open source project).
While its current form (version 3.0.3 as of now) is rather new, Google Lighthouse as a concept has been around for a little while. Its nascent form initially cropped up in June 2016, focusing more towards optimising Progressive Web Apps.
The improvements to overall accessibility and changes to the UI have helped it become more prominent as of late. Lighthouse’s audits have also progressed in terms of information provided, 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 Google 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. Google have incorporated the Chrome User Experience Index into the report, aiming to give a far 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, with users being able to quickly engage 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 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. Here are the ways in which you can access the Lighthouse report:
Chrome DevTools:
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. These have improved recently, providing a wide range of choices, including the choice of Mobile and Desktop, as well as the option of including Throttling.
Chrome Extension:
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.
WebPageTest
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.
This is my preferred way of using the tool, as it combines with the actual report you get from WebPageTest, which provides excellent information.
Improving Page Speed With Google Lighthouse
Here’s an overview of what you’ll see once the Lighthouse audit 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, though you’ll also get a View Trace option. This provides the Performance report you’ll find in DevTools, which helps in the process of identifying performance issues with a page. You’ll see something like this:
More information on that can be found via Google’s own guide to Analyzing Network Performance in Chrome DevTools.
Going back to Lighthouse, you can see the environment in which the page was tested under the Runtime Settings section:
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.
Options to export the report are provided, though these only seem to pop up in the non-DevTools version of the audit.
There are scoring metrics for each of the respective areas analysed within the audit, grading them from 0 to 100. This is common with most performance analysis tools such as GTMetrix and Google Pagespeed Insights, providing a quick overview into how well the page has performed.
Performance
The first audit area is Performance: the primary overview of any speed or performance issues that your page/site may be facing. It’s also the main focus of any page speed improvements you’ll find within the Lighthouse report.
Initially, as shown in the overall view of the Lighthouse report, you’ll get metrics related to the performance of your audited page. You’ll also see a timeline which shows how long it took for the page to load and render fully:
Here’s some info on what these mean:
First Contentful Paint: This marks the time at which the first text/image is painted – when any content appears on the screen.
First Meaningful Paint: This measures when the primary content of a page is visible. The lower your First Meaningful Paint score, the faster that the page displays its main content.
First CPU Idle: This marks the first time at which the page’s main thread is quiet enough to handle input. This helps to measure when users are first able to properly interact with the page.
Time to Interactive: defined as the first point at which everything is loaded, meaning that the page and its elements will quickly respond to any user input.
Speed Index: this is how quickly the contents of the page are visibly populated, using a Node module called Speedline.
Estimated Input Latency: finally, this measures 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).
Google have also stated that if you’re consistently seeing zero’s and errors like this, then it can 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.
Opportunities
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 a 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 commonly mentioned issue, 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: whether the page is mobile friendly, and if there is valid structured data. These are to be checked manually through the Mobile Friendly Test and the Structured Data Testing Tool – two long-standing staples of the technical audit 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 indexable.
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.
This report is 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?
If you would like some advice regarding the speed of your site or any aspects of Technical SEO please don’t hesitate to contact us!
