Lab-based Vitals with Lighthouse’s New Diagnostics
Chrome’s tooling stack has added several features to make it easier to act on Web Vitals issues directly from lab reports. Lighthouse 7.x is now available across the usual entry points—DevTools, CI setups, and WebPageTest—alongside a notable new capability: element screenshots in the report. These images let you visually inspect the exact DOM nodes that are impacting your metrics, such as elements contributing to Cumulative Layout Shift. The same visual aid is now live on PageSpeed Insights, which is handy for quick, one-off audits of public pages.
These screenshots integrate with existing audits, surfacing the responsible elements as thumbnails within flagged opportunities. Previously, you would have to decode raw dimensions or class names from the report to guess which part of the UI was misbehaving.
Reading the Metrics Section
Lighthouse produces a synthetic evaluation of Core Web Vitals, covering Largest Contentful Paint, Cumulative Layout Shift, and Total Blocking Time as the lab-based proxy for interaction readiness. These are shown alongside First Contentful Paint and others in the dedicated "Metrics" section of the report, which gives you a digestible summary view of the experience areas that need attention before you dive into individual audits.
Lab results have known limitations: they can’t fully replicate actual user conditions like device variability or network fluctuations. Real-user data from the Chrome UX Report or your own RUM setup fills those gaps, but field data lacks the granular, diagnostic context you need to fix problems. The ideal workflow is to use lab reports like the ones Lighthouse generates to isolate and fix root causes, then confirm the improvements against field-measured Vitals in production.
Using Lighthouse audits to debug Web Vitals
Find the LCP element
The "Largest Contentful Paint element" audit shows exactly which element triggered the LCP event. Hovering over the entry in the audit highlights the element in the rendered page.
If the LCP element is an image, that's a signal to look at how that image is loaded. Lighthouse's image audits can tell you whether the asset could be compressed, resized, or served in a modern format.
For quick checks outside Lighthouse, Annie Sullivan's LCP Bookmarklet draws a red rectangle around the LCP element on any page with a single click.
Preload images that are discovered late
If the hero image is hidden behind a JavaScript bundle, the browser won't start fetching it until that script executes. Preloading the image tells the browser to fetch it earlier, which can improve LCP.
Preloading works for responsive images too. Given an image defined with srcset and sizes:
<img src="lighthouse.jpg"
alt="A helpful
Lighthouse">
...you can preload it with the matching imagesrcset and imagesizes attributes on the link tag:
<link rel="preload" as="image" href="lighthouse.jpg"
imagesrcset="lighthouse_400px.jpg 400w,
lighthouse_800px.jpg 800w,
lighthouse_1600px.jpg 1600w"
imagesizes="50vw">
The audit also flags preload opportunities when the LCP image is applied via CSS background. Any LCP image—whether in an <img> tag or a background—is a candidate as long as it's discovered at a waterfall depth of three or more.
Lazy loading: apply it selectively
Native lazy loading defers offscreen images until the user scrolls near them, freeing up bandwidth for critical assets. The "Defer offscreen images" audit lists images that are safe to lazy-load:
Above-the-fold images, especially the LCP image itself, should never be lazy-loaded. Doing so delays the LCP metric. The "Largest Contentful Paint image was lazily loaded" audit calls out this mistake directly:
Track down layout shift sources
The "Avoid large layout shifts" audit lists the DOM elements responsible for the biggest shifts, with each element's CLS contribution shown next to it:
Lighthouse's element screenshots give you a visual preview of these elements, with click-to-zoom for a closer look:
For shifts that happen after load, persistent visual cues help. Third-party tools like SpeedCurve's Core Web Vitals dashboard overlay shift rectangles onto the page. Defaced's Layout Shift GIF Generator does the same for a single recording:
Search Console's Core Web Vitals report gives a site-wide view, showing which page templates have high CLS and where to focus your efforts:
Image dimensions and ads
Images and videos without explicit width and height attributes cause the browser to reflow the page once they load. Reserving that space up front prevents this shift:
Ads are a common culprit for layout shift. Publisher Ads for Lighthouse, available under Community Plugins, audits ad loading behavior including CLS contributions:
Two practices matter most: avoid placing non-sticky ads near the top of the viewport, and reserve the largest slot size you expect the ad to need.
Non-composited animations and long tasks
Animations that can't run on the compositor become janky when the main thread is busy, and they can introduce layout shifts. Chrome records these in the DevTools trace, and Lighthouse surfaces them in the "Avoid non-composited animations" audit with the offending elements and reasons:
Long main-thread tasks directly impact First Input Delay and its proxy, Total Blocking Time. The "Avoid long main-thread tasks" audit lists the longest tasks with the script URLs responsible:
Tasks over 50ms are considered long—long enough to block frame rate or input handling. For a deeper view of parent and child task relationships, Calibre's main-thread execution timeline visualizes these costs:
Test impact by blocking requests
Chrome DevTools can block specific network requests to show what a page looks like without a given resource. The technique works inside Lighthouse, making it easy to measure the performance cost of a third-party script or unnecessary polyfill.
A quick example: a site scores 63/100 for performance with a TBT of 400ms. The page loads an Intersection Observer polyfill that Chrome doesn't need.
Right-click the script in the Network panel and choose Block Request URL:
Re-running Lighthouse shows the gain: the score improves to 70/100 and TBT drops from 400ms to 300ms.
Facades for third-party embeds
Video players, social widgets and similar embeds typically load their full payload immediately, even when the user has to scroll to see them. A facade renders a lightweight preview and only loads the real embed on interaction. Lighthouse's third-party facades audit points out which resources can use this pattern:
Lighthouse also flags any third-party code that blocks the main thread for over 250ms, which can expose scripts—including Google's own—that are good candidates for deferral:
Deeper JavaScript guidance
Recent Lighthouse and PageSpeed Insights releases offer concrete suggestions for speeding up JavaScript-heavy apps when source maps are enabled, including audits that flag unnecessary polyfills and duplicate dependencies. For updates on tooling, follow the Lighthouse team on Twitter or check What's new in DevTools.
