What INP (Interaction to Next Paint) Is and How It Slows Your Site Down in 2026

You've heard Google changed one of its Core Web Vitals and that something called INP now matters. Maybe you saw a red score in PageSpeed Insights and panicked. That's normal — INP is harder to grasp than the old metric it replaced, but once you understand what it measures, it makes sense.

In short: INP doesn't measure how fast the page loads. It measures how fast your site responds when you click, tap, or type into a form. It's the "responsiveness" metric. A page can look fully loaded and still feel frozen for a fraction of a second when you press a button — that's exactly what INP captures. In this article I'll show you what it means, how to measure it correctly, and what to actually do to improve it.

What INP is and what it replaced

INP stands for Interaction to Next Paint. Since March 2024, INP officially replaced FID (First Input Delay) as one of the three Core Web Vitals, alongside LCP (loading speed) and CLS (visual stability).

The difference from FID matters. FID measured only the delay of the FIRST interaction, and only the waiting part — not how long the reaction actually took. It was a forgiving metric; plenty of slow sites passed easily.

INP is far more honest: it looks at ALL interactions on the page (clicks, taps, keystrokes) throughout the visit and reports essentially the slowest one. It measures the whole journey: from the moment you tap until the screen actually changes in response. That's why it's harder to pass.

How INP is measured: thresholds and tools

INP is measured in milliseconds, and Google uses these thresholds (at the 75th percentile of real users):

• Under 200 ms — good (green)
• Between 200 and 500 ms — needs improvement (orange)
• Over 500 ms — poor (red)

Where to check it:

• PageSpeed Insights — the easiest; it also gives you real field data (CrUX) if your site has enough traffic.
• Chrome DevTools, Performance tab — record an interaction and see exactly what takes time.
• The Web Vitals extension for Chrome — shows INP in real time as you browse.

Note: INP is a "field" metric, meaning it depends on real users, their phones, and their connection. A lab test gives you an estimate, but reality shows up in the CrUX data, which accumulates over time.

Why your site is slow on INP

In almost every case, the culprit is JavaScript blocking the main thread. The browser has a single thread it uses both to paint the page and to run scripts. When a script runs for a long time, the browser can't react to your click until it finishes — and that's the delay.

Common causes, especially on small-business sites:

• Too many plugins and third-party scripts (chats, tracking pixels, cookie banners, widgets).
• Heavy WordPress themes loading tons of JavaScript you don't need.
• "Long tasks" — work that keeps the thread busy for over 50 ms.
• Code that recalculates the layout many times on every interaction.

The paradox is that a site can have a good LCP (loads fast) and still have poor INP, because all the weight is felt once you start interacting.

How to actually improve INP

There's no magic button, but the steps are clear:

• Drop scripts you don't use. Every extra chat widget or tracking tool has a cost. Keep only what brings you customers.
• Defer non-critical JavaScript so it doesn't block the first interaction.
• Break long tasks into small chunks and "yield" the main thread (with setTimeout or the browser's modern scheduler) so the click response can go first.
• Prefer CSS over JavaScript for simple animations and effects — CSS runs on a different thread and doesn't block.
• On forms, use debounce so code doesn't run on every keystroke.
• Choose a lightweight theme or build from the start, not a bloated one you then "optimize."

The cheapest win is often removing the ballast, not stacking optimizations on top of it.

What this means for a small-business site

If you run a salon, a clinic, or a local shop, you don't need to become a developer. But two things are worth knowing. First: responsiveness genuinely affects how many visitors stay and click "Book" or "Call." Second: many slow sites are slow by construction, not because of one forgotten plugin — and patched-on optimizations don't help much then.

At MPO Web Studio we build lightweight sites from the start, precisely so we don't have to fight INP later. We work remotely across the country and can build you a free pre-built demo of your site so you can see the difference before you pay anything.

If you want us to look together at why your current site is slow, message us on WhatsApp — we'll tell you honestly whether it's something to fix or to rebuild.