Interaction to Next Paint (INP) replaced First Input Delay (FID) as Google's interactivity Core Web Vital in March 2024, and it now sits alongside LCP and CLS as one of the three explicit Page Experience ranking signals.
Loading Website Speed Test…
INP and FID measurement
Main thread blocking time analysis
JavaScript execution bottleneck identification
No sign-up required
Drop the Website Speed Test into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.
Embed code
<iframe
src="https://www.fixtools.io/web-tools/website-speed-test?embed=1"
width="100%"
height="780"
frameborder="0"
style="border:0;border-radius:16px;max-width:900px;"
title="Website Speed Test by FixTools"
loading="lazy"
allow="clipboard-write"
></iframe>Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.
Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital in March 2024. Where FID only measured the input delay of the very first interaction on a page, INP measures the responsiveness of every interaction throughout the entire page lifecycle including clicks, taps, and keyboard presses. INP is defined as the worst-case interaction latency from the full page visit, with a small allowance for outlier exclusion when an unusual number of interactions occurred. Google's thresholds are Good under 200ms, Needs Improvement from 200ms to 500ms, and Poor above 500ms. An interaction is considered responsive if the browser renders a visual update, which is the next paint, within 200ms of the user's input. That threshold reflects the boundary of human perception: anything inside 200ms feels instantaneous, while anything beyond it registers consciously as a delay.
INP is dominated by JavaScript execution time on the main thread. When the browser's main thread is busy executing long JavaScript tasks, it cannot process user input or render visual updates, and the result is the perception of a frozen or sluggish interface even when the page actually finished loading minutes ago. Long tasks, defined as JavaScript work that takes more than 50ms in a single uninterrupted block, are the primary target for INP optimisation. Tools such as Chrome DevTools' Performance panel and the Long Tasks API surface every task exceeding 50ms with stack traces showing exactly which functions ran. The most common sources of long tasks are third-party analytics and ad scripts, large bundle JavaScript execution during initial page load, complex DOM manipulation inside event handlers, and synchronous operations such as parsing huge JSON payloads or running heavy calculations on the main thread.
INP optimisation requires a different approach from LCP or CLS fixes because the problem is structural rather than asset-driven. The primary technique is yielding to the browser using setTimeout(fn, 0), scheduler.yield(), or Promise.then() to break up long synchronous tasks into smaller chunks that give the browser windows in which to process user input between work blocks. For event handlers specifically, avoid doing heavy work synchronously inside click handlers: perform the minimum necessary DOM update immediately so the user sees a response, then schedule any heavy processing as a follow-up micro-task. Moving non-DOM work to Web Workers is the most powerful INP improvement available because it keeps the main thread entirely free for rendering and user interaction while the heavy lifting happens on a parallel thread the browser does not need to consult before responding.
Diagnosing poor INP in production is a different exercise from diagnosing LCP or CLS. Lab tests run by Lighthouse simulate interactions but cannot capture the full distribution of real user behaviour, so the field data in Search Console and the CrUX dataset is the authoritative source for whether your INP is actually failing for real visitors. When the Search Console report flags INP issues for a URL group, the fastest path to a root cause is the Chrome DevTools Performance panel running an actual interaction recording on the affected page. Look for long tasks coloured red in the main thread timeline, then drill into the call tree to find the specific function call consuming the time. From there the fix is usually one of three patterns: break the function up, defer it past the interaction, or move it off the main thread entirely.
Enter your URL to measure INP/FID and identify JavaScript execution issues causing interactivity delays.
Step-by-step guide to check your inp / fid score (interactivity core web vital):
Enter your URL
Paste the page URL you want to test for interactivity issues, including any path or query parameters that load the JavaScript bundles your real users encounter. The test must run against the full production page rather than a stripped-down development version, because third-party scripts and conditional loaders behave differently in production and are the most common cause of poor INP that surprises teams.
Review the INP score
Check the INP value against Google's thresholds: Good is under 200ms, Needs Improvement is 200 to 500ms, and Poor is over 500ms. Note whether your score is close to the Good boundary or deep into the Poor range, because the gap dictates the level of intervention required. A score of 220ms responds to incremental fixes; a score of 700ms typically requires structural changes to how JavaScript runs on the page.
Identify blocking JavaScript tasks
Review the Total Blocking Time (TBT) and any reported long tasks in the result. Identify which scripts are consuming main-thread time during typical interaction patterns. Pay particular attention to third-party scripts loaded from tag managers, chat widgets, analytics platforms, and consent management tools, because these are the most frequent sources of unexpected long tasks that surface only when real users start interacting with the page.
Reduce main thread blocking
Defer non-critical scripts using async or defer attributes, remove unnecessary third-party scripts that no longer serve an active purpose, or move heavy computation to Web Workers so the main thread stays free for user input. Re-test after each change to confirm the INP value moved in the right direction, since changes that look harmless can occasionally make INP worse by shifting work into the wrong moment of the page lifecycle.
Common situations where this approach makes a real difference:
High cart abandonment investigation
An e-commerce site investigates abnormally high checkout abandonment and discovers an INP of 480ms on the cart page, which means every quantity-update click and remove-item tap feels sluggish to a shopper who is already wavering on the purchase. A tag manager loading 14 marketing scripts is identified as the primary blocking source. Reducing the active tags to the five that demonstrably drive revenue, deferring the rest, and moving the remaining tags into a worker thread drops INP to 180ms within a single sprint. Cart abandonment falls by a measurable percentage in the following month.
Single-page application audit
A React application fails INP because expensive component re-renders are triggered by user interactions that ripple through a deep component tree. A developer uses the INP report alongside the React Profiler to identify the specific interaction patterns causing the longest tasks, then refactors the state management so that updates fan out only to the components that actually depend on the changed data. Adding memoisation around the heaviest children and breaking a synchronous filter operation into incremental work with scheduler.yield brings INP from 410ms back into the Good range without rewriting business logic.
Google Search Console INP alert
A site owner receives a Poor INP alert in Google Search Console for mobile users, with the affected URL group covering the highest-traffic landing pages. Running the FixTools check identifies a heavy image filtering JavaScript function as the main blocking task, triggered every time a visitor adjusts a filter on the product grid. Offloading the filtering routine to a Web Worker via Comlink improves INP from 520ms to 95ms, the Search Console alert clears within the next CrUX update window, and organic traffic to the affected URL group recovers within a month.
Use this when your page feels "laggy" or unresponsive to user clicks and taps, or when INP is flagged as Poor in Google Search Console.
Get better results with these expert suggestions:
Break up long JavaScript tasks to improve INP
Long JavaScript tasks over 50ms block the browser from processing user input for the full duration of the task, so a single 500ms function holds the page unresponsive for half a second from the user's perspective. Break long tasks up using setTimeout(0), Promise.then, or scheduler.yield to create yield points where the browser can handle interactions between work chunks. A single 500ms task should become five 100ms tasks with yield points between them. Chrome DevTools' Performance panel identifies which tasks are longest and shows the function calls inside each one.
Profile real interactions, not just page load
INP measures responsiveness during actual user interactions, not the initial page load that most performance tools focus on by default. Use Chrome DevTools' Performance panel to record a real interaction such as clicking a button, expanding an accordion, or filtering a list, and profile what happens on the main thread during that specific moment. The Long Tasks view shows exactly which code is causing input delay for that interaction, and the call tree drills into the specific functions consuming the time so you can target the fix precisely.
Move non-DOM work to Web Workers
Any JavaScript processing that does not need to access or modify the DOM can run in a Web Worker on a separate thread, completely freeing the main thread for user interactions and rendering. JSON parsing, data processing, cryptography, image filtering, and full-text search indexing are common candidates that benefit dramatically from worker offloading. Libraries such as Comlink make Web Worker communication significantly simpler to implement by exposing worker functions as if they were ordinary async calls, removing the postMessage boilerplate that historically made workers harder to adopt.
Defer non-critical third-party scripts
Analytics, chat widgets, and advertising scripts are common INP offenders because they execute long tasks on the main thread at the moment users are most likely to interact with the page. Load them with async or defer attributes so they do not block the initial render, or inject them only after the main page content has finished loading and the user has had a chance to begin interacting. Partytown is an open-source library that moves third-party scripts entirely to a Web Worker, potentially eliminating their INP impact while retaining the analytics signal these scripts provide.
Long JavaScript tasks are the primary cause of poor INP
INP is determined by how long the browser takes to respond to user interactions. Long JavaScript tasks on the main thread block the browser from responding to clicks. Identifying and breaking up these tasks is the core INP optimisation.
Reduce third-party JavaScript
Tag managers, chat widgets, analytics scripts, and marketing pixels all execute JavaScript on the main thread. A single poorly-written third-party script can cause INP to fail. Audit third-party scripts and remove non-essential ones.
Defer non-critical JavaScript
Add defer or async to all script tags that do not need to execute at page load. This reduces main thread blocking during initial load and improves both INP and TBT (Total Blocking Time).
More use-case guides for the same tool:
Other tools you might find useful:
Open the full Website Speed Test — free, no account needed, works on any device.
Open Website Speed Test →Free · No account needed · Works on any device