Most Core Web Vitals advice is a list. Compress your images, defer your JavaScript, use a CDN. The list is not wrong, but it is not useful either, because at any given moment a slow page has one dominant constraint and the other nineteen items on the list will not move the number until that constraint is removed.

This is a guide to finding the constraint. It covers what the three metrics measure, what actually causes each to fail on business websites, and how to tell the difference between a fix that will change your field data and a fix that will only change your Lighthouse score.

The three metrics and their thresholds

Core Web Vitals are three metrics with published "good" thresholds, each assessed at the 75th percentile of real page loads and segmented across mobile and desktop. The 75th percentile matters: it means a quarter of your visitors can have a worse experience than your reported number.

  • Largest Contentful Paint (LCP) measures loading. Good is 2.5 seconds or less. It records when the largest text block or image in the viewport finishes rendering.
  • Interaction to Next Paint (INP) measures interactivity. Good is 200 milliseconds or less. It records the latency of interactions across the whole page visit, not just the first one – it replaced First Input Delay for exactly that reason.
  • Cumulative Layout Shift (CLS) measures visual stability. Good is 0.1 or less. It records how much visible content moves unexpectedly during the page's life.

Lab data and field data are answering different questions

This is the distinction that most performance work gets wrong, and it wastes more effort than any technical mistake.

Lab tools – Lighthouse, WebPageTest, the Performance panel – load your page once, on a simulated device, on a simulated network, with no cache and no real user behaviour. They are diagnostic instruments. They are very good at telling you why something is slow, because they can isolate a single variable and show you a waterfall.

Field data – the Chrome User Experience Report, and any real-user monitoring you run yourself – records what actually happened to actual visitors on their actual devices and connections. It is the measurement that reflects your business, and it is the one search engines use.

The practical consequence: a perfect Lighthouse score tells you almost nothing on its own. Sites with a 100 in the lab and poor field data are common, usually because the lab test measures a cached, logged-out, empty-cart home page while real visitors arrive on a heavy category page with a personalisation script running.

LCP: it is almost always one of four things

LCP failures decompose neatly. The metric can be broken into four sub-parts, and on any given page one of them dominates. Identifying which one tells you what to fix and, just as usefully, what not to bother with.

  1. Time to first byte. The server took too long to respond. No amount of frontend optimisation compensates for this. Causes are usually an uncached database query, a slow origin, or no CDN in front of a distant server. If TTFB is a large share of your LCP, everything else is a rounding error.
  2. Resource load delay. The browser knew about the page but did not start loading the LCP element promptly. This is the most commonly missed cause. It happens when the hero image is lazy-loaded, when it is referenced from CSS rather than HTML, when it is injected by JavaScript, or when it sits behind a carousel that initialises on load.
  3. Resource load time. The LCP element itself is too large. An unoptimised photograph served at desktop resolution to a phone is the classic case, and it is the one everyone thinks of first – which is why it is often the only one addressed.
  4. Element render delay. The resource arrived but could not be painted. Render-blocking CSS, a render-blocking web font the text depends on, or a client-rendered page waiting on a JavaScript bundle.

The most reliable structural fix is to make the LCP element text rather than an image. Text rendered in a system font has no download, no decode, and no dependency other than the CSS. It is why a well-built content site with a typographic hero will frequently beat a beautifully art-directed one on this metric without trying.

If the LCP element must be an image, the priorities are: reference it in the HTML, do not lazy-load it, mark it fetchpriority="high", serve it in a modern format at correct responsive sizes, and give it explicit dimensions.

INP: the problem is main-thread work, not "slow JavaScript"

INP measures the time from a user interaction to the next frame being painted. It is a whole-visit metric, so a page that feels fine on first load and degrades as scripts accumulate will fail it even though the initial load looked good.

The failure is nearly always the same shape: the browser's main thread is busy with something else when the user taps, so the interaction has to wait its turn before it is even processed.

Three causes account for the large majority of INP problems on business websites.

  • Third-party scripts. Tag managers, chat widgets, session recording, A/B testing frameworks and marketing tags. Each one is code you did not write, running on your main thread, that can change without warning. This is by a wide margin the most common cause on marketing sites.
  • Long tasks during hydration. Sites that ship a JavaScript framework to render content that could have been static HTML spend a long, uninterruptible stretch of main-thread time making an already-rendered page interactive. Any tap during that window is queued.
  • Expensive event handlers. A handler that reads layout, writes to the DOM, and reads it again forces synchronous reflow. Scroll and input handlers are the usual offenders.

The most valuable INP work is usually subtraction. Audit every third-party script, measure what each one costs in main-thread time, and put the list in front of whoever owns the marketing stack. In our experience a meaningful proportion of the tags on any mature site are for tools nobody has opened in a year, and removing those is the cheapest performance work available.

Where a script must stay, the options are to load it later, to load it on interaction rather than on load, or to accept the cost knowingly. All three are better than not knowing.

CLS: nearly all of it is preventable at build time

CLS is the easiest of the three to fix and the easiest to reintroduce, because almost every cause is a missing declaration rather than an architectural problem.

  • Images and video without dimensions. Set width and height attributes, or an aspect-ratio in CSS, so the browser reserves the space before the file arrives.
  • Web fonts. When a fallback font is swapped for a webfont with different metrics, every line of text moves. Matching fallback metrics with size-adjust helps; using a system font stack removes the problem entirely.
  • Content injected above existing content. Cookie banners, announcement bars, personalisation blocks and late-loading ads. If it must appear, reserve its space in the initial layout.
  • Dynamically resized containers. Accordions, tabs and lazily-hydrated components that change height after load.

One nuance worth knowing: layout shifts within 500 milliseconds of a user interaction are excluded from the metric, because a shift you caused by tapping something is expected. That exclusion is for user-initiated change, not a licence to defer your banner.

How to prioritise when the audit has twenty items

A performance audit will always produce more findings than you will act on. The sequence that works is narrow and boring.

  1. Get field data first, segmented by page template and by device. Fix the template that carries the traffic or the revenue, not the home page by default.
  2. Identify which metric is actually failing. Do not optimise LCP if your problem is INP; they have almost no fixes in common.
  3. For LCP, break it into the four sub-parts and address the dominant one. For INP, audit third-party scripts before writing any code. For CLS, check dimensions and injected content.
  4. Fix the single dominant constraint, then measure again. Performance has a moving bottleneck – the second-biggest problem is frequently not worth fixing once the first is gone.
  5. Set a budget and enforce it in the build process, otherwise the improvement decays release by release.

What this means commercially

It is worth being precise about why this matters, because performance work is easy to oversell. Core Web Vitals are one input among many in search ranking, and a fast site does not outrank a more relevant slow one. Anyone selling performance work primarily as an SEO tactic is overstating it.

The stronger argument is direct. Every second a page takes to become usable is a period during which some proportion of your visitors leave, and mobile visitors on ordinary connections leave sooner. That effect is measurable in your own analytics, segmented by device, without reference to search rankings at all.

Performance is also cheaper to hold than to recover. A budget agreed before design sign-off costs very little; a remediation project two years later costs a great deal, because by then the causes are load-bearing.