Google’s Lighthouse doesn’t use the Interaction to Next Paint (INP) metric in its standard tests, despite INP being one of the Core Web Vitals.
Barry Pollard, Web Performance Developer Advocate on Google Chrome, explained the reasoning behind this and offered insights into measuring INP.
Lighthouse Measures Page Loads, Not Interactions
Lighthouse measures a simple page load and captures various characteristics during that process.
It can estimate the Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) under specific load conditions, identify issues, and advise on improving these metrics.
However, INP is different as it depends on user interactions.
Pollard explained:
“The problem is that Lighthouse, again like many web perf tools, typically just loads the page and does not interact with it. No interactions = No INP to measure!”
Custom User Flows Enable INP Measurement
While Lighthouse can’t measure INP, knowing common user journeys allows you to use “user flows” to measure INP.
Pollard added:
“If you as a site-owner know your common user journeys then you can measure these in Lighthouse using ‘user flows’ which then WILL measure INP.”
These common user journeys can be automated in a continuous integration environment, allowing developers to test INP on each commit and spot potential regressions.
Total Blocking Time As An INP Proxy
Although Lighthouse can’t measure INP without interactions, it can measure likely causes, particularly long, blocking JavaScript tasks.
This is where the Total Blocking Time (TBT) metric comes into play.
According to Pollard:
“TBT (Total Blocking Time) measures the sum time of all tasks greater 50ms. The theory being: