You compressed the images, enabled caching, moved to better hosting, and the page still fails Core Web Vitals. The metric letting you down is INP, and it is the one most sites fail: roughly 43 percent miss the threshold in 2026. It is also the only Core Web Vital you cannot fix by making a file smaller.
That is why it frustrates people who have handled performance work before. Every technique that worked for the other metrics does very little here, because INP measures something structurally different.
What INP actually measures
Interaction to Next Paint replaced First Input Delay in March 2024 and measures the delay between a user interacting with your page and the screen visibly updating in response. Tap a button, open a menu, expand an accordion: INP is how long the page appears frozen before something happens.
The critical difference from the older metric is coverage. First Input Delay only measured the first interaction and only the delay before processing began. INP looks at interactions throughout the visit and measures the full round trip until the screen actually repaints. It is far harder to pass because it reflects what users genuinely experience rather than a single favourable moment.
The threshold is 200 milliseconds for a good score. Above 500 is poor. Scores above 300 milliseconds have been associated with roughly 31 percent drops on mobile, which puts it firmly in revenue territory rather than technical housekeeping.
Why compressing things does not help
Largest Contentful Paint is largely a loading problem, so compressing an image, adding a CDN, or improving server response fixes it. Those are file size and network problems with file size and network solutions.
The problem is the main thread. When a user taps something, the browser needs to run your event handler, recalculate layout, and repaint. If the main thread is busy executing JavaScript, none of that can happen and the interface sits frozen. The page has already loaded. Nothing is downloading. It is simply too busy to respond.
So the fix requires changing how your code handles user events, not shrinking assets. That is a genuinely different kind of work: architectural rather than configurational, and it cannot be delegated to a plugin or a build setting.
Read More - Your Cloud Bill Grows Faster Than Revenue: How to Cut SaaS Infrastructure Cost
What usually causes a poor score
The culprits repeat across most sites:
- Long tasks blocking the main thread. Any single script execution over 50 milliseconds. Frameworks re-rendering large component trees are a frequent source.
- Third party scripts. Analytics, chat widgets, heatmaps, consent managers, and ad tags all compete for the same thread you need for responding to taps.
- Heavy event handlers. Work done synchronously inside a click handler before anything visible changes.
- Layout thrashing. Code reading and writing layout properties repeatedly, forcing the browser to recalculate geometry over and over.
- Oversized DOM. Thousands of elements make every style recalculation expensive, and page builders generate these easily.
- Hydration on interactive pages. JavaScript frameworks attaching behaviour to server rendered markup, often exactly when users first try to interact.
Third party scripts deserve particular attention because they are usually the easiest large win and the hardest politically. The chat widget nobody uses and the three analytics tools measuring the same thing are pure main thread cost, and removing them requires a conversation with whoever asked for them rather than an engineering change.
How to fix INP in practice
Ordered by effort against likely return:
- Measure with field data, not lab tools. INP depends on real interactions. Lab tests simulate loading and cannot tell you what happens when a person taps your menu. Use the Chrome UX Report or real user monitoring.
- Find your worst interactions. Identify which specific elements produce the slow responses. It is usually a handful of components rather than the whole site.
- Yield to the main thread. Break long tasks into chunks so the browser can respond between them. This alone often moves a failing score into passing range.
- Show feedback immediately, then do the work. Update the visual state first, then run the expensive logic. INP stops counting once something repaints, and users perceive it as instant.
- Audit and defer third party scripts. Remove what is unused, defer what is not needed at load, and load chat and similar widgets on interaction rather than immediately.
- Reduce DOM size on interactive pages. Fewer elements means cheaper recalculations on every interaction.
Points three and four are where most of the improvement lives. They are also where a developer is genuinely required, which is the honest answer to why plugin based approaches disappoint here.
Where to start if you only have a day
Most teams cannot clear their calendar for a performance project, so it is worth knowing the order that produces the most improvement per hour spent.
Spend the first hour on measurement, using field data rather than a lab tool, and identify the two or three specific interactions producing the worst results. Almost every failing site has a small number of offenders rather than a uniformly slow interface, and skipping this step is how teams spend a week optimising something that was never the problem.
Spend the second block auditing third party scripts. List everything loading on the page, find the owner of each, and remove anything nobody can justify. This is usually the largest single win available and it requires no code changes, only a decision. Sites commonly carry two or three analytics tools measuring overlapping things plus widgets added for a campaign that ended long ago.
Spend whatever remains on the single worst interaction, applying the show feedback first pattern: update the visible state immediately, then run the expensive work afterwards. Fixing one heavily used control properly is worth more than partially improving five, because the metric is driven by what people actually touch rather than by an average across your interface.
Mobile is where this actually costs you
Desktop pass rates run around 63 percent while mobile lags well behind, and mobile is where the revenue concentration sits. Around 62 percent of ecommerce traffic and more than 64 percent of global web traffic now comes from mobile devices.
The gap is a hardware reality. A mid range phone has a fraction of the processing power of the laptop your developers test on, so JavaScript that executes in 30 milliseconds on a development machine can take 200 on a real device. The site feels perfectly responsive to the people building it and sluggish to most of the people using it.
The practical instruction is to test on an actual mid range Android phone, not a simulator and not your own recent iPhone. Every team that does this finds problems they had genuinely never seen, and it recalibrates what "fast enough" means far better than any dashboard.
Read More - Customers Send Angry Emails When They Cross a Tier: How to Fix SaaS Pricing
Modern design trends make this worse
Worth naming because it explains why sites are failing more, not less, over time. The richer the interaction layer, the easier it is to blow past the threshold. Scroll driven animations, parallax, live filtering, animated transitions, and interactive elements all execute JavaScript in response to user activity.
A design that looks effortless is frequently doing substantial work that a visitor's phone can feel. This is not an argument for static pages, it is an argument for deciding which interactions justify their cost. An animation on a marketing hero is worth far less than a filter on a product listing that customers actually use to buy things.
The version of this that hurts most is decorative work on commercial pages. If your product listing has a scroll animation that makes filtering feel sluggish, you have traded revenue for polish, and the analytics will not tell you because nobody reports a page as slow. They just leave.
If your INP scores are failing and the usual fixes have not moved them, our website development and web app development teams handle front end performance work at the architectural level. Related reading: slow WordPress sites costing sales and fixing a five second bounce.
Frequently Asked Questions
What is a good INP score?
200 milliseconds or below is good, 200 to 500 needs improvement, and above 500 is poor. Google measures the 75th percentile of real user interactions, so a quarter of your visitors can exceed the threshold while you still pass. Scores above 300 milliseconds have been linked to roughly 31 percent drops on mobile.
Why did my score get worse when I did not change anything?
Usually a third party script updated, or your traffic mix shifted toward lower end devices or slower regions. INP is measured from real users, so changes in who visits affect the score without any change to your code. Third party tags updating themselves is the single most common cause of unexplained movement.
Can a plugin fix INP?
Rarely, and this is the key difference from other Core Web Vitals. Plugins genuinely help with image compression, caching, and file delivery, which address loading metrics. INP requires changing how your JavaScript handles interactions, which no plugin can do on your behalf because it depends on your specific code.
Does INP affect rankings?
It is part of Core Web Vitals, which is a ranking signal, though a comparatively modest one against relevance and authority. The stronger argument is commercial rather than SEO: a page that freezes when tapped loses conversions regardless of where it ranks, and a one second delay in load time can reduce conversions by around 7 percent.
How do I measure INP properly?
Use field data from the Chrome UX Report, Search Console's Core Web Vitals report, or real user monitoring. Lab tools like Lighthouse cannot measure INP meaningfully because they do not simulate a real person tapping through your interface. This is the most common measurement mistake teams make.
Should I remove my chat widget and analytics?
Audit them rather than removing everything. Many sites run several tools measuring the same thing, plus widgets nobody uses, and each one competes for the main thread. Load what you keep on interaction rather than at page load, which preserves the functionality while removing most of the cost.
Is this worth prioritising over other work?
If mobile drives meaningful revenue, yes. Mobile carries roughly 62 percent of ecommerce traffic and is where INP failures concentrate, so poor scores hit the transactions that matter most. If your audience is overwhelmingly desktop on fast machines, it is a lower priority than other performance work.
Talk to our team if your Core Web Vitals have stalled despite the usual optimisations.