When did INP replace FID, and what changed for measuring responsiveness?

INP (Interaction to Next Paint) became a stable Core Web Vital on 12 March 2024, replacing FID (First Input Delay) which had been a CWV since 2020 (Google Search Central blog announcement May 2023; web.dev migration post). FID measured only the delay before the browser started processing the user's first interaction; INP measures the entire interaction-to-paint path, capturing slow handlers, expensive style recalculations, and layout thrashing — all of which hide from FID. The 'good' threshold is INP <200 ms (vs FID <100 ms). INP is harder to optimise because it measures the worst interaction across the page lifetime, not just the first; sites that passed FID can fail INP if any single click handler is slow. Google Search Console removed FID metrics on 12 March 2024; other tools had a 6-month deprecation window. Transport upgrades (HTTP/2 RFC 7540, HTTP/3 RFC 9114) improve TTFB and resource parallelism but don't directly fix INP — that requires JavaScript optimisation.

Site Speed Check — Core Web Vitals

Q: Why is this different from Lighthouse or PageSpeed Insights?

The Chrome User Experience Report (CrUX) is a public BigQuery dataset Google updates monthly with field metrics aggregated from every Chrome user who opted in. Google uses CrUX as the field-data source for Core Web Vitals ranking signals. Lighthouse, by contrast, runs a single synthetic probe from a clean environment — one device, one network, no real users. Both matter for different questions: Lighthouse for what could be faster in a controlled lab, CrUX for what actually is faster for real visitors. The two datasets often disagree (Lighthouse green + CrUX poor), and the CrUX answer is the one Google uses for ranking.

Q: What does 'not enough data' mean?

CrUX only publishes data for origins and URLs with enough Chrome traffic to aggregate anonymously. Below the publication threshold (Google does not disclose the exact number publicly), the metrics are withheld to prevent single-user inference. If your site shows 'not enough data', run Lighthouse or WebPageTest for synthetic measurements instead.

Q: What's the difference between URL-level and origin-level scope?

URL-level measures the specific URL you entered (e.g. /pricing). Origin-level aggregates every URL across the entire hostname. PingThat tries URL-level first because it's more actionable. If URL-level has no data, it falls back to origin-level, which usually has enough traffic. Origin-level is coarser: you see the typical experience across the site, not the specific page.

Q: Which metric should I optimise first?

Whichever is rated Poor. In 2024-2025, INP is where most sites fail first because it was recently tightened. If INP is Good and LCP is Poor, optimise LCP: preload the hero image, reduce render-blocking CSS, and ship critical JS earlier. CLS is Poor usually because images or ads load without reserved space — that's the cheapest fix.

Site Speed — Core Web Vitals from CrUX (LCP, INP, CLS)

Enter a URL or origin to fetch its Core Web Vitals from the Chrome User Experience Report (CrUX, developer.chrome.com/docs/crux). Results are the 75th percentile across real Chrome users over the past 28 days — the exact dataset Google uses for ranking signals. Core Web Vitals in 2024+ are LCP (Largest Contentful Paint, threshold <2.5 s for 'good'), INP (Interaction to Next Paint, threshold <200 ms — replaced FID on 12 March 2024 per Google Search Central), and CLS (Cumulative Layout Shift, threshold <0.1). Plus FCP (First Contentful Paint) and TTFB (Time to First Byte) for diagnostic context. Lab tests (Lighthouse, WebPageTest) run a single synthetic probe from a clean machine — this tool reflects what actual visitors experienced. Modern transports affect the numbers: HTTP/2 (RFC 7540 Belshe, Peon & Thomson, May 2015) and HTTP/3 (RFC 9114 Bishop Ed., June 2022) over QUIC change connection setup and head-of-line blocking behaviour; switching from HTTP/1.1 to HTTP/2 typically improves TTFB and resource parallelism.

How to check Core Web Vitals

Enter a URL (specific page) or origin (entire hostname) to test.
The tool queries the Chrome UX Report API for the 75th-percentile values of LCP, INP, CLS, FCP, and TTFB over the past 28 days of real Chrome user data.
If URL-level data is insufficient (below CrUX coverage threshold), the tool falls back to origin-level aggregation — pooling every URL on the hostname.
Use the numbers as field-data context — combine with Lighthouse lab tests for a complete optimisation picture.

Common use cases

