INP vs FID: What Changed and Why It Matters for SEO

INP vs FID: What Changed and Why It Matters for SEO (2026)

Google replaced FID (First Input Delay) with INP (Interaction to Next Paint) as an official Core Web Vital in March 2024. INP is significantly harder to pass because it measures every interaction across an entire page session — not just the first click. If your site passed FID easily, it may now be failing INP without you realising it. This article explains exactly what changed, why it matters for your rankings, and what to do about it.

If you checked your Core Web Vitals report in Google Search Console recently and noticed a new metric called INP showing Poor or Needs Improvement, you are not alone.

Google made the switch from FID to INP on March 12, 2024. It was one of the biggest changes to Core Web Vitals since the metrics launched in 2021. Thousands of sites that were passing all three vitals under the old system are now failing under the new one.

Understanding exactly what changed — and why INP is harder — is the first step to fixing it.

If you are still getting familiar with Core Web Vitals as a whole, start with the complete Core Web Vitals fix guide first. If you already know the basics and want to understand the FID to INP transition specifically, this article covers everything.

What was FID?

FID stood for First Input Delay. It measured the time between a user's very first interaction with a page — the first click, tap, or key press — and the moment the browser was able to begin processing that interaction.

The keyword is first. FID only measured one single moment: the very first time a user touched the page.

FID was relatively easy to pass for most sites. Here is why:

The first interaction on a page typically happens after the page has already loaded. By the time most users click something for the first time, the browser has finished its most JavaScript-heavy work — parsing scripts, executing event listeners, setting up frameworks. The main thread is usually available. The first click gets a fast response.

This meant sites with genuinely bad JavaScript performance — heavy frameworks, slow event handlers, expensive third-party scripts — could still pass FID comfortably as long as the first interaction happened after the worst JavaScript had finished running.

Google knew this was a problem. FID was passing sites that were delivering a genuinely poor interactive experience. It needed to be replaced with something more representative of what users actually experience.

What is INP?

INP stands for Interaction to Next Paint. It measures the time between any user interaction — a click, tap, or key press — and the next time the browser visually updates the screen in response.

Three things make INP fundamentally different from FID:

1. INP measures all interactions, not just the first one. FID measured one moment. INP monitors every single interaction across the entire page session. Every click on a filter button. Every tab switch. Every form field. Every dropdown. Every button. All of them are measured.

2. INP uses the worst interaction, not the first one. INP takes the highest (worst) interaction delay across the session and uses that as the score. A site with nine fast interactions and one slow one gets scored on the slow one.

3. INP measures through to the visual response, not just the processing start. FID measured the delay before the browser started processing the input. INP measures all the way to when the browser paints the visual response. This is a much fuller picture of what the user actually experiences.

FID vs INP: side-by-side comparison

Why FID was replaced

Google's own research found that FID had a fundamental limitation: it did not reflect how users actually experience interactivity.

Consider a typical e-commerce product page:

• User lands on the page
• First click: opens the image gallery — fast response (FID measured this, score: Good)
• Second interaction: selects a size from the dropdown — slow response (3-second delay)
• Third interaction: clicks Add to Cart — slow response (2-second delay)

Under FID, this page scores Good because the first interaction was fast. Under INP, it scores Poor because the worst interaction — size selection — took 3 seconds.

Which score better reflects the user's experience? INP — by a significant margin.

Google's data showed that FID was approving pages that were genuinely frustrating to use. INP was developed specifically to capture this broader picture of interactivity across the full page lifecycle.

The other technical limitation of FID was that it only measured input delay — the gap before processing started. It did not measure processing time or rendering time. A page could have a 10ms FID but take 2 seconds to visually respond after that because of expensive JavaScript execution. INP captures the full end-to-end interaction time, including processing and rendering.

Why INP is harder to pass than FID was

Most sites that passed FID easily are now finding INP much harder. There are five specific reasons:

1. Every interaction is a potential failure point

With FID, you only needed one interaction to be fast — the first one. With INP, every single interactive element on your page needs to respond quickly. A slow filter widget on your category page. A sluggish tab component on your product page. A sticky navigation menu that lags on scroll. Any of these can cause an INP failure that FID would never have caught.

