We use cookies. You have options. Cookies help us keep the site running smoothly and inform some of our advertising, but if you’d like to make adjustments, you can visit our Cookie Notice page for more information.
We’d like to use cookies on your device. Cookies help us keep the site running smoothly and inform some of our advertising, but how we use them is entirely up to you. Accept our recommended settings or customise them to your wishes.
×

Lighthouse v6: Guiding your way to a “Fast” Site

The Lighthouse Report is one tool that can help identify how your website is performing through the whole loading journey of a user. It can be run against any web page in various ways: using Chrome DevTools, from the command line, as a Node module or even as a Chrome Extension. The report gives you a performance score and tailored recommendations on how to improve it. But what defines a ‘fast’ website? 

How does Lighthouse measure a “fast” website?

 

The truth is relative. A site might be ‘fast’ for one user and ‘slow’ for another one. So, when measuring performance it's important to take into consideration quantifiable criteria, also known as metrics. The Lighthouse Report is measuring them in two ways: in the lab, using automated tools to simulate a page load, and in the field, using real users that interact with the page. Hence, the loading journey of a user is captured by the following metrics:

Example of the performance section from a Lighthouse Audit and the metrics used in v5 and previous
Example of the performance section from a Lighthouse Audit and the metrics used in v5 and previous
Source: https://developers.google.com/web/tools/lighthouse

It is important to note that the Lighthouse score is calculated based on a weighted average, with some metrics being more important than others. For example, FCP and TTI weigh more than Speed Index or First CPU.

Google have been consistently adding features to Lighthouse, but the Performance section has always been everyone’s focus, so whenever there is an update to this there is always some excitement.

At the Chrome Dev Summit in November 2019, Google announced possibly the biggest update to Lighthouse for a while – v6, going live in early 2020. Not only are new metrics being added and others being deprecated, but the weighting of these metrics is changing!

 

So, what are these new Lighthouse metrics and what do they mean?

 

Largest Contentful Paint

Replacing First Meaningful Paint with Largest Contentful Paint (LCP) marks the moment that the largest piece of content is rendered on the page, a hero image or the largest element of text for example. This moment is useful to a user as it often shows the page’s use as well as indicating that the page load is progressing if it is not almost visually complete already.

An image visually showing the Largest Contentful Paint and how it differs to First Contentful Paint
An image visually showing the Largest Contentful Paint and how it differs to First Contentful Paint
Source: https://web.dev/lcp/

Total Blocking Time

Replacing First CPU Idle with Total Blocking Time (TBT) is a metric to calculate a page’s responsiveness to user input by calculating the time the main thread is “blocked” between FCP and TTI. The main thread is “blocked” if a long task is being executed.

Google classifies any task as “long” if it exceeds 50 ms. Why 50ms? This marks the minimum length of time for which a user will begin noticing any lag between interacting with the page and the interaction being executed.

Total Blocking Time is not just the length of time the main thread is in use, but the summation of the time a task uses the main thread after an initial 50 ms period
Total Blocking Time is not just the length of time the main thread is in use, but the summation of the time a task uses the main thread after an initial 50 ms period
Source: https://web.dev/tbt/

What is Lighthouse’s V6 score weighting?

A small note:

As the information currently on web.dev is not aligned with the announcement from Chrome Dev Summit or that found within the detailed GitHub PR, we have done our own interpretation of the scoring based on the publicly available code in Github PR. This may change after the official Google release.

Lighthouse V6 score weighting

All Lighthouse Performance Metrics and their historic version weightings

v6 is shifting the focus and introducing new metrics
v6 is shifting the focus and introducing new metrics
Source: https://web.dev/lighthouse-evolution-cds-2019/

What is going to happen to my Performance Score?

The new metrics and weightings still focus heavily on giving the user a paint and interactivity quickly, ensuring that the user is served with a working page as fast as possible. So, the overall focus has not changed, but the way we are measuring it has changed. The goalposts have shifted, but not by too much. You can also easily model your score on the v5 and v6 Performance Score using this Lighthouse tool.

Do we need to change our focus to improve our Performance Score for V6?

