Core Web Vitals Example: LCP 3.8s, CLS 0.04, INP 280ms

Two of these three metrics are amber. It is tempting to read that as "mostly fine, some room to improve". It is not how Google scores it.

To pass the Core Web Vitals assessment, all three metrics must be Good. One amber metric fails the page. There is no partial credit, and a CLS of 0.04 — genuinely excellent — earns nothing while LCP sits at 3.8s. This page is not two-thirds of the way to passing. It is failing.

Worth keeping in proportion, though: Core Web Vitals are a real but modest ranking signal, closer to a tiebreaker than a lever. A slow page with the best answer will generally outrank a fast page with a worse one. Fixing this matters — and it will not rescue a page nobody wants to read.

The header says Field Data via PSI API, and that is the single most important label on this report. These numbers are not a simulation. They come from the Chrome User Experience Report — real Chrome users, on their real phones, on their real networks.

Three consequences that determine how you act on it:

• 3.8s is the 75th percentile, not the average. The threshold is met when 75% of visits are good. So the median visitor may well be experiencing 2.1s — and the slowest quarter, on older phones and worse connections, are at 3.8s or beyond. Those are the people the metric exists to protect, and averages hide them completely.
• The window is 28 days, rolling. Deploy a fix today and the number will not fully reflect it for four weeks. Teams routinely ship a genuine improvement, check after five days, see nothing, and revert it.
• Low-traffic URLs have no field data at all. Where a page has too few visits, Google falls back to origin-level data — the whole site's numbers, applied to that page. This is why an obscure page can inherit a poor score it did nothing to earn, and why fixing your busiest templates lifts pages you never touched.

This also explains the classic disagreement: a page can pass in Lighthouse and fail here. Lighthouse is one synthetic load in a data centre. This is what happened to actual people. When the two conflict, this one is the one Google uses.

INP replaced FID in March 2024, and it is a far harder test. FID measured only the delay before an interaction began being processed. INP measures the whole thing — from the tap until the screen actually updates. It also considers every interaction across the page's life, not just the first.

Every interaction decomposes into three phases, and the report has found problems in two of them:

These need opposite fixes. Input delay is fixed by not running third-party code during load — the chat widget has no business executing before the user has done anything. Processing time is fixed by yielding: break the handler's work into chunks so the browser can paint between them, rather than blocking for 140ms and then painting once.

This is not bad luck. A product page is where third-party JavaScript accumulates, and third-party JavaScript is what breaks INP.

Count them on any real store: analytics, a tag manager, a chat widget, a review platform, a recommendation engine, a personalisation script, an A/B testing tool, a heatmap recorder, a consent manager, a currency converter, and three advertising pixels. Each one runs on the same single main thread that has to respond when someone taps Add to Cart.

• The tag manager is the worst offender, because it is a loader for everything else — and because marketing can add scripts to it without anyone reviewing the performance cost. Audit what is actually in it. There is nearly always a pixel for a campaign that ended two years ago, still executing on every page view.
• Defer everything that is not needed for the first interaction. A chat widget does not need to exist until somebody wants to chat. Load it on first user interaction, or on idle, or on hover — not on page load.
• Third-party scripts are the one thing you cannot optimise, only remove or defer. You do not control their code. The only lever you have is when — and whether — it runs.

The revenue argument writes itself on a product page: the interaction being delayed by 280ms is the add-to-cart button. This is not an abstract quality metric.

The report names three LCP opportunities. They are not equally valuable and they should not be done in the order listed — do them in this order:

1. Preload the hero image. Biggest win, smallest change. Without it, the browser only discovers the image after parsing the HTML and, frequently, after the CSS has parsed too. A <link rel="preload" as="image"> in the head means the preload scanner finds it in the first bytes of the document. Add fetchpriority="high" to the image itself so it queues ahead of everything else.
2. Unblock the third-party review CSS. 380ms of render-blocking, from a domain you do not control, requiring its own DNS lookup, TCP handshake and TLS negotiation before the first byte. Nothing about a review widget needs to block the first paint of a product page.
3. Then the WebP conversion. 78KB to 45KB is real and it is the smallest of the three. Compressing an image the browser has not been told about yet does not fix the fact that it has not been told about it.

What are Core Web Vitals?

Core Web Vitals are three performance metrics Google uses as ranking signals: LCP (Largest Contentful Paint) measures loading speed, CLS (Cumulative Layout Shift) measures visual stability, and INP (Interaction to Next Paint) measures responsiveness. Good scores are LCP under 2.5s, CLS under 0.1, INP under 200ms.

How does LCP affect SEO?

LCP is a direct Google ranking factor. Pages with LCP above 4 seconds receive a Poor rating and rank lower than faster competitors. Improving LCP involves preloading the hero image, eliminating render-blocking resources and using a fast CDN.

What causes Cumulative Layout Shift?

CLS is caused by elements moving unexpectedly after the page loads — usually images without defined dimensions, ads that load late, web fonts that swap, or dynamically injected content. Reserve space for all dynamic content using CSS aspect-ratio or min-height.

Two metrics are amber and one is green. Does the page pass?

No. All three metrics must be Good for a page to pass the Core Web Vitals assessment — there is no partial credit. An excellent CLS earns nothing while LCP sits above 2.5s. Keep it in proportion, though: Core Web Vitals are a real but modest ranking signal, closer to a tiebreaker than a lever, and a fast page with a worse answer will still generally lose to a slow page with a better one.

Is 3.8s what most of my visitors experience?

No — it is the 75th percentile of real visits, not the average. The median visitor may be well under it; the slowest quarter, on older phones and worse connections, are at 3.8s or beyond, and they are who the threshold exists to protect. Note also that the field data is a 28-day rolling window, so a fix deployed today will not be fully reflected for about four weeks, and low-traffic URLs with no field data of their own inherit origin-level figures from the site as a whole.

How do I diagnose a poor INP score?

Break the interaction into three phases, because they need opposite fixes. Input delay means the main thread was already busy when the tap arrived — fix by not running third-party code during load. Processing time is your own event handler blocking — fix by yielding, so the browser can paint between chunks of work rather than after all of it. Presentation delay is the re-layout and paint afterwards, usually caused by a large DOM update.

Why do e-commerce product pages fail INP so often?

Because they accumulate third-party JavaScript — analytics, tag manager, chat, reviews, recommendations, personalisation, A/B testing, heatmaps, consent, and advertising pixels — and every one of them runs on the same single main thread that must respond when someone taps Add to Cart. Third-party code cannot be optimised, only deferred or removed. Audit the tag manager first; there is nearly always a pixel from a campaign that ended years ago, still executing on every page view.