Auditing whether real Chrome users hit the 'good' CWV thresholds (LCP <2.5 s, INP <200 ms, CLS <0.1) for a key landing page.
Confirming a CDN deployment improved CrUX TTFB — wait 28 days for the rolling window to refresh after deployment.
Comparing mobile vs desktop CWV — mobile usually lags due to slower CPUs and networks.
Spotting regressions: if INP went from green to red after a release, suspect new third-party scripts or expensive interaction handlers.

Frequently asked questions

Why is this different from Lighthouse or PageSpeed Insights?

Lighthouse fires one synthetic probe from a clean machine. CrUX aggregates real Chrome users at p75 over 28 days — that's the dataset Google uses for ranking. Both useful: Lighthouse for lab diagnosis, CrUX for what users actually experience.

What does 'not enough data' mean?

CrUX requires sufficient Chrome traffic per origin/URL to publish data while preserving anonymity. Below the threshold (Google doesn't publish the exact number), no metrics appear. Use Lighthouse or WebPageTest as fallback.

What's the difference between URL-level and origin-level scope?

URL-level reports a specific page (/pricing); origin-level aggregates all URLs on the hostname. URL is more actionable but needs higher traffic. Tool tries URL first, falls back to origin if no data.

Which metric should I optimise first?

Whichever is Poor. In 2024+, INP (replaced FID on 12 March 2024) is where most sites fail since it tightened. Then LCP (preload hero image, reduce render-blocking CSS). CLS is usually the cheapest fix — reserve space for images and ads.

When did INP replace FID?

12 March 2024 (Google Search Central announcement). FID measured delay before first interaction; INP measures full interaction-to-paint path, catching slow handlers and layout thrashing FID missed. Good threshold INP <200 ms (vs FID <100 ms).

Why real-user data matters and how the rolling 28-day window works

Lab-based tools fire one synthetic request from a clean machine on a fast connection. Real users hit slow networks, old devices, crowded CPUs, and third-party cascades. The CrUX dataset aggregates real field metrics at the 75th percentile, which is the number Google uses to decide whether a page is fast for ranking purposes. If your Lighthouse score is great but CrUX is poor, fix the real-user experience, not the benchmark — they're different datasets answering different questions. CrUX has a coverage threshold: an origin or URL needs sufficient Chrome traffic over the rolling 28-day window for Google to publish per-URL data. Below that threshold (Google doesn't disclose the exact number publicly), the tool falls back to origin-level aggregation, which usually has enough volume because it pools every URL on the hostname. The CrUX dataset publicly covers tens of millions of origins (the exact count is published monthly via the BigQuery dataset release notes). Optimising in the right order matters: start with whichever metric is rated Poor. As of 12 March 2024, INP replaced FID — sites that passed FID may now fail INP because INP measures the worst interaction across the page lifetime (slow click handlers, expensive style recalcs, layout thrashing). LCP usually improves by preloading the hero image and reducing render-blocking CSS. CLS is often the cheapest fix — reserve dimensions for images and dynamic content.

LCP, INP, CLS, FCP, TTFB at p75 (Google CWV 2024+ thresholds)
INP replaced FID on 12 March 2024 (Google Search Central announcement)
Mobile and Desktop form factors per CrUX standard
URL-level and origin-level scope (28-day rolling window)
Real Chrome user data via Chrome UX Report (developer.chrome.com/docs/crux)
Clear "not enough data" state for low-traffic sites (below CrUX coverage threshold)

Free. No signup. Browser tools (subnet, JWT, password strength) run locally; lookup tools query public APIs (Cloudflare DoH, RDAP, certificate logs). Full per-tool breakdown at /methodology/.

Sources (5)

Google (web.dev / Chrome team) (live). Core Web Vitals — LCP, INP, CLS thresholds. web.dev/articles/vitals (LCP <2.5s, INP <200ms, CLS <0.1).
Google Chrome team (live). Chrome User Experience Report (CrUX) Methodology. developer.chrome.com/docs/crux (28-day rolling window, p75).
Google Search Central (2024). Interaction to Next Paint (INP) becomes a Core Web Vital on March 12. developers.google.com/search/blog/2023/05/introducing-inp + web.dev/blog/inp-cwv-march-12.
Belshe, M., Peon, R., & Thomson, M. (Ed.) (2015). Hypertext Transfer Protocol Version 2 (HTTP/2). RFC 7540, IETF.
Bishop, M. (Ed.) (2022). HTTP/3. RFC 9114, IETF (HTTP semantics over QUIC).

These are the IETF RFCs, NIST publications, and W3C standards the tool implements or queries. Locate them on the IETF Datatracker (datatracker.ietf.org) or the official standards body.

Related guides

By Marco B. · Last verified June 2026 — runs in your browser