If your site feels slightly laggy, your customers notice before you do.
They click twice. They scroll past the form. They bounce and buy elsewhere.
In 2026, the speed conversation has moved on. It is not just ‘does it load fast’.
It is “does it react instantly when I touch it”.
That is why Interaction to Next Paint (INP) matters. It is now a Core Web Vital, and Google’s own guidance treats Core Web Vitals as part of page experience. The headline threshold is simple: hit 200 milliseconds or less, or expect friction that costs you leads.
Here we explain what INP really measures, why it shows up in your SEO and conversion data, and what to fix first so you can move the needle without rewriting your whole website.
Core Web Vitals in plain English
Core Web Vitals are three metrics that describe how real users experience your pages:
• LCP (Largest Contentful Paint): how fast the main content becomes visible.
• INP (Interaction to Next Paint): how fast the page responds to clicks, taps, and key presses.
• CLS (Cumulative Layout Shift): how stable the layout is while it loads.
Two details that trip teams up:
First, Core Web Vitals are designed around real user data, not best case lab tests. Google commonly reports them using field data from Chrome users.
Second, ‘good’ is judged at the 75th percentile. That means your slowest 25% of visits can keep you in the ‘needs improvement’ bucket even if most sessions feel fine.
INP replaced FID, and it is much harder to fake
FID (First Input Delay) only looked at the first interaction and only measured input delay. In practice, that meant you could score well while the rest of the session still felt sticky.
INP is tougher. It looks at the latency of user interactions across the whole visit and reports a single value that represents how responsive the page feels. If one interaction is consistently bad, INP will show it.
The thresholds are clear:
• Good: 200ms or less
• Needs improvement: over 200ms up to 500ms
• Poor: over 500ms
When people say ‘INP ≤200ms or else’, the ‘or else’ isn’t a penalty switch. It’s death by friction. Slow interactions create hesitation, hesitation kills conversion rate.
Why marketers should care, even if you don’t touch code
INP is where marketing and engineering collide.
If your landing page loads quickly but the CTA click stutters, users feel it. If filters on a category page lag, users abandon. If a cookie banner blocks the first tap, your first impression is ‘this site is hard work’.
These aren’t edge cases. INP is heavily influenced by JavaScript execution on the main thread. And guess what loves JavaScript:
• Tag managers
• Experiment tools
• Chat widgets
• Heatmaps
• Consent banners
• Personalisation scripts
So yes, INP is a technical metric. But the inputs are often owned by marketing.
How Google measures Core Web Vitals (so you don’t chase ghosts)
You’ll see Core Web Vitals in a few places, and they won’t always match:
Search Console Core Web Vitals report uses real world field data. It groups similar URLs and shows trends over time.
PageSpeed Insights shows both lab data (a simulated Lighthouse run) and field data (Chrome UX Report) when enough data exists. A page passes the Core Web Vitals assessment when the 75th percentile for all three metrics is ‘good’.
Chrome DevTools also offers ways to compare your local results with real user baselines, which is useful when your laptop is faster than your customers’ phones.
The rule of thumb is simple:
• Use lab tools to find causes.
• Use field data to judge success.
The fast INP audit: find the real bottleneck in 30 minutes
Here’s a quick process that works for most sites:
1) Start with Search Console
Look at the Core Web Vitals report and focus on INP issues first. Note which templates are affected (product pages, blog, checkout).
2) Use PageSpeed Insights on a problem URL
Check whether field data exists and whether INP is failing on mobile, desktop, or both. Mobile usually tells the truth, use it as a benchmark, most visitors are probably on mobiles.
3) Reproduce in Chrome DevTools
Record a Performance trace while you do the interaction that feels slow (open a menu, apply a filter, submit a form).
You’re looking for long tasks on the main thread. If you see a big chunk of scripting before the next paint, you have your culprit.
4) List what runs on that page
Especially third party scripts. Every extra tag is another chance to block the main thread at the wrong moment.
The 80/20 fixes that move INP quickly
INP problems usually come from the same handful of causes. Fix them in this order.
1) Kill long tasks
If the main thread is busy for long stretches, clicks can’t be processed fast. Break big chunks of work into smaller pieces and let the browser paint between them. Your dev team will talk about yielding, splitting bundles, and reducing blocking scripts. The aim is the same: keep interactions snappy.
2) Reduce JavaScript you don’t need
Audit what’s sent to users. Remove old libraries, unused components, and dead code. For marketing teams, this also means cleaning up tag manager containers and stopping redundant pixels.
3) Delay non essential work until after the first interaction
Load what users need to click and scroll first. Everything else can wait. This is where you win big on busy landing pages.
4) Fix interaction handlers that do too much
Common offenders include mega menus, filter panels, accordions, and custom sliders. If a click triggers heavy DOM updates, expensive layout calculations, or rerenders, it will show up as INP.
5) Watch third party scripts like a hawk
Third party code can add long tasks at random points in the session. Set rules for what gets added, and measure impact before and after. If a tool can’t prove value, it shouldn’t be on your site.
A practical way to split ownership:
• Marketing owned fixes: tag hygiene, consent banner configuration, experiment count, tracking bloat.
• Dev owned fixes: JS bundling, long task splitting, rendering performance, moving work off the main thread.
Don’t ignore LCP and CLS: you only pass if all three are good
It’s tempting to hyper focus on INP. Don’t.
Google’s assessment is based on all three Core Web Vitals at the 75th percentile. In PageSpeed Insights, you pass only when INP, LCP, and CLS are all ‘good’.
The current ‘good’ thresholds are:
• LCP: 2.5 seconds or less
• INP: 200ms or less
• CLS: 0.1 or less
If you fix INP but LCP is slow, users still feel delay. If CLS is messy, users misclick. The best teams treat Core Web Vitals as one system, not three separate objectives.
A simple 4 week plan that works for most sites
Week 1: Measure and prioritise
Pick the top templates by revenue and lead volume. Pull field data and build a short list of worst URLs. Agree success metrics and owners.
Week 2: Fix the biggest blockers
Make the first round of changes that remove long tasks and cut unnecessary scripts. Keep scope tight. Small releases beat big rewrites.
Week 3: Validate in lab and field
Use lab tools to confirm you removed the cause. Then watch field data trends and user behaviour (bounce rate, conversion rate, form completion).
Week 4: Stop regression
Create a release checklist: new tags need approval, new widgets need performance checks, new landing pages get tested before launch.
Performance isn’t a one off project. It is a habit.
FAQ: Core Web Vitals and INP
What is a good INP score in 2026?
A good INP score is 200 milliseconds or less, measured at the 75th percentile of real user visits. Scores over 200ms need improvement, and over 500ms is poor.
How is INP measured?
INP is based on the latency of user interactions like clicks, taps, and key presses during a page visit. Tools commonly report it using field data from real Chrome users when enough data exists.
Does INP affect SEO rankings?
Core Web Vitals are used by Google’s ranking systems as part of page experience. A strong score won’t guarantee top rankings, but poor responsiveness can hold back pages when everything else is similar.
Why does Search Console show different numbers to Lighthouse?
Search Console is field data over many real users and days. Lighthouse is a single lab test on a simulated device. Use Lighthouse to find causes, and Search Console to judge real impact.
What usually causes high INP?
The most common causes are long JavaScript tasks blocking the main thread, heavy third party scripts, and interaction handlers that trigger expensive DOM work.
What are the current Core Web Vitals thresholds?
For good scores, aim for LCP at or under 2.5 seconds, INP at or under 200ms, and CLS at or under 0.1. These are evaluated at the 75th percentile.
How long does it take for improvements to show in field data?
Field data reflects real user experiences and usually lags behind releases. Expect days to weeks, depending on traffic volume and how much data is available for the affected pages.
Can I improve INP without rebuilding my site?
Often, yes. Start by removing or delaying non essential scripts, reducing tag bloat, and fixing the worst interaction handlers on key templates. Many wins come from governance, not a replatform.