2. JavaScript-heavy pages are disproportionately affected

React, Vue, Angular, and other JavaScript frameworks are particularly vulnerable to INP failures. Every state update triggers a re-render. Complex re-renders create long tasks on the main thread. Long tasks block the visual response to user interactions.

A React component that re-renders 50 child components on a single button click can produce an INP of 800ms+ on a mid-range Android device — even though the same interaction produces a perfectly fast FID.

3. Third-party scripts affect the entire session

Under FID, a third-party script that loaded and ran heavy JavaScript 2 seconds after page load would not affect the FID score at all — the first interaction happened before the script ran. Under INP, if that third-party script is still running expensive tasks when the user interacts at the 5-second mark, INP records the delay.

This means every third-party script — analytics platforms, advertising networks, chat widgets, A/B testing tools — that runs JavaScript during the page session is a potential INP contributor. For a full breakdown of how third-party scripts affect performance, see how to eliminate render-blocking resources.

4. Mobile devices are measured differently

INP is measured on real user devices. A significant portion of web traffic comes from mid-range and budget Android devices with CPUs 5–10x slower than a MacBook Pro. JavaScript that executes in 20ms on a desktop may take 200ms on a budget phone.

FID was also measured on real devices — but because it only captured the first interaction (usually before heavy JavaScript had run), most mobile users got a fast FID reading even on slow devices. INP captures interactions throughout the session when more JavaScript is running, making the device speed difference much more impactful.

5. The threshold is stricter in practice

The INP threshold (200ms) is higher than the FID threshold (100ms) in absolute terms. But in practice, INP is harder to achieve because:

• FID measured input delay only (typically 10–80ms for passing sites)
• INP measures input delay + processing time + rendering time (must be under 200ms total)

A site with a 10ms FID score might have interactions that take 350ms end-to-end — failing INP by 150ms despite looking excellent on FID.

What INP means for your SEO rankings

INP is an official Core Web Vitals. Core Web Vitals are official Page Experience ranking signals. A failing INP score means:

Direct ranking impact: Pages with Poor INP scores can lose rankings in competitive search results where competing pages have Good INP scores and similar content quality. Google uses CWV as a tiebreaker — when content quality is comparable, the better-performing page wins.

Search Console flagging: Google Search Console now shows INP failures in the Core Web Vitals report. URLs flagged as Poor or Needs Improvement are actively identified as underperforming in Google's system.

Compounded with other CWV failures, Google's Page Experience signal requires all three Core Web Vitals to pass. A site with Good LCP and Good CLS but Poor INP still fails the overall Page Experience signal. For context on how all three vitals connect and interact, the complete Core Web Vitals guide covers the full picture.

The broader impact beyond rankings: INP failures directly reduce conversion rates independently of SEO. Users who experience slow interactions — buttons that feel laggy, filters that stutter, forms that delay — abandon sessions at higher rates. Fixing INP is simultaneously an SEO fix and a UX fix.

How to check if your site is failing INP

Method 1: Google Search Console

1. Go to Google Search Console → Experience → Core Web Vitals
2. Check both Mobile and Desktop reports
3. Look specifically for INP in the issues list
4. URLs grouped under INP issues are your priority fix targets

Search Console shows field data — real user measurements from Chrome browsers. This is what Google uses for ranking decisions. If INP is showing Poor here, it is directly affecting your rankings.

Method 2: PageSpeed Insights

1. Go to pagespeed.web.dev
2. Run your URL
3. In the field data section at the top, look for the INP value
4. In the Diagnostics section, look for "Reduce JavaScript execution time" and "Avoid long main-thread tasks" — these are the primary INP indicators

Method 3: Chrome DevTools Performance panel

1. Open Chrome DevTools → Performance panel
2. Enable "Web Vitals" checkbox in the panel settings
3. Record a session where you interact with the page — click buttons, open menus, fill forms
4. Stop recording
5. Look for INP markers in the timeline and identify which interactions are slowest
6. Look for red-topped bars in the Main thread — these are long tasks that are likely causing slow interactions

Method 4: Web Vitals Chrome extension

