What's new in Lighthouse 8.4

Published on

Lighthouse is an automated website auditing tool that helps developers with opportunities and diagnostics to improve the user experience of their sites. It's available in Chrome DevTools, npm (as a Node module and a CLI), or as a browser extension (in Chrome and Firefox). It powers many Google services, including web.dev/measure and PageSpeed Insights.

Lighthouse 8.4 is available immediately on the command line and in Chrome Canary. It will land in Chrome Stable in Chrome 95 and be available in PageSpeed Insights within a week.

To try the Lighthouse Node CLI, use the following commands:

npm install -g lighthouse
lighthouse https://www.example.com --view

See the full list of changes in the 8.4 changelog.

New audits

Don't lazy-load Largest Contentful Paint images

Lazy-loading images can be an effective way to defer offscreen images so they don't interfere with loading the content that is above the fold.

However, if a page's LCP element is an image, lazy-loading it can have a significant negative effect on the LCP. The browser may put the image in the queue and fetch other resources first, instead of prioritizing the image for immediate download. A recent study of lazy-loading in WordPress found that LCP can improve by as much as 15% for some sites if images in the initial viewport are not lazy-loaded.

The lazy-loaded LCP audit in a Lighthouse report

Lighthouse will now detect if the LCP element was a lazy-loaded image and recommend removing the loading attribute from it.

For more information, see the initial proposal and the implementation pull request.

Set a mobile viewport for a better First Input Delay

The viewport audit has been a part of the Best Practices category for years, but 8.4 welcomes this advice to the Performance category as well.

Many mobile browsers support "double tap to zoom" to allow users to easily magnify content not designed for a mobile screen, that is, content without an explicit mobile <meta name="viewport">. In practice, this means the browser needs to wait as much as 300 ms after a user tap to see if a second tap will follow, and during that time the page can't respond to the initial tap. This translates to a failing FID of several hundred milliseconds.

The mobile-viewport audit in a Lighthouse report

In a recent study of data from the HTTP Archive, over half of the sites that received a score of 90 or higher in Lighthouse, but failed at least one Core Web Vital, did not have a mobile viewport set and were failing FID. As a result, the Lighthouse performance section will now recommend adding a viewport like the following if none is found:

<meta name="viewport" content="width=device-width">

For more details, see the proposal issue and implementation pull request.

Getting in touch with the Lighthouse team

To discuss the new features, changes in the version 8.4, or anything else related to Lighthouse:

Published on Improve article

Back

User-Agent Reduction origin trial

Next

New in Chrome 93

This site uses cookies to deliver and enhance the quality of its services and to analyze traffic. If you agree, cookies are also used to serve advertising and to personalize the content and advertisements that you see. Learn more about our use of cookies.