Core Web Vitals: a business guide to website performance

Understand the three experiences being measured

Core Web Vitals describe three aspects of a page's experience. Largest Contentful Paint, or LCP, concerns when the largest eligible visible content element is rendered. Interaction to Next Paint, or INP, concerns the responsiveness of interactions. Cumulative Layout Shift, or CLS, concerns unexpected movement of content. They help turn “the site feels slow” into a more precise discussion.

The current good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1. A full assessment uses the 75th percentile, separated for mobile and desktop, with all three meeting their recommended thresholds. These definitions and targets are published in Google's Web Vitals guidance.

A simple way to interpret the percentile is that at least three quarters of the measured experiences should fall within the good threshold for that metric. It is not an average and it does not mean three quarters of the site's pages passed. Keep that distinction visible in reporting. Otherwise a team may celebrate a fast homepage while a heavily used service template continues to frustrate visitors.

Read the label on the evidence

Field data comes from real visits, with the devices, connections and behaviour those visits involve. Lab data comes from a controlled test. Both are useful, but they answer different questions. Field data shows what happened across measured experiences; a lab test helps reproduce conditions and investigate a particular cause.

A standard Lighthouse page-load test does not include the visitor interactions needed to measure INP. It reports Total Blocking Time as a useful diagnostic instead; that is not a substitute INP result. The distinction appears in the official measurement guidance. Interactive developer tools and scripted journeys can provide further laboratory evidence, but still do not represent the full distribution of visitors.

When sharing a report, include the source, date range, device category and whether it describes a URL or a broader origin. PageSpeed Insights field data covers the previous 28 days and may fall back to origin data when a page has insufficient samples. Its assessment can pass on good LCP and CLS when INP data is insufficient, so read the metric coverage as well as the label. Missing field data does not establish good performance. You can still use controlled tests and appropriate real-user measurement.

Investigate what delays the main content

For a slow LCP, begin with the element being measured. It might be the opening photograph, a large heading or another visible element. Then inspect the sequence: how long did the server take to respond, when did the browser discover the resource, how long did transfer take, and what prevented it from being displayed?

Consider a restaurant site whose first photograph is inserted only after a large script runs. Compressing that image helps its transfer, but the browser still waits to discover it. The improvement may require making the image available earlier in the page. Likewise, web.dev advises against lazy-loading the LCP image, because that introduces avoidable discovery delay.

Ask the technical team to explain the main delay before approving a broad optimization package. A faster hosting plan will not necessarily fix a late-discovered image, and a new image format will not resolve a blocking script. Preserve the visual intention while adjusting delivery: use appropriately sized image variants, reserve the intended space and prioritize only genuinely important resources. Giving everything high priority removes the value of the distinction.

Measure the moments when people act

A page can look complete while responding poorly to input. Test the menu during initial loading, a filter after several selections, a long form and a booking interaction. Ask what the visitor sees immediately after acting. An unresponsive button often encourages repeated clicks, which can make a difficult interaction more confusing.

For INP problems, the technical investigation should examine the work surrounding the delayed interaction. Large JavaScript tasks can occupy the browser's main thread and postpone a response. The official INP optimization guide discusses reducing input delay, simplifying event work and breaking up long tasks. The right change depends on the observed interaction.

For example, a service filter might rebuild an entire large listing after every keystroke. A more focused update may preserve the same functionality with less work. A third-party chat tool may add work during a visitor's first attempt to open navigation. Delaying that tool until it is useful may be worth testing. Judge each proposal by its effect on the task, including clear loading and error feedback, rather than by the amount of code removed.

Protect the place where a visitor is reading

Layout instability is particularly visible when a visitor is about to select something. An image arrives, a banner appears, or a font changes the text wrapping, and the intended target moves. The page may be fully functional, yet the experience feels unfinished because its arrangement cannot be trusted.

Start by reserving space for images, video embeds and other late-arriving elements. Providing image dimensions helps the browser allocate space before the image loads, as explained in web.dev's image loading guidance. Review the site's actual content ratios, rather than giving every image an arbitrary fixed box that crops important information.

Then test font loading, announcement bars and widgets. A page with a dismissed consent banner may behave differently from a first visit. A case study with no embedded video may miss a problem present on the next one. Observe the full journey, including scrolling, because a short initial screenshot cannot reveal later shifts. Fix the shared source of movement where possible so the improvement reaches every affected template.

Ask for a finding that can become a task

A useful performance report should leave the team knowing what to investigate next. For each priority finding, record the URL or page type, device context, evidence source, affected task and suspected cause. “Mobile performance is weak” is not specific enough to price or verify. “The main project image is discovered late on the case-study template” points toward a reproducible investigation.

Ask the developer to preserve a before-and-after record under comparable conditions. Include the change made and any tradeoff, such as lowering image transfer size while retaining enough detail at the intended display width. A single improved laboratory result is useful diagnostic evidence; continue watching the relevant field measurement when sufficient data becomes available.

Prioritize a delay that obstructs a common inquiry journey before optimizing an incidental animation. Then put the agreed constraints into a performance budget so the next upload or third-party tool does not undo the work. Performance review becomes an operating habit when findings have owners and a clear way to check them.

Turn the report into a manageable improvement plan

Build a small table of important page types, the affected metric, evidence, likely cause and person responsible. Choose priorities using both visitor impact and the confidence of the diagnosis. A frequently used enquiry journey deserves attention even when an easier homepage adjustment would produce a more attractive presentation score.

1. Capture a baseline using documented test conditions and available field data.
2. Reproduce the issue on the relevant page or interaction.
3. Make a focused change with a clear expected effect.
4. Repeat the same controlled test and check related functionality.
5. Observe new field data over time, allowing for the reporting window.
6. Add an appropriate regression check to the release process.

Keep broader experience questions alongside these metrics. Passing Core Web Vitals does not establish that the writing is clear, navigation is accessible or an enquiry reaches the business. Nor does a score promise a particular search position or conversion improvement. The useful outcome is a site that shows its content promptly, responds when asked and holds its layout steady while people make decisions.