Core Web Vitals: FID Replaced by INP in March 2024 — PageSpeed Insights vs Lighthouse Alternatives

Treat INP as the primary interaction metric now, not FID, and stop relying on a single PageSpeed Insights run to judge whether a site feels responsive. Since March 2024, Google’s Core Web Vitals use Interaction to Next Paint instead of First Input Delay, which means your audits need field data, repeat testing, and better debugging tools.

TLDR: FID was replaced by INP in March 2024 because FID measured only the delay before the first interaction started, while INP measures how long real interactions take from input to visual feedback. A product page may show a fine FID of 35 ms but still fail INP at 420 ms because tapping “Add to cart” triggers heavy JavaScript. PageSpeed Insights is useful for quick checks, but it mixes field data and lab data, so results can confuse teams. Use PSI for reporting, then use Lighthouse, Chrome DevTools, WebPageTest, or real user monitoring to find the actual cause.

What changed in March 2024?

Google replaced First Input Delay with Interaction to Next Paint as a Core Web Vital in March 2024. The reason was simple. FID was too narrow.

FID measured the delay between a user’s first interaction and the browser’s ability to start handling it. That sounds useful, but it missed too much. It did not measure how long the event handler ran. It did not measure rendering work after the handler. It ignored later interactions, even if those were the ones that hurt conversion.

INP is stricter. It measures the latency of user interactions across the page session. It looks at clicks, taps, and keyboard input. It then reports a high-percentile interaction, not just the first one. That makes it better at showing whether a page actually feels responsive.

Good INP: 200 ms or less
Needs improvement: over 200 ms and up to 500 ms
Poor: over 500 ms

Why INP is harder to pass than FID

FID often looked good because browsers are usually ready for the first tap after a page becomes interactive. INP is less forgiving. It catches the slow search filter, the sticky menu button, the cart drawer, the form validation script, and the oversized tag manager setup.

Honestly, it feels like INP exposed problems many teams already felt but could not prove. Users were tapping buttons and waiting. Dashboards still said “green.” That mismatch is much harder to ignore now.

Common causes of poor INP include:

Long JavaScript tasks that block the main thread.
Heavy third-party scripts, especially ads, chat widgets, A/B testing, and analytics tags.
Large React, Vue, or Angular re-renders after simple user actions.
Expensive event handlers attached to clicks, inputs, or keypresses.
Slow DOM updates when large lists, filters, or product cards change.
Layout work caused by reading and writing styles in the same interaction.

PageSpeed Insights: useful, but easy to misread

PageSpeed Insights is often the first place people check Core Web Vitals. That is reasonable. It is free, fast, and tied closely to Google’s public performance standards.

But PSI shows two different kinds of data on one page:

Field data: Real user data from the Chrome User Experience Report, based on recent visits.
Lab data: A controlled Lighthouse test run from Google’s servers.

The field section is the one that matters most for Core Web Vitals assessment. It reflects real Chrome users over a rolling period, usually around 28 days. The lab section is useful for debugging, but it is one test under fixed conditions.

This causes confusion. A URL can show passing field data while the Lighthouse lab score is poor. The reverse can also happen. If your lab test runs on a clean page without cookie banners, logged-in menus, personalization, real ads, or returning-user scripts, it may miss the worst interactions.

Expect to waste time if you treat the big PSI score as the only truth. That score is not the same as Core Web Vitals compliance. It is a Lighthouse performance score, weighted by several lab metrics. INP field data sits in a different part of the report.

How Lighthouse fits into INP testing

Lighthouse is still useful, but it has limits. A standard Lighthouse run loads a page and measures lab performance. It does not behave like thousands of real users clicking menus, opening filters, typing into forms, and dismissing popups.

Lighthouse can help identify likely INP issues through related signals such as:

Total Blocking Time, which shows main-thread blocking during load.
JavaScript execution time, which points to costly scripts.
Main-thread work, which shows where the browser spends time.
Third-party impact, which can reveal scripts outside your direct codebase.

Still, Total Blocking Time is not INP. It is a useful proxy, mostly during load. INP is based on real interactions. A site can have acceptable TBT and still suffer from slow clicks after the page loads.

Best alternatives for deeper INP analysis

When PSI tells you INP is poor, use other tools to answer a harder question: which interaction is slow, and why?

1. Chrome DevTools Performance panel

This is the most direct debugging tool. Record a session, click the slow element, and inspect the main thread. Look for long tasks, event handlers, rendering work, and layout recalculation.

Use DevTools when you need developer-level detail. It can show the exact function or script that blocks visual feedback.

2. WebPageTest

WebPageTest is strong for repeatable lab testing. It offers location selection, device profiles, filmstrips, waterfalls, and scripting. You can script interactions such as opening a menu or typing into search.

It is especially useful when stakeholders need proof. A filmstrip showing a button tap followed by a 600 ms delay is harder to dismiss than a vague score.

3. Real user monitoring tools

Tools such as SpeedCurve, DebugBear, New Relic, Datadog, and other RUM systems can capture INP from actual users. This is often the best source for prioritization.

For example, a site may have a median INP of 160 ms, which looks fine, but the 75th percentile on mobile product pages may be 520 ms. That tells you where revenue is likely being hurt.

4. CrUX Dashboard and BigQuery

The Chrome User Experience Report can be explored through dashboards or BigQuery. This helps compare page groups, origins, countries, and device types. It is not as granular as your own RUM setup, but it is valuable for public, Google-aligned reporting.

How to choose between PSI, Lighthouse, and alternatives

Use each tool for the job it handles best.

Use PageSpeed Insights to check Google field data and communicate Core Web Vitals status.
Use Lighthouse to find lab performance issues and rough optimization targets.
Use Chrome DevTools to debug the exact code behind slow interactions.
Use WebPageTest for repeatable scripted tests and visual evidence.
Use RUM to see how real users experience key pages, devices, and journeys.

Practical INP improvement checklist

Start with the interactions that matter to users and revenue. Do not optimize random scripts before checking the checkout flow, navigation, filters, forms, and account actions.

Break up long tasks so the browser can respond sooner.
Reduce JavaScript shipped to mobile users, especially unused code.
Delay non-critical third-party scripts until after key interactions are ready.
Keep event handlers small and move heavy work out of the interaction path.
Use partial rendering instead of re-rendering large sections after one click.
Test on real mid-range mobile devices, not only a powerful laptop.

A practical workflow is simple. Check PSI to confirm whether INP is failing. Segment the issue by template, device, and traffic source. Reproduce the slow interaction with DevTools or WebPageTest. Fix the code. Then verify with RUM and wait for field data to catch up.

The main lesson is clear: INP made Core Web Vitals more realistic. PageSpeed Insights remains useful, but it is not enough on its own. Serious performance work now requires field data, interaction-level debugging, and proof that real users get faster feedback after they tap, click, or type.