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.
New Metrics
Lighthouse 6 added some new metrics for measuring the performance of our browser apps.
Largest Contentful Paint (LCP)
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.
Cumulative Layout Shift (CLS)
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 (TBT)
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.
Performance Score Update
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.
New Audits Tools
Lighthouse 6 can audit unused JavaScript.
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.
They include:
- aria-hidden-body
- aria-hidden-focus
- aria-input-field-name
- aria-toggle-field-name
- form-field-multiple-labels
- heading-order
- duplicate-id-active
- duplicate-id-aria
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.
Source Location Links
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.
Experimental Features
Experimental features in Lighthouse 6 that are worth looking at include the ability to detect duplicate modules in JavaScript bundles.
It can also detect extra polyfills that we don’t need in modern browsers.
And it can detect unused JavaScript and report them by modules.
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
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:
lighthouse <url>
Where url is the URL of our page.
Then we can change some options like logging and other configuration.
Logging can be set with --verbose or --quiet.
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
Renamed Chrome DevTools Panel
The Audits panel has been renamed to the Lighthouse panel in chrome.
This makes it easier to find.
Mobile Emulation
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.
Browser Extension
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.
Conclusion
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.
The post What’s new in Lighthouse 6 appeared first on The Web Dev.
Top comments (2)
Does web.dev use lighthouse 6?
Not sure. But how would they write about it if they haven't used it?