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:
- First Contentful Paint (FCP): the time at which the first text/image is painted.
- First Meaningful Paint (FMP): the time when the primary content of a page is visible.
- Time to Interactive (TTI): the time it takes the page to become fully interactive.
- Speed Index: shows how quickly the contents of a page are visibly populated.
- First CPU Idle: the first time at which the page's main thread is quiet enough to handle input.
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.
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.
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.
All Lighthouse Performance Metrics and their historic version weightings
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!
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.
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.3s. New 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!
