Skip to content

Not affiliated with any operatorCasino website performanceCore Web VitalsiGaming UX engineering

Sources checked Oct 26, 2026UK · US · CA · AU

CasinoPerflyn.onlineCasino performance & Core Web Vitals lab

Core Web Vitals

Interaction to Next Paint for Casino Sites

INP measures how quickly a page responds to clicks, taps and key presses across a whole visit. It usually reports the slowest interaction, and good is 200 milliseconds or less at the 75th percentile. On casino sites, slow responses tend to come from heavy lobby scripts and third-party code competing for the main thread.

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

INP phases, from web.dev "Interaction to Next Paint" (last updated September 2, 2025)
PhaseDefinitionCasino example
Input delayWaiting before event handlers can start, usually because other work is runningA tag or game bundle is still evaluating when the player taps "Live casino"
Processing durationThe time the event handlers take to runA filter handler re-renders hundreds of game tiles at once
Presentation delayFrom the end of the handlers until the next frame is paintedA 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

  1. 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.
  2. Yield to the main thread. Break long work into smaller tasks with setTimeout() or scheduler.yield(). web.dev lists scheduler.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 recommends isInputPending().
  3. Show feedback first. Paint the pressed state or a loading indicator, then run the heavier work, so the next frame arrives quickly.
  4. Reduce rendering work. Keep the DOM small and consider content-visibility: auto for long offscreen sections.
  5. 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".

What we did not test. We have not measured INP on any operator's site. The examples are mechanisms that match web.dev's descriptions, not observations.

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

  1. web.dev, Interaction to Next Paint (INP), last updated September 2, 2025.
  2. web.dev, Optimize Interaction to Next Paint, last updated September 2, 2025.
  3. web.dev, Optimize long tasks, last updated December 19, 2024.
  4. web.dev, Interaction to Next Paint is officially a Core Web Vital, last updated March 12, 2024.
  5. Chrome for Developers, Long Animation Frames API, last updated October 14, 2024.
  6. web.dev, Total Blocking Time (TBT), last updated October 15, 2025 (footer shows November 4, 2024).
  7. GoogleChrome, web-vitals library, no date shown.

Related research

Questions about casino site performance?

Send a correction, a source or a research question. A person reads every message.

Contact the editors hello@casinoperflyn.online