At a glance
- INP became a Core Web Vital on March 12, 2024, replacing First Input Delay.
- It counts clicks, taps and key presses, not hovering or scrolling.
- Each interaction has three phases: input delay, processing duration and presentation delay.
- Any task over 50 milliseconds is a long task, and the browser cannot respond to input while it runs.
What INP counts
web.dev describes INP as a metric that "assesses a page's overall responsiveness to user interactions". It observes mouse clicks, taps on a touchscreen and key presses. Hovering, zooming and scrolling are not observed. The page normally reports its worst interaction, but on pages with many interactions it ignores one of the slowest for every 50 interactions, so a single outlier does not decide the result. As with the other Core Web Vitals, the 75th percentile across visits is what counts.
Because INP covers the whole visit, it captures what happens after the page loads: opening the game filter, typing in search, switching from slots to live casino, opening the cashier or tapping a bet slip. A lobby can load quickly and still fail INP.
The three phases of an interaction
| Phase | Definition | Casino example |
|---|---|---|
| Input delay | Waiting before event handlers can start, usually because other work is running | A tag or game bundle is still evaluating when the player taps "Live casino" |
| Processing duration | The time the event handlers take to run | A filter handler re-renders hundreds of game tiles at once |
| Presentation delay | From the end of the handlers until the next frame is painted | A very large lobby DOM makes style and layout slow after each change |
Common causes on casino and sportsbook pages
- Long tasks during load. web.dev defines a long task as "any task that takes longer than 50 milliseconds". If the lobby bundle, personalization and tags all evaluate at once, early taps wait. See JavaScript execution costs.
- Heavy handlers. Filtering or sorting a large game catalog in one go, or updating odds for many markets in one task.
- Large DOMs. web.dev notes that rendering work grows with DOM size. Lobbies that render every game tile up front, including those far below the fold, pay for it on every update. See rendering paths.
- Third-party code. Chat, analytics, affiliate tracking and consent tools add work on the main thread. See third-party script audit.
Fixes Google documents
- Do less in event handlers. web.dev's advice is "to do as little work as possible" in them, and to move non-urgent work into a separate task.
- Yield to the main thread. Break long work into smaller tasks with
setTimeout()orscheduler.yield(). web.dev listsscheduler.yield()as supported in Chrome and Edge 129 and later and Firefox 142 and later, but not Safari, so keep a fallback. It no longer recommendsisInputPending(). - Show feedback first. Paint the pressed state or a loading indicator, then run the heavier work, so the next frame arrives quickly.
- Reduce rendering work. Keep the DOM small and consider
content-visibility: autofor long offscreen sections. - Load code when it is needed. Split the filter panel, the cashier and the game launcher into chunks loaded on use.
How to find slow interactions
Field data tells you which pages fail, but not which interaction. Collect INP with attribution from real visits, for example with Google's web-vitals library, to see the element and the phase that took longest. In Chrome, the Long Animation Frames API (shipped in Chrome 123) reports frames delayed beyond 50 milliseconds and attributes them to scripts in the page and same-origin frames. Cross-origin frames, such as many payment and game frames, generally do not get script attribution. In the lab, Total Blocking Time is a reasonable proxy, but web.dev is clear that it is "not a substitute for INP".
Questions
Does INP include interactions inside a game frame?
The metric covers the visit as the browser sees it, but Google's web-vitals library notes that its values can differ from Chrome's field data on pages with iframes, because browser APIs cannot see into iframe content. Debug game and payment frames with their providers.
Is a fast load enough to pass INP?
No. INP is measured until the visitor leaves the page, so slow filters, search or bet slips can fail it even on a page that loads quickly.
What replaced First Input Delay?
INP did, on March 12, 2024. FID measured only the delay before the first interaction; INP covers all three phases of every interaction.
Sources
- web.dev, Interaction to Next Paint (INP), last updated September 2, 2025.
- web.dev, Optimize Interaction to Next Paint, last updated September 2, 2025.
- web.dev, Optimize long tasks, last updated December 19, 2024.
- web.dev, Interaction to Next Paint is officially a Core Web Vital, last updated March 12, 2024.
- Chrome for Developers, Long Animation Frames API, last updated October 14, 2024.
- web.dev, Total Blocking Time (TBT), last updated October 15, 2025 (footer shows November 4, 2024).
- GoogleChrome, web-vitals library, no date shown.