The first tap works. The next one feels stuck. A product filter eventually responds, but only after the customer has tapped again. First Input Delay does not describe every part of that experience. Google’s May announcement plans to replace FID with Interaction to Next Paint in March 2024, giving website teams a useful reason to look beyond the first interaction while there is time to prepare.
Be precise about what has changed this month
INP is moving out of its experimental phase, and Google has announced its intention to make it a Core Web Vital next year. It has not already replaced FID in May 2023. That distinction matters when reading a report or discussing requirements with a developer. A forthcoming measurement should not be presented as an existing ranking threshold.
FID focuses on the delay before the browser begins processing the first relevant input. INP looks more broadly at responsiveness across interactions and the time until the next paint. A handler can begin promptly and still perform enough work to leave the screen feeling unresponsive. That is the kind of gap a page-level review needs to investigate.
Choose a task with several interactions
A useful commerce example is browsing a category, opening filters, selecting two options and adding a product to a basket. Review the sequence after the page has loaded, including the point where another script or a third-party feature becomes active. A single click on an otherwise idle page can miss the frustrating part.
Ask the tester to describe what they expected to happen after each tap. A busy state can make a necessary wait understandable, but it should not disguise unnecessary work. The application should also avoid treating repeated taps as separate purchases or duplicate requests when a customer is simply unsure whether the first action registered.
Find the work competing with the interaction
Long stretches of JavaScript can prevent the browser from showing a timely update. Inspect the relevant event, the surrounding tasks and the rendering work rather than deleting code at random. A heavy component, an expensive calculation or a broad rerender can have quite different remedies.
Work in a controlled copy of the page and change one cause at a time. Reproduce the original sequence on a representative phone, not only a developer’s fast computer. Where field information is available, use it to decide which pages and interactions deserve attention. A lab investigation and evidence from real visits should inform one another.
Prepare a better performance brief
Record the action, the observed delay and the page state in which it happens. A brief saying that the second filter selection freezes the results is far more actionable than a request to improve responsiveness everywhere. It also creates a repeatable check for a later change.
Keep the existing Core Web Vitals work in view while evaluating INP. Loading and visual stability still affect the same visitor. Preparing for INP gives the team a reason to investigate the whole visit, with a clear distinction between the metric in force now and the transition Google has announced for next year.
