Lighthouse is a tool made by Google to let us measure the performance metrics of our browser apps.
Version 6 is the latest version of the software.
As with other versions, it’s available as part of Chrome or as an NPM package to let us run it automatically to check those performance metrics when the software is being built for continuous integration.
In this article, we’ll look at the latest features of Lighthouse 6.
Lighthouse 6 added some new metrics for measuring the performance of our browser apps.
One of them is the Largest Contentful Paint (LCP). It’s a measurement of perceived loading experience.
It captures how long it takes to load all the parts of our page.
Like with First Contentful Paint (FCP), we don’t want this to take too long.
If it’s more than 2.5 seconds, then it’s too long and we’ve to make our web app speedier.
Another new metric is the Cumulative Layout Shift or CLS.
This is a measurement of visual stability.
Users don’t want a web page to have content that moves around too much.
Jumpy pages make it easy for users to do something they don’t want to do accidentally.
Therefore, any unexpected shift is annoying.
It’s measured by the following formula:
layout shift score = impact fraction * distance fraction
Impact fraction is the measurement of how unstable some element is.
It’s a percentage change of the distance from the original position to the new position.
Distance fraction is the distance that an element moved relative to the viewport.
It’s the great distance of any unstable element that has moved in the frame.
A score below 0.1 is considered good.
These are welcome changes since slowing loading and jumpy pages are always frustrating for users.
Total Blocking Time is another measurement of responsiveness.
It’s the total duration of when the main thread is blocked long enough to prevent input responsiveness.
It’s the total time between FCP and Time to Interactive.
Time to Interactive is the time to take to load the page until when we can interact with the page.
In Lighthouse 6, the performance score is calculated from the weighted blend of multiple performance metrics to summarize page speed.
The metrics are weighted as follows according to https://web.dev/lighthouse-whats-new-6.0/#new-metrics:
|Phase||Metric Name||Metric Weight|
|Early (15%)||First Contentful Paint (FCP)||15%|
|Mid (40%)||Speed Index (SI)||15%|
|Largest Contentful Paint (LCP)||25%|
|Late (15%)||Time To Interactive (TTI)||15%|
|Main Thread (25%)||Total Blocking Time (TBT)||25%|
|Predictability (5%)||Cumulative Layout Shift (CLS)||5%|
The weights are changed in all the categories to takes into account the new metrics.
In version 5, the weights are as follows:
|Phase||Metric Name||Metric Weight|
|Early (23%)||First Contentful Paint (FCP)||23%|
|Mid (34%)||Speed Index (SI)||27%|
|First Meaningful Paint (FMP)||7%|
|Finished (46%)||Time to Interactive (TTI)||33%|
|First CPU Idle (FCI)||13%|
|Main Thread||Max Potential FID||0%|
TTI’s weight decreased according to user feedback. It’s very variable so reducing its weight will decrease its variability.
FCP is also decreased in weight since it doesn’t give us the full picture of loading.
The first CPU Idle metric is deprecated since it isn’t as direct as other metrics for interactivity.
With Lighthouse 6, we can use the Lighthouse Scoring Calculator to make our calculations.
It’s included since 2017, but it’s disabled by default to keep Lighthouse fast.
Now that the tool is more efficient, it’s turned on by default.
It also has some new audit features to audit for some accessibility attributes.
aria-hidden-body makes sure aria-hidden=’true’ is in the body element
aria-hidden-focus checks for aria-hidden in focusable elements.
aria-input-field-name checks for aria attributes in input field names.
aria-toggle-field-name checks for aria attributes in a toggle field.
Form fields shouldn’t have multiple labels.
Headings should be sequentially descending order.
And there shouldn’t be any duplicate aria IDs.
Lighthouse 6 check for all those so that we won’t confuse users that are impaired.
Maskable icons are a new icon format that supports progressive web apps.
It’ll check for them so that we get good looking icons everywhere.
It also checks for the
meta charset element to our HTML.
We also should add a
Content-Type response header which it also checks for.
It specifies the character encoding explicitly so browsers won’t be confused.
With this declaration, browsers can’t render our page wrong.
Otherwise, it can render our page wrong and make the user experience poor.
Lighthouse 6 provides us with the lines of code in our code that are causing audits to fail.
It has links to look through them in the Sources panel.
It can also detect extra polyfills that we don’t need in modern browsers.
There’s also a visualization of all things in a module that require changes to improve the audit score.
We can enable them with the
--preset experimental switch.
For example, we can run:
lighthouse https://example.com --view --preset experimental
to run Lighthouse in the command line with the experimental features on.
Lighthouse CI is a Node CLI program and a server that lets us run Lighthouse audits for every commit.
It can easily be integrated into the continuous integration pipeline.
It supports many CI providers like Travis, Circle, GitLab, and Github Actions.
Docker images are provided to let us make the work of setting up the build pipeline with Lighthouse easy.
We can also install it manually.
To do that, we run:
npm install -g lighthouse
Then we can run it by running:
url is the URL of our page.
Then we can change some options like logging and other configuration.
Logging can be set with
Other configuration options include changing the port, host name, emulate desktop, mobile, etc.
The full list of options are at https://www.npmjs.com/package/lighthouse#using-lighthouse-in-chrome-devtools
For instance, we can run Lighthouse and output to JSON by running:
lighthouse --output json
The Audits panel has been renamed to the Lighthouse panel in chrome.
This makes it easier to find.
We can test mobile performance with emulation of slow network and CPU conditions.
Device screen emulation can also be done.
Lighthouse 6 has changed the reference device to the Moto G4.
There’s a Chrome extension for Lighthouse.
This lets us run it locally in addition to what’s in Chrome itself.
It uses the PageSpeed Insights API.
The API has many limitations.
It can’t audit non-public websites since it runs from a remote server and not locally.
It’s also not guaranteed to have the latest Lighthouse release.
In Chrome, we should use the Lighthouse section of the dev tools to do our audits.
Or we can use the Node package version.
Lighthouse 6 is an even better version of Lighthouse.
It has new metrics to audit the performance of an app from the user’s perspective.
The weights to calculate the final performance score is changed from user feedback.
Also, it can look through our code to find where the problems originate.
This is very helpful when it comes to fixing problems easily.
With the Node package, we can automate our auditing easily.
Then the problems that needed to be fixed will be apparent to us all the time.