Core Web Vitals Explainer

To understand your Core Web Vitals scores, type your LCP, INP and CLS values into the free Core Web Vitals Explainer above, or paste a table of pages from PageSpeed Insights, Search Console or a CrUX export. Each value is rated good, needs improvement or poor against Google’s thresholds. You get a plain explanation of what the metric measures, a pass or fail for the page, the metric to fix first and the fixes that usually work. Add TTFB and it also tells you whether a slow LCP is the server’s fault or the page’s.

Last updated: 6 November 2026. Written by Saad Raza.

Key takeaways

• Core Web Vitals are three measurements of real user experience: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability).
• A page passes when all three are good at the 75th percentile of real visits: LCP 2.5 seconds or less, INP 200 milliseconds or less, CLS 0.1 or less.
• INP replaced First Input Delay in March 2024. It is stricter, because it measures every interaction rather than just the first.
• Fix the worst metric first. For LCP, check how much of it is server time before you start compressing images.

What each metric means

Core Web Vitals are part of Google’s page experience signals. They are measured from real Chrome users and reported in Search Console and PageSpeed Insights. Each one answers a simple question a visitor would ask.

• Largest Contentful Paint (LCP): how long until the main content shows? It times the largest image or text block in the first screen. Slow servers, heavy hero images and render-blocking files are the usual causes.
• Interaction to Next Paint (INP): when I tap, does it respond? It measures the delay between an interaction and the next visual update, across the whole visit. Heavy JavaScript and third-party scripts are the usual causes. My guide to measuring and improving INP goes deeper, and what changed when FID was retired explains the switch.
• Cumulative Layout Shift (CLS): does the page jump around? It scores unexpected movement of visible content. Images without dimensions, late ads and font swaps are the usual causes. See how to fix CLS.

Two supporting metrics help diagnose them: First Contentful Paint (when anything first appears) and Time to First Byte (when the server first answers).

The thresholds

These are Google’s thresholds from web.dev, applied to the 75th percentile: three out of four visits must be at or under the good line for the page to count as good.

How to use the Core Web Vitals Explainer

1. For one page, type its values into the boxes. Units are flexible: 2.4 s, 2400 ms and 2400 all work, and INP without a unit is read as milliseconds.
2. For many pages, paste a table with a header row. The columns are found by name (url, lcp, inp, cls, fcp, ttfb), so exports from most tools work as they are.
3. Read the verdict: pass or fail, and the metric to fix first.
4. Work through the fixes listed for that metric, then test again after real users have visited (field data updates over 28 days).
5. Download the CSV to track progress across a whole site.

A worked example

The example pastes field data for four pages of a sample site. The tool reported one pass and three fails, with INP as the most common problem:

• Home page (LCP 1.9 s, INP 120 ms, CLS 0.02): Pass. Nothing to fix.
• Long blog guide (LCP 3.6 s, INP 180 ms, CLS 0.18, TTFB 1.2 s): Fail, fix CLS first. Both LCP and CLS need improvement, but CLS is furthest over its good line.
• Shop page (LCP 5.2 s, INP 640 ms, CLS 0.31, TTFB 2.1 s): Fail, fix INP first. All three are poor, and INP is the furthest past its threshold, typical of a page with heavy filters and scripts.
• Contact page (LCP 2.3 s, INP 260 ms, CLS 0.05): Fail on INP alone. A chat widget or map embed is the usual suspect on contact pages.

Enter a single page with LCP 3.6 s and TTFB 1.2 s, and the explainer adds a diagnosis: the server response is 33 percent of LCP, so most of the delay happens after the HTML arrives, which points at the main image and render-blocking files rather than hosting.

Where the numbers come from

• PageSpeed Insights: the “Discover what your real users are experiencing” panel at the top is field data. The score below it is lab data from one simulated load. Use the PageSpeed checker to pull it.
• Search Console: the Core Web Vitals report groups similar URLs and shows which groups fail.
• Your own tests: measure server time with the TTFB and compression checker and page weight with the page size checker.

Fixing the metric that fails

For LCP, start with the server if TTFB is a large share; caching and a CDN help most, as my guide to hosting, caching and CDNs explains. Then make the main image small and prioritised: compress it with the image compressor, serve it at its display size, never lazy-load it, and add fetchpriority="high". For INP, audit third-party scripts and defer anything not needed for the first interaction. For CLS, give every image and embed dimensions and reserve space for anything that loads late. Phones are where most sites fail, so read optimising Core Web Vitals for mobile as well.

Limits

The explainer interprets numbers you give it; it does not measure your site. Its advice lists the most common causes, which are right for most WordPress and small business sites but cannot see your actual code. Lab tools and field data often disagree, and only field data decides whether Google counts a page as passing. Pages with too few visits have no field data at all, in which case Search Console groups them with similar pages. Everything runs in your browser.

Questions about the Core Web Vitals Explainer

If your Core Web Vitals are failing and you want them fixed, my website speed optimisation service covers LCP, INP and CLS, and you can ask for a free audit. You can also browse the other free image and speed tools.