Lots of long, blocking tasks = high risk of INP!
Few long, blocking tasks = low risk of INP!”
Limitations Of TBT As An INP Substitute
TBT has limitations as an INP substitute.
Pollard noted:
“If you don’t interact during long tasks, then you might not have any INP issues. Also interactions might load MORE JavaScript that is not measure by Lighthouse.”
He adds:
“So it’s a clue, but not a substitute for actually measuring INP.”
Optimizing For Lighthouse Scores vs. User Experience
Some developers optimize for Lighthouse scores without considering the user impact.
Pollard cautions against this, stating:
“A common pattern I see is to delay ALL JS until the user interacts with a page: Great for Lighthouse scores! Often terrible for users 😢:
Sometimes nothing loads until you move the mouse.
Often your first interaction gets a bigger delay.”
Pollard’s Full Post
Why This Matters
Understanding Lighthouse, INP, and TBT relationships is necessary for optimizing user experience.
Recognizing limitations in measuring INP helps avoid misguided optimizations.
Pollard’s advice for measuring INP is to focus on real user interactions to ensure performance improvements enhance UX.
As INP remains a Core Web Vital, grasping its nuances is essential for keeping it within an acceptable threshold.
Practical Applications
To monitor site performance and INP:
Use Lighthouse’s “user flows” for INP measurement in common journeys.
Automate user flows in CI to monitor INP and catch regressions.
Use TBT as an INP proxy, but understand its limitations.
Prioritize field measurements for accurate INP data.
Balance performance optimizations with UX considerations.
Featured Image: Ye Liew/Shutterstock