Install the Web Vitals Chrome extension from the Chrome Web Store. It shows a real-time INP overlay as you browse your own site — updating after each interaction. This is the fastest way to identify which specific interactions are causing INP failures without opening DevTools.

The most common causes of INP failures in 2026

Based on real-world data from sites that failed INP after passing FID, these are the most common root causes:

Any JavaScript task running for more than 50ms blocks the browser's ability to respond to user input. INP failures are almost always caused by long tasks firing at the moment of interaction.

Common sources of long tasks:

• React/Vue/Angular re-renders triggered by user interactions
• Expensive DOM manipulation (adding/removing many elements)
• Synchronous data processing in event handlers
• Third-party scripts that run at interaction time

Event listeners that do too much work synchronously when triggered:

// Bad — synchronous heavy processing on click
button.addEventListener('click', () => {
  const results = processLargeDataset(allProducts); // blocks for 800ms
  renderResults(results);
});

// Better — yield to browser between heavy tasks
button.addEventListener('click', async () => {
  const results = await processInChunks(allProducts);
  renderResults(results);
});

In React specifically, a single state update can cascade into hundreds of child component re-renders. Each re-render is a JavaScript execution on the main thread. Combined, they create the long tasks that cause INP failures.

jsx

// Bad — updates parent state, causing entire tree to re-render
function ProductList({ products }) {
  const [selected, setSelected] = useState(null);

  return products.map(product => (
    <ProductCard
      key={product.id}
      product={product}
      onSelect={setSelected} // triggers full list re-render on every selection
    />
  ));
}

// Better — memoize child components to prevent unnecessary re-renders
const ProductCard = React.memo(({ product, onSelect }) => {
  return <div onClick={() => onSelect(product.id)}>{product.name}</div>;
});

Ad refresh scripts, analytics event tracking, and A/B testing tools often fire JavaScript in response to user interactions. If these scripts run synchronously on the main thread during an interaction, they add directly to the INP measurement.

How to fix INP: the priority order

Fixing INP is covered in depth in the complete Core Web Vitals guide. The priority order for most sites:

1. Identify your worst interactions first Use the Web Vitals Chrome extension to find which interactions are slowest. Focus on the interactions users actually perform — filter buttons on category pages, add to cart buttons, form submissions, navigation menus.

2. Break up long JavaScript tasks Use scheduler.yield() or setTimeout(fn, 0) to yield the main thread between chunks of expensive work. This is the highest-impact INP fix for JavaScript-heavy sites.

3. Audit and defer third-party scripts. Use PageSpeed Insights → "Reduce the impact of third-party code" to identify which scripts are causing long tasks. Defer or delay loading everything non-essential. See how to preload your LCP image for context on how script loading order affects all Core Web Vitals.

4. Optimise React/framework re-renders. Add React.memo, useMemo, and useCallback to components that re-render unnecessarily on interaction. Profile re-renders in React DevTools before and after to confirm the improvement.

5. Reduce DOM size. Pages with more than 1,400 DOM nodes take significantly longer to style-recalculate after interactions. Audit your DOM size in PageSpeed Insights → "Avoid an excessive DOM size" and reduce unnecessary nesting and off-screen elements.

Sites most at risk from the FID to INP transition

Not all sites are equally affected. These site types are most at risk of failing INP after passing FID:

E-commerce sites with filtering and sorting Category pages with JavaScript-powered filters are one of the most common INP failure scenarios. Each filter interaction triggers a data fetch, a re-render, and a DOM update — all of which create long tasks.

React and Next.js applications. Client-side rendered React applications are particularly vulnerable. Complex component trees, frequent state updates, and large JavaScript bundles combine to create the conditions for INP failures.

Sites with heavy third-party scripts. Sites running 10+ third-party scripts — common on media, publishing, and ecommerce sites — are at high risk. Each script competes for main thread time during the entire session.

WordPress sites with page builders Elementor, Divi, and WPBakery generate large amounts of JavaScript for their interactive elements. Page builder-rendered pages often have DOM sizes of 3,000–5,000+ nodes and multiple long tasks on each interaction.

