For most site owners Core Web Vitals should be a closed subject. LCP, FID, and CLS went live in 2021 and everyone has had time to adapt. The problem is that in March 2024 Google quietly replaced FID with INP, and two years after that change most Polish sites still fail the new metric. In 2026 this can no longer be ignored, because INP is one of the three main signals deciding whether a site is ready to rank for competitive queries.
How INP differs from FID
FID measured one thing only: the delay of the user's first interaction with the site. If the page responded quickly to the first click, it passed. INP goes much further. It measures the delay of every interaction during the whole user session and picks the value at the 98th percentile as representative. In other words, the first twenty clicks can be fast, but the twenty-first, which triggers a slow JavaScript handler, is enough to ruin the score.
The difference is fundamental because INP exposes issues FID used to hide. Heavy analytics scripts, third-party widgets, slow React re-renders, bloated GTM containers, and unnecessary animations show up in INP immediately. The good threshold is 200 milliseconds, needs improvement sits between 200 and 500, and anything above is poor. Sites with a perfect FID often register an INP of 800 milliseconds and have no idea about it.
How to check your score
INP is measured exclusively from real user data, not from lab conditions. That means PageSpeed Insights shows two values: the Chrome User Experience Report score, which is the actual data from the last 28 days, and a lab estimate. For diagnosis you rely on field data. For testing fixes you use DevTools with the Performance panel and its new Interaction section.
A good starting point is the Core Web Vitals report in Google Search Console, which breaks down scores by URL and device. If mobile scores are much worse than desktop, the problem is almost always in JavaScript, not CSS or images. The next step is to run a tool like web-vitals-js on the site and pipe the data into your own analytics, so you can correlate the score with conversion.
Five most common causes of poor INP
- Heavy onClick handlers running computations synchronously instead of delegating to requestIdleCallback
- Third-party marketing and analytics scripts loaded without defer or prioritisation
- React and similar frameworks re-rendering whole component subtrees on every state change
- Animations based on setInterval instead of requestAnimationFrame, which block the main thread
- Content Security Policy and A/B testing handled in JavaScript instead of at the edge
How to fix INP without rewriting the app
Most INP fixes do not require a deep refactor. The first step is a third-party script audit and removing anything that is not strictly necessary. A typical corporate site loads 8-12 tracking scripts and half of them have not been used in a year. The second step is to delay the remaining ones using the defer attribute and run Facebook Pixel and Google Analytics in sendBeacon mode so they do not block the main thread.
The next step concerns your own application code. In React and Vue you check whether components use memoisation where needed and whether global state triggers unnecessary re-renders. In practice splitting contexts, replacing useState with useReducer in complex forms, and moving heavy computations to a Web Worker helps the most. Each change adds a small improvement, but together they drop INP from 800 to 300 milliseconds in about a week of focused work.
INP does not punish a single slow click. It punishes building an app where you never know which click will be the slow one.
What changes with Cloudflare or Vercel
Edge infrastructure such as Cloudflare Workers or Vercel Edge Runtime has a surprisingly large effect on INP. The reason is simple: logic that used to run in the user's browser moves to an edge node that sits physically closer to the user and has far more compute. Country-based personalisation, A/B tests, feature flags, and redirects stop blocking the browser's JavaScript thread.
For a typical Polish company, putting Cloudflare in front of an existing WordPress site or a Shopify store is worth 100-200 milliseconds on INP without a single line of application code change. The same effect comes from migrating hosting from a traditional VPS in Germany to an edge network with a presence in Warsaw and Frankfurt. It is one of the few infrastructure decisions that pay back in under a month.
When it is worth outsourcing
If you have a single simple site and time, INP optimisation can be done in-house in a few days using Google documentation and web.dev tooling. If you have a complex application, an e-commerce store with hundreds of SKUs, or a SaaS with many screens, it is worth bringing in outside expertise from day one. A good agency audits in a week, presents priorities and costs, and ships the most impactful fixes in the next two weeks. Budgets usually land in the low five figures in euros and pay back with organic traffic growth within a quarter.
Case study: a WooCommerce store in four weeks
One of our clients, a mid-sized home and living online store, ran an INP of 720 milliseconds on mobile in November 2025 and lost around 18 percent of conversion during Black Friday compared with the previous year. Google Search Console showed position drops on key commercial queries. Instead of planning a full replatform, we ran a four-week audit and INP optimisation without changing the platform.
The first week was the audit. We found 14 active tracking scripts, of which three were actually used. Disabling the rest took two days and immediately brought INP down to 510 milliseconds. Week two was about onClick handler optimisation in the cart and on the product page, where a single click triggered a full re-render of the recommendation component. Week three was migrating static assets to Cloudflare R2 and introducing edge cache for category pages. Week four was testing and tuning. The final INP landed at 190 milliseconds, CLS improved from 0.18 to 0.04, and organic traffic recovered to previous levels within six weeks.
The total project budget was in the low four figures in euros, significantly less than the potential cost of another shopping season with lower conversion. This is a typical payback profile for a well-run INP audit, if the problem lives in the frontend layer and third-party scripts rather than in the application architecture.
Takeaway
INP is not yet another technical metric that only matters to developers. It is the signal that in 2026 decides rankings in Google and whether a user stays on the site after the first click. Companies that take it seriously in the first half of the year will enter the second half with an advantage that is hard to close later. The first step does not have to be a big investment, just an honest audit of what actually loads on the site and which scripts block the main thread.