You open Search Console and see an INP warning under Core Web Vitals: "longer than 200 ms". It sounds technical, but it is about something very concrete: how quickly your site responds when someone clicks, taps or types. I'll explain what the warning means, why it appears now and how I tackle a problem like this.

What INP actually measures

Interaction to Next Paint, or INP, is a stable Core Web Vital that measures how responsive a page is, based on data from the Event Timing API. That is how web.dev explains it. INP looks at all of a visitor's interactions on the page and reports a single value that all, or nearly all, interactions stayed below.

It matters what counts and what doesn't:

  • Counted: mouse clicks, taps on a touchscreen and key presses, on a physical or an on-screen keyboard.
  • Also counted: interactions inside iframes, such as clicking play on an embedded video.
  • Not counted: hovering, zooming and scrolling.

For every 50 interactions, the slowest one is ignored. Since most page visits have no more than 50, in practice you usually see the worst interaction. A page can also have no INP value at all, for example when the visitor only scrolled or when it was a bot such as a crawler.

Why measure over the whole lifetime of the page? According to Chrome usage data, a visitor spends 90% of their time on a page after it has loaded. A fast load time doesn't tell the whole story.

The thresholds are measured at the 75th percentile of real visits, separately for mobile and desktop:

  • 200 milliseconds or less: good
  • more than 200 up to and including 500 milliseconds: needs improvement
  • more than 500 milliseconds: poor

Why this matters now

INP isn't new. It was introduced as an experimental metric in May 2022, and on 12 March 2024 it officially became a Core Web Vital, replacing First Input Delay (FID), according to the launch post on web.dev. Since then PageSpeed Insights assesses INP instead of FID. Developers had until 9 September 2024 to update tools that pulled FID data.

The Google Search Central documentation lists three Core Web Vitals: LCP for loading (aim for less than 2.5 seconds), INP for responsiveness (aim for less than 200 milliseconds) and CLS for visual stability. A site that used to score fine on FID can therefore show a problem on INP, even though nothing on the site itself has changed.

How to read the Search Console report

The Core Web Vitals report groups URLs by status (Poor, Need improvement, Good), by metric (CLS, INP, LCP) and by URL group, a set of similar pages. The report uses real user data from the Chrome User Experience Report (CrUX).

A few things that often cause confusion:

  • "Group INP" means that 75% of page requests over the last 28 days had this response time or less.
  • The worst metric determines the status. A good INP with a poor CLS still results in "poor".
  • The status applies to the whole group, not to one individual page.
  • Mobile and desktop are assessed separately. Good on mobile doesn't automatically mean good on desktop, or the other way round.

Where the delay comes from

An interaction has three parts. First there is the input delay until the event handlers start, caused among other things by long tasks on the main thread. Then the event handlers themselves run. After that there is another delay until the next frame appears on screen.

According to the guide on optimizing INP, long tasks created when scripts load and run can delay interactions during page load. Put simply: the more work the browser has to process when the page opens, the more likely a click is to hang for a moment.

What to do, in this order

  1. Open the Core Web Vitals report and note which URL groups have a poor INP, separately for mobile and desktop. That tells you which type of page has the problem, for example your product pages or your contact form.
  2. Start with field data. If your site qualifies for CrUX, you'll find the INP data in PageSpeed Insights. Your own measurements from real users (RUM) give more detail: which interaction is slow, whether it happened during or after loading, and which part of the interaction causes the delay.
  3. Then find the cause in a lab environment. Reproduce that slow interaction and look at what happens on the main thread.
  4. Fix the cause. Avoid long tasks when loading scripts. Break up event callbacks and give the main thread frequent chances to do other work, for example with setTimeout, because the callback then runs in a new task. That way the screen shows visual feedback sooner. Work that isn't needed for the next frame goes into a later task. Also keep the DOM small, avoid large, complex layouts and limit style calculations.
  5. Once you think it's fixed, click "Start Tracking" on the issue's detail page in the report. Then keep an eye on your traffic and the group's INP values. Because the report works with the last 28 days, you won't see the effect straight away.

When to outsource it

You can do the first step yourself: read the report and see which pages are affected. From step three it gets technical. You need to read a performance profile, know which script causes a long task and change code without breaking your form or shopping cart. If your site runs on a theme or plugins you don't manage yourself, the cause may sit in code that you, as a business owner, would rather not touch.

I do this kind of work as part of maintenance and security: measuring, finding the cause, fixing it and then following up over the 28 days until the group is back to good. Not sure how serious your warning is? Get in contact with your Search Console data at hand and I'll take a look.