Blogger sites with heavy widgets. Blogger sites running multiple sidebar widgets, comment systems, and third-party gadgets are particularly affected on mobile. If your Blogger site is experiencing broader performance issues, see how to fix slow server response time — TTFB improvements reduce the window during which third-party scripts can interfere with interactions.

INP vs FID: what the data shows in 2026

Since the March 2024 transition, real-world data has revealed several important patterns:

Pass rates dropped significantly. Before the transition, approximately 65% of mobile web pages met the "Good" threshold for FID. After the INP transition, the pass rate for the equivalent interactivity metric dropped to around 55% on mobile — meaning roughly 1 in 10 pages that were passing are now failing.

E-commerce sites are the most affected. Category pages with JavaScript-powered filters show the highest INP failure rates across industries — often 400–800ms INP on mid-range Android devices.

Third-party scripts are the biggest contributing factor. Analysis of failing INP pages consistently shows that third-party script execution during user interactions is the primary cause, more than framework re-renders or DOM size.

The mobile gap is larger than expected. The difference between desktop INP and mobile INP for the same page is typically 2–4x. A page with a 120ms desktop INP often has a 350–500ms mobile INP — passing on desktop and failing on mobile.

Frequently asked questions

Q1. Is FID still measured anywhere?

FID was officially retired as a Core Web Vital on March 12, 2024. Google no longer uses FID as a ranking signal. However, some older PageSpeed Insights reports and third-party SEO tools may still show FID data from before the transition. Any FID data you see is historical — INP is the current metric that matters.

Q2. If my site passed FID, does it automatically pass INP?

No. Passing FID gives no guarantee about INP performance. FID passing sites that now fail INP are extremely common because FID only measured the first interaction while INP measures all interactions. Sites with good first-interaction performance but slow subsequent interactions passed FID and fail INP.

Q3. What is the INP threshold for Good?

A Good INP score is 200ms or less, measured at the 75th percentile of real user sessions. This means 75% of your users' worst interactions need to be completed within 200ms.

Q4. Does INP affect mobile and desktop rankings separately? 

Yes. Google measures INP separately for mobile and desktop users and scores them independently in Search Console. A page can have Good INP on desktop and Poor INP on mobile simultaneously. Both need to pass to receive the full Page Experience signal benefit.

Q5. My INP score varies a lot between tests. Why? 

INP is inherently variable because it depends on which interactions occur during the measurement session and what else is running on the main thread at that moment. Lab tools (Lighthouse, PageSpeed Insights) may show different INP values on different runs. For a stable, representative INP score, use the field data from Google Search Console — it is averaged over 28 days of real user sessions.

Q6. Can I improve INP without a developer? 

Some INP improvements can be made without developer involvement — particularly deferring or removing third-party scripts and using performance plugins on WordPress. However, the deepest INP fixes (breaking up long JavaScript tasks, optimising framework re-renders, reducing DOM size) require code-level changes. For sites with complex JavaScript, developer involvement is typically necessary to achieve a Good INP score.

Q7. How does INP relate to CLS and LCP? 

All three are Core Web Vitals and all three must pass for a Good Page Experience signal. INP focuses on interactivity, LCP on loading speed, and CLS on visual stability. They are interdependent — fixing render-blocking resources and third-party scripts often improves both LCP and INP simultaneously. The complete Core Web Vitals guide covers all three together.

Summary

FID measured one moment. INP measures everything.

The transition from FID to INP in March 2024 was Google's acknowledgement that measuring only the first interaction was not enough to capture real user experience. INP measures every interaction across the full page session and scores on the worst one.

Sites most at risk are JavaScript-heavy applications, ecommerce sites with filtering, and any site running multiple third-party scripts. The fix strategy starts with identifying your worst interactions in Chrome DevTools or the Web Vitals extension, then breaking up long JavaScript tasks, deferring third-party scripts, and optimising framework re-renders.

INP is harder than FID was. But it is also a more honest measure of whether your site actually feels fast to use. Sites that invest in fixing INP do not just improve their rankings — they improve the experience for every user who interacts with their pages.

Hardeep Singh

Hardeep Singh is a tech and money-blogging enthusiast, sharing guides on earning apps, affiliate programs, online business tips, AI tools, SEO, and blogging tutorials. About Author.