dardo

Core Web Vitals for business websites: use field and lab evidence

Core Web Vitals are measurements of loading, responsiveness and visual stability for real page visits. They help a business find friction in its main task, but a green report does not promise rankings, sales or a universally fast site. Pair current thresholds with a repeatable diagnosis and the conditions in which the page is actually used.

By Dardo studio6 min read

Three metrics, three different problems

Use the 75th percentile of field visits, split by mobile and desktop. A single Lighthouse run can help investigate a defect; it does not establish a field pass. The thresholds below define good Core Web Vitals.

A decision aid
Metric / good thresholdInvestigate
LCP ≤ 2.5 sMain content discovery, server and image delivery
INP ≤ 200 msInput delay, handlers and the next paint
CLS ≤ 0.1Unreserved media, fonts and inserted UI

If field data is unavailable, say so and use repeatable lab tests to investigate. Preserve the design’s purpose while addressing the specific loading delay, long task or layout shift shown in the trace.

  1. 01Field data
  2. 02Trace
  3. 03Fix
  4. 04Validate

Know what the three metrics measure

Largest Contentful Paint, or LCP, measures when the largest image, text block or other eligible element in the viewport is rendered. A good LCP is 2.5 seconds or less; above 4 seconds is poor. Interaction to Next Paint, or INP, measures the delay from a qualifying click, tap or key press until the next visual feedback. A good INP is 200 milliseconds or less; above 500 milliseconds is poor. Cumulative Layout Shift, or CLS, measures unexpected movement of visible content. A good CLS is 0.1 or less; above 0.25 is poor.

These classifications use the 75th percentile of visits, segmented by device where available. A single fast run is not the same as 75 percent of users meeting a threshold. Field data comes from real visits and includes their devices, connections, geography, cache state and behavior. Lab data comes from a controlled Lighthouse run. Record the data source, URL or origin, device class and collection period for every number.

Diagnose LCP as a chain of delays

Suppose a service page reports an LCP of 4.3 seconds on mobile and the LCP element is the hero image. Do not begin by replacing the image blindly. Break the time into the server’s response, the delay before the image request starts, the download itself and the time needed to render it. A slow first byte points toward hosting, server work, the edge or a redirect. A late request can mean the image is hidden behind JavaScript, a CSS background or a low-priority discovery path. A large download can need a correctly sized responsive image, modern compression and a quality target that preserves the message. A long render delay can expose main-thread work, fonts or layout dependencies.

Use PageSpeed Insights and DevTools to identify the LCP element and timing breakdown, then compare with field data. Make the important resource discoverable in the initial HTML, avoid lazy-loading the element visible at the top, reserve its dimensions and deliver the initial document promptly. Re-run the same URL under the same lab conditions, but keep the before value and real-user distribution.

Find the interaction that raises INP

Imagine a Bogotá clinic’s booking page whose date picker feels frozen. A lab trace shows a long task immediately after the tap: a large script recalculates availability, rerenders every appointment row and fires analytics before the next frame. INP includes input delay, event processing and presentation; reducing only the network request may change nothing while the main thread remains blocked. Profile the interaction in DevTools, identify the slow handler and separate urgent feedback from later work. Show the picker opening immediately, then fetch or calculate availability asynchronously. Break long JavaScript tasks, avoid rerendering unrelated rows and defer nonessential third-party tags.

INP observes qualifying interactions throughout the visit, so test the menu, search, filters, forms and checkout controls people actually use. Field attribution or a Real User Monitoring library can identify the element and interaction real users found slow; lab flows can then reproduce it. Scrolling and hovering do not count as INP; without enough interactions, field data may be unavailable. Preserve the business action while reducing the time until its first visible response.

Track down unexpected movement for CLS

Consider a product page whose purchase button moves below a promotional banner after the page appears. Check the image, banner, font and embed that arrived late, rather than blaming the button that moved. Give images and video intrinsic dimensions or reserve space with aspect-ratio. Allocate a known area for an announcement, consent notice, ad or iframe before it loads. Avoid inserting content above the viewport without a planned placeholder. A web font that changes line breaks can move content; use a compatible fallback and load critical fonts deliberately.

Lighthouse often catches shifts during the initial load. Real users may also shift after scrolling, opening a menu or returning through the back/forward cache, so compare lab and field values. In the DevTools Performance panel, inspect layout-shift records and the elements that moved, then reproduce the business journey on a narrow screen. An interaction-triggered change may be expected, but a late network response that pushes a visible control away is still a user problem even if one lab reload missed it. Aim for stable space and clear feedback, not a score obtained by hiding content.

Use lab and field measurements together

Run a lab test before release to create a controlled baseline. Keep the URL, viewport, throttling, browser version and build identifier. Lighthouse can expose opportunities and traces for LCP, INP-related main-thread work and CLS during its scripted load, but it cannot observe every later interaction or network condition. PageSpeed Insights also reports CrUX field data when enough traffic is eligible, usually over trailing 28 days. Confirm whether the value is for the URL or only the origin, and whether mobile and desktop tell different stories.

If field data is worse than the lab, look for devices, connections, third-party tags, post-load shifts or interactions that the script omitted. If lab is worse than field, keep the warning: the sample may be small or biased toward capable devices. Collect your own field attribution when CrUX is too coarse, respecting the site’s privacy design. Compare distributions and 75th percentiles rather than one score, and annotate deployments so a change can be connected to a measurable effect.

Set a business acceptance test without guarantees

Choose the page and task that matter: a service page should load its offer, a catalog should expose a product and a lead form should respond to a tap. Set a target for each metric at the 75th percentile, test on the devices your visitors use and retain a slow-path example for review. Fix the largest verified cause first, then retest the full path so an optimization does not break navigation, analytics, accessibility or the form.

Core Web Vitals are useful signals, not a contract for conversion or search position. A page can meet all three thresholds and still have confusing copy, a broken inquiry route or a slow external payment step. A page can miss one threshold for a low-volume URL while its audience remains satisfied. Report the metric, percentile, segment, date, tool and task, then state the remaining uncertainty. Continuous field monitoring and a small set of repeatable lab journeys make performance an operating practice instead of a launch screenshot.

Sources & further reading

Sources behind this guide, with further detail from the original publishers.

How we publish these guides

Your next read.

Custom web design

Technical SEO diagnostics: trace a page from request to index

How to use motion without making a website exhausting

Have a project in mind?

Let’s talk