Everyone knows what a slow-loading page feels like. Fewer people can name the other failure: the page that looks ready, invites a tap, and then freezes for half a second before anything happens. That stall is the single most jarring performance defect on a marketing site, because it reads as broken rather than slow. It has a name and a number, and most B2B SaaS sites are failing it on mobile right now.
What INP Actually Measures, and Why FID Couldn’t
Interaction to Next Paint measures the full delay between an interaction and the page’s visible response. It clocks the input delay, the time the event handlers run, and the wait for the next frame to paint, across every interaction in the session, and reports close to the slowest one. Good is 200 milliseconds or less; poor is anything over 500 (Google web.dev, 2026)[1].
The metric exists because its predecessor measured too little. FID, First Input Delay, only timed the delay before a visitor’s very first interaction, and only the delay, not the work that followed. A page could score a perfect FID and still freeze on the third tap, when the heavy script finally ran. INP replaced FID as a Core Web Vital on March 12, 2024 (Google web.dev, 2024)[2]. The change broke a lot of “passing” scorecards overnight, because INP measures the responsiveness people actually experience after they start using the page.
If the three Vitals are new to you, start with core web vitals explained for marketers for the overview, then come back. INP is the one that earns a dedicated guide because it is the hardest to pass and the least intuitive to fix.
Poor INP Is Almost Always JavaScript
When INP is bad, the cause is almost always a long task on the main thread, and long tasks come from JavaScript. The browser runs script and responds to input on the same single thread. When a script runs more than 50 milliseconds without pausing, the browser cannot answer a tap until it finishes. The visitor clicks, the thread is busy, and the response waits in line.
The web has been getting heavier, not lighter. In 2024, the median site shipped 558 KB of JavaScript on mobile, up 14% year over year (HTTP Archive Web Almanac, 2024)[3]. That weight turns into blocking work. The same 2024 data found the median mobile page carried 14 long tasks, against just 3 on desktop, and 90th-percentile Total Blocking Time hit 5,950 milliseconds on mobile versus 707 on desktop[4]. Every one of those long tasks is a window where the page cannot respond.
This is also why a content delivery network does not help. A CDN and a caching plugin speed up byte delivery, which improves how fast the page appears. INP happens after that, when the visitor interacts and the device has to execute the JavaScript already sitting on the page. The fix is not faster delivery of the same heavy bundle. It is less main-thread work.
Why INP Is a Mobile Problem
INP is the Core Web Vital with the widest gap between devices, and the gap is the whole diagnostic. In 2025, 97% of desktop origins passed good INP, but only 77% of mobile origins did, a 20-point spread that narrowed from 23 points in 2024 (HTTP Archive Web Almanac, 2025)[5]. The code is identical across devices. The hardware is not.
A mid-range Android phone executes JavaScript several times slower than the laptop the marketing team works on. A long task that finishes in 80 milliseconds on a developer’s machine can take 300 on a real visitor’s phone, which pushes INP from green into red without a single line of code changing. The team tests on fast hardware, sees a responsive page, and ships a frozen one to half its audience.
That blind spot has the same shape as the loading failures in the 15-second site that took seven fixes to reach one: no single villain, just accumulated weight nobody owned, felt worst on the devices nobody tested. INP rewards the team that measures on the hardware its buyers actually hold.
How to Bring INP Down
INP optimization is the discipline of doing less work on the main thread, and doing it in smaller pieces. Three moves cover most of the gain. Defer or remove non-critical JavaScript, especially third-party tags that run on every interaction. Break long tasks into chunks. And yield to the main thread between chunks so the browser can answer input in the gaps.
Yielding is the move with the cleanest evidence. In a 2023 web.dev case study, Trendyol replaced a single 737-millisecond long task in an Intersection Observer callback with chunked work that yielded to the main thread, cutting INP roughly 50% and lifting click-through from listing to product pages by 1% (Google web.dev, 2023)[6]. The pattern generalizes: find the handler that runs long, split it, and let the browser breathe between the pieces. Modern APIs like scheduler.yield make this a few lines rather than a rewrite.
Measure all of it in field data. Google’s own guidance is that INP work should start from field data, the Chrome User Experience Report (Google web.dev, 2026)[7]. Lab tools cannot reproduce the real interactions that produce a true INP, so they come second. Lighthouse gives you Total Blocking Time, a useful proxy, not the metric Google ranks on. Read your field INP in PageSpeed Insights, find the pages and interactions that fail, then drop into lab tools to debug those specific spots. INP is not a question a marketing team answers alone, but it is one a marketing team should be able to read, own, and hand off with the field numbers in hand. That ownership is the through-line behind site speed is a marketing P&L line.
Sources
- Google web.dev, Interaction to Next Paint (INP) – Official metric definition, last updated Sept 2025; good ≤200ms, needs improvement 200-500ms, poor >500ms at the 75th percentile; INP observes input delay, event-handler time, and next paint across all interactions ↩
- Google web.dev, Interaction to Next Paint becomes a Core Web Vital on March 12 – Official announcement, January 31 2024; INP replaced FID on March 12 2024 ↩
- HTTP Archive Web Almanac 2024, JavaScript chapter – HTTP Archive crawl of millions of pages, 2024; median site shipped 558 KB of JavaScript on mobile and 613 KB on desktop, a 14% year-over-year increase ↩
- HTTP Archive Web Almanac 2024, JavaScript chapter (long tasks) – 2024 data; median page had 14 long tasks on mobile vs 3 on desktop; 90th-percentile Total Blocking Time was 5,950 ms on mobile vs 707 ms on desktop ↩
- HTTP Archive Web Almanac 2025, Performance chapter – Published January 15 2026; CrUX July 2025 field data; 77% of mobile origins passed good INP versus 97% on desktop, a 20-point gap, narrowed from 23 points in 2024 ↩
- Google web.dev, How Trendyol reduced INP by 50% – CrUX field data, before Sept 2023 to after, published Dec 2023; replacing a 737 ms long task with chunked work via scheduler.yield cut INP roughly 50% and lifted listing-to-product click-through by 1% ↩
- Google web.dev, Optimize Interaction to Next Paint – Official optimization guide, last updated Sept 2025; INP optimization should start with field data, with lab tools as a complementary follow-up step ↩
Seeing these patterns at your company?
Book a free WebOps Diagnostic. I'll review your site before the call and share specific observations.
Book a Free Call →Frequently Asked Questions
As of 2026, good INP is 200 milliseconds or less, measured at the 75th percentile of real interactions. The needs-improvement band runs from just over 200 up to 500 milliseconds, and poor is anything over 500. The threshold is the same on mobile and desktop, but mobile is far harder to hit because phones execute JavaScript more slowly than laptops, so the same code produces a worse INP on a mid-range Android device.
FID (First Input Delay) only measured the delay before a visitor's very first interaction, and only the input delay portion, not the full response. INP measures every interaction across the whole session, from input delay through event-handler execution to the next paint, and reports close to the slowest. INP replaced FID as a Core Web Vital on March 12, 2024, because it reflects how responsive a page feels in use, not just on first touch.
Long tasks on the main thread, almost always from JavaScript. When a script runs for more than 50 milliseconds without yielding, it blocks the browser from responding to taps and clicks until it finishes. In 2024 the median site shipped 558 KB of JavaScript on mobile and the median mobile page had 14 long tasks. Third-party tags, heavy frameworks, and unsplit event handlers are the usual culprits.
No. A content delivery network and page caching speed up how fast bytes arrive, which helps Largest Contentful Paint. INP is about JavaScript running on the visitor's own device after the page loads, so faster delivery does not touch it. Fixing INP means doing less main-thread work: deferring non-critical scripts, breaking long tasks into smaller chunks, and yielding to the main thread so the browser can respond to input between chunks.
With field data, not a lab test. Google's own guidance is that INP optimization starts with field data from the Chrome User Experience Report, with lab tools as a follow-up. Lighthouse reports proxies like Total Blocking Time, not a true INP, because it cannot reproduce real user interactions. Read your field INP in PageSpeed Insights or the Search Console Core Web Vitals report, then use lab tools to debug specific slow interactions once the field data points you at them.
