INP Core Web Vital: how to get under 200 ms

INP (Interaction to Next Paint) is the Core Web Vital that measures how fast your page responds to every click, tap, and keypress. It replaced FID in March 2024 and it is the metric most sites fail today. Here is how to measure it, why it spikes, and how to get under 200 ms.

What INP Is and Why Google Made It the Responsiveness Metric

INP observes the latency of every interaction during the full lifetime of a page visit: each click, each tap, each keypress. It does not report an average; it reports the slowest response the user experienced. The idea is simple: a page can load fast and still feel slow the moment someone tries to use it.

The official web.dev INP guide describes it as the metric that assesses a page's overall responsiveness by observing the latency of all click, tap, and keyboard interactions throughout a user's visit. It also adds the data point that justifies the change: Chrome usage data shows that 90% of a user's time on a page is spent after it loads. The real experience lives in the interaction, not in the load.

FID's Limitation: It Only Measured the First Interaction

First Input Delay (FID) measured one thing: the delay between a user's first click and the moment the browser could start processing it. A site could pass FID with flying colors and still take 800 ms to open a menu five minutes later. Google acknowledged that limitation for years: INP was first announced as experimental and later committed to replace FID. Since March 12, 2024 it is the stable responsiveness metric, so do not compare old FID reports with INP as if they measured the same thing.

Which Interactions INP Counts and Which It Ignores

It counts clicks, taps, and keypresses. It ignores scroll, hover, and zoom, because they do not block the response to a user action in the same way. An interaction is a group of events from the same logical gesture (pointerdown, pointerup, and click from a single click), and its latency runs from the start of that group until the browser can paint the next frame. Interactions inside embedded iframes count too.

How INP Is Calculated and What a Good Score Looks Like

INP takes the slowest interaction of the visit with one exception: it drops one interaction out of every 50 so a single outlier does not punish the page. What CrUX, PageSpeed Insights, and Search Console report is the 75th percentile across all visits, split by mobile and desktop. If 75% of visits respond quickly, the metric is good.

Official Thresholds: 200 ms, 500 ms, and the 75th Percentile

200 ms or less: good.
More than 200 and up to 500 ms: needs improvement.
More than 500 ms: poor.

Google recommends keeping INP at 200 ms or less at the 75th percentile, on both mobile and desktop. In practice mobile does worse because of slower CPUs and more variable networks: if your report splits by device, start there.

INP vs FID: Why Your Site May Have Gotten Worse Without Any Changes

Many sites that were green on FID turned amber or red when INP arrived. That is not a regression; it is a change of yardstick. FID measured only the input delay of the first interaction; INP measures the full latency (input, processing, and painting) of all of them. If you have to explain this to stakeholders, that nuance prevents an unnecessary panic: the job is to optimize, not rebuild.

How to Measure Your INP: Field and Lab Data

Order matters: field data first, which is what Google uses, then the lab, which is where you diagnose the cause.

Field Data: CrUX, Search Console, and RUM

PageSpeed Insights shows the CrUX field data block with the 75th percentile INP and its distribution. The Core Web Vitals report in Search Console groups URLs by status and shows which templates fail. If you can add your own measurement, the web-vitals library sends the real INP of every visit to your analytics and lets you cross the number with page type, country, or device.

Lab Data: Simulating Real Interactions

In Chrome DevTools, the Performance panel with CPU throttling at 4x or 6x lets you record a real flow (open the menu, filter a list, submit a form) and see which long tasks line up with the slow interaction. The classic mistake is testing with no throttling: it looks green and does not represent a phone user.

The Three Parts of an Interaction

Interaction latency splits into three stages: input delay (how long the event waits until the main thread is free), processing duration (how long your handlers take), and presentation delay (how long the browser needs to recalculate styles, lay out, and paint the next frame). Knowing which stage eats the time decides which technique to apply; optimizing blindly just moves the problem around.

Common Causes of a High INP

Long tasks on the main thread: a script that occupies the thread for 300 ms blocks any click arriving in that window.
Third-party JavaScript: analytics, chat widgets, consent managers, and marketing tags all compete for the same thread.
Huge DOM and complex layouts: every change forces style and layout recalculation, and the cost multiplies across thousands of nodes.
Repeated work: handlers that read and write the DOM in a loop (layout thrashing) or recompute the same values on every event.

How to Improve Your INP: Practical Techniques

The web.dev Optimize INP guide lays out a clear method: start from field data, reproduce in the lab, then attack long tasks. These are the levers that move the needle most.

Reduce and Split Long Tasks: Yielding

If a task needs more than 50 ms, split it and return control to the browser between chunks so it can handle incoming clicks. The classic pattern uses setTimeout; today there are better APIs such as scheduler.yield.

async function processItems(items) {
  for (let i = 0; i < items.length; i++) {
    heavyWork(items[i]);
    // hand control back every 50 items
    if (i % 50 === 0) {
      await new Promise((r) => setTimeout(r, 0));
    }
  }
}

Where supported, scheduler.yield() hands the thread back with better priority, and navigator.scheduling.isInputPending() lets you yield exactly when an input is waiting. That way a click stops queuing behind a loop that is in no hurry.

Offload Work From the Main Thread With Web Workers

Parsing large JSON, sorting lists, computing totals, or processing text does not need to touch the DOM. A web worker does it on another thread and posts the result back. The main thread stays free to respond, which is exactly what INP measures.

Optimize Handlers and Trim Third Parties

In every handler, do only what is needed for the next frame and defer the rest. Audit third-party scripts with the Coverage panel: every tag that earns nothing can be deferred or removed. And simplify the DOM of your worst templates: fewer nodes, less cost.

INP and SEO: What Google Actually Says

Google says it plainly in the announcement of INP as a Core Web Vital: good stats in the Core Web Vitals report do not guarantee good rankings. Core Web Vitals are part of page experience, one signal among many, not a shortcut. Promising rankings because you lowered INP is selling smoke; the honest claim is that a site that responds fast retains and converts better, and that benefit is measurable.

In Search Console, the Core Web Vitals report stopped showing FID and evaluates INP since March 2024. If you are working from an old audit, check that your responsiveness numbers are INP and not legacy FID. And place it where it belongs: next to LCP (loading speed) and CLS (visual stability), covered in the guide to what Core Web Vitals are. If your problem is loading, start with web fonts and LCP; if it is responsiveness, this article.

Action Plan: From Measuring to Improving in a Week

Check field INP in PageSpeed Insights for your 3 to 5 main templates and note which range you are in.
Open the Core Web Vitals report in Search Console and group failing URLs by template, not one by one.
Reproduce your most interactive flow (menu, cart, form, filters) in the lab with CPU throttling.
Identify the stage where the time goes: input delay, processing, or presentation. That decides the technique.
Apply one lever per week: yielding on the longest task, a worker for heavy computation, or removing a third party that earns nothing.
Measure again at 7 and 28 days. Field data takes time to move; do not change course over one bad day.

Getting under 200 ms does not require rebuilding your site: it requires knowing which interaction hurts, which stage eats the time, and fixing that specific task. If you also organize your measurement in Search Console, you get the full picture: that is what the guide on how to use Google Search Console is for.