Simply put, no. The new metrics continue to focus on user experience, for example the LCP measures perceived load speed and TBT measures how long a page is not unusable for a user. Your current focus should be on reducing the time it takes for your page to render (Eliminate Render Blocking resources) so the user is given a visual as fast as possible, as well as reducing main-thread usage and JavaScript payloads so your page becomes interactive as fast as possible. This will still be the case with the new metrics, with fixes such as reducing the JavaScript payload positively affecting metrics like both Time to Interactive and Total Blocking Time.

Lighthouse’s evolution: What happened in 2019?

In 2019 there have also been several other updates announced & released to Lighthouse to aid in analysing, reporting and improving your performance; including further new metrics, CMS and Framework specific recommendations and performance budget incorporation.

Cumulative Layout Shift AKA Layout Stability

A new metric was announced called “Cumulative Layout Shift”, something that our team described as:

“You know when you are about to click on a link or some cracking content and then BAM! Ad loads and moves that content. Then you end up in a vortex of ad redirects before eventually getting to the worst webpage you have ever seen, and you have to close the tab because there are too many requests to navigate back through.”

We have all experienced this before and know how painful it can be on our and our user’s experience of our page. Now, Cumulative Layout Shift has been introduced allowing us to quantify this so we can fully understand and project its impact on our users. Not only has this been available on Chrome User Experience Report for a while, the wonderful folks at web.dev have even detailed how you can test & fix Cumulative Layout Shift using WebPageTest. Coming soon to a Lighthouse report near you!

CLS is a measure of how a page’s content changes position as the page loads
CLS is a measure of how a page’s content changes position as the page loads
Source: https://web.dev/cls/

Stack Packs & User Interface

Stack Packs were first introduced in January 2019 and feature CMS or framework specific recommendations on how to improve the performance of your site. Currently WordPress is live on Lighthouse and packs are being created for both React and AMP Frameworks.

For those that use Lighthouse from Chrome Dev Tools or the Lighthouse Chrome Extension, a new UI is coming. Already released and useable on Chrome Canary, the UI is more compact with a more obvious Call to Action. Noticeably, it also includes support for another new feature, Plugins.

The old (left) and new (right) Lighthouse UI side by side. The new UI is available in Canary
The old (left) and new (right) Lighthouse UI side by side. The new UI is available in Canary

Plugins

Lighthouse plugins allow for users to write their own specific tests to add some specific required functionality to Lighthouse which can then be published to the wider community. Some examples of those already created include one to identify YouTube embeds specifically (something we have all seen hinder interactivity I’m sure) and also one to gather CrUX data so you can have field data in the same report.

LightWallet

We all know that we can’t just implement some fixes on our site speed and then leave it at that. After a while our code will start to bloat, new oversized images are added and our performance decreases. This is where the infamous Performance Budgets come in. Touted by Google for a while their implementation and monitoring has posed some issues in the past, however now Google has introduced LightWallet to allow you to incorporate Performance Budgets within Lighthouse from the command line. It generates a breakdown of the requests and their sizes detailing if you are over budget on either.

Lighthouse CI

Long talked about and highly anticipated, Lighthouse CI has made it into Alpha testing. Allowing you to incorporate Lighthouse into your pull requests and into your development process; you can fully and proactively monitor your performance, align it with your performance budget, and identify any possible code branches that may negatively impact your Lighthouse score.

 

2020: The “year of mobile” or the “year of speed”?

 

Mobile experiences are still falling short of user expectations with an average mobile webpage loading for 15.3sNew technologies are emerging, new mobile features and coming up and Google continuously reminds us that we need to move to a faster web. Mobile-friendly, https and speed tools are the new normal. This is no longer a one-off activity that you can slot in your roadmap and forget about for the rest of the year. It is a mindset. Speed and mobile performance are now part of BAU and something that we must monitor, assess and constantly improve if we want to stay competitive. Slow speed affects our revenue on all digital channels – paid and organic.

Performance is not something that can be driven by a single team. It requires alignment between developers, SEOs, marketing, and internal stakeholders for the strategy to be successful. In an ever-evolving digital world, we should all be all on the same page – building fast websites and that also stay fast.

The Lighthouse Performance Score is often a metric that teams can align on to help drive a Performance Mindset across various stakeholders. Focus on delivering a fast FCP/LCP experience alongside minimising your TBT to make a tangible impact on your Performance Score quickly and get everyone to buy into speed for 2020!

Join the Discussion