Core Web Vitals explained: LCP, INP and CLS for business websites

What are Core Web Vitals?

[Core Web Vitals](/glossary#core-web-vitals) are a set of three metrics Google uses to describe how a page feels to real visitors: how quickly the main content appears, how quickly the page responds when someone taps or types, and whether things jump around while it loads. web.dev (opens in a new tab) lists LCP, INP and CLS as the current stable set.

These bands match Google's Search Console Core Web Vitals report (opens in a new tab). INP replaced First Input Delay (FID) as a Core Web Vital in March 2024 (opens in a new tab).

What does 'at the 75th percentile' mean?

Google recommends measuring at the 75th percentile of page loads, segmented across mobile and desktop. In plain terms: line up every visit from slowest to fastest experience, and look at the point three-quarters of the way along. If that visit meets the threshold, at least 75% of visits did.

This matters because an average hides your slowest visitors, often people on older phones or weak mobile connections. It also means one fast test on your office Wi-Fi tells you very little about how the page performs for customers.

LCP: why the main content loads slowly, and how to fix it

[LCP](/glossary#lcp) reports the render time of the largest image, text block or video visible in the viewport. On most business sites it is the hero image or the main heading. web.dev's LCP optimisation guide (opens in a new tab) splits it into four parts: time to first byte, resource load delay, resource load duration and element render delay.

• Slow server response. Reduce redirects, use caching and a CDN, and check that caching is not bypassed by unique query strings.
• The hero image is found late. Put it directly in the HTML rather than loading it through CSS or JavaScript, and give it fetchpriority="high".
• The hero image is lazy-loaded. web.dev says never to lazy-load your LCP image.
• Large image files. Serve correctly sized images in modern formats such as AVIF or WebP.
• Render-blocking CSS and scripts. Defer non-critical CSS and avoid synchronous scripts in the page head.

INP: why the page feels sluggish, and how to fix it

[INP](/glossary#inp) assesses how quickly a page responds to clicks, taps and key presses throughout a visit; hovering and scrolling do not count. The value reported is the longest interaction observed, ignoring outliers. According to web.dev (opens in a new tab), each interaction has three phases: input delay, processing time and presentation delay.

• Long JavaScript tasks block the main thread. Break them up and yield to the main thread so the browser can respond and paint, as described in web.dev's INP optimisation guide (opens in a new tab).
• Heavy event handlers. Do the minimum needed to update the screen, then run the rest later.
• Very large pages. web.dev notes that large DOMs need more work to render; simplify markup and load off-screen content later.
• Too many third-party scripts. Chat widgets, tag managers, trackers and sliders all compete for the main thread. Remove what you do not use.

CLS: why content jumps around, and how to fix it

[CLS](/glossary#cls) measures the largest burst of unexpected layout shifts during a page's life. Shifts within 500 milliseconds of a tap, click or key press are excluded, because the user expects something to change. web.dev (opens in a new tab) names images or videos with unknown dimensions, fonts that render at a different size from their fallback, and third-party ads or widgets that resize themselves as common causes.

1. 1Always set width and height attributes on images and videos, or reserve space with CSS aspect-ratio.
2. 2Reserve space for ads, embeds, cookie banners and late-loading content, for example with min-height.
3. 3Avoid inserting new content above content the user is already reading.
4. 4Choose a fallback font close to your web font and use font metric overrides to reduce the difference.
5. 5Animate with CSS transform rather than changing top, left, width or height.

web.dev's CLS optimisation guide (opens in a new tab) also recommends making pages eligible for the browser's back/forward cache, so returning visitors see the page restored instantly without repeat shifts.

Field data vs lab data: which numbers count?

Field data comes from real visitors. Lab data comes from a test run on one simulated device and network. web.dev is clear that lab measurement is useful but not a substitute for field measurement.

Two caveats. First, lab tools cannot measure INP because nobody interacts with the page, so Lighthouse uses Total Blocking Time as a stand-in. Second, CrUX only includes pages and sites with enough eligible traffic, so a new or small site may show no field data at all.

How to measure your site step by step

1. 1Run your home page and your most important landing page through PageSpeed Insights, on mobile first.
2. 2Read the field data section. PageSpeed Insights passes a page only if all metrics with enough data are good at the 75th percentile; if INP lacks data, LCP and CLS decide the result.
3. 3Open the Core Web Vitals report in Search Console to see which page groups fail on mobile and desktop.
4. 4Use the lab section and Chrome DevTools to find the specific cause on a failing template.
5. 5Fix, deploy, then use Search Console's validation, which runs a 28-day monitoring session before marking an issue fixed.

Field data lags behind your changes, because it covers the previous 28 days of visits. Do not judge a fix the day after release.

Do Core Web Vitals affect Google rankings?

Google says Core Web Vitals are used by its ranking systems and recommends achieving good scores for success with Search (opens in a new tab). It also says good results do not guarantee top rankings (opens in a new tab), and that Google Search always seeks to show the most relevant content, even if the page experience is sub-par.

Treat speed as part of a good website, not a ranking trick. Faster, steadier pages are easier to use, and that helps whether a visitor comes from search, ads or an AI assistant.

What to put in a website contract

'The site will load in under two seconds' sounds clear but is not measurable: on which device, network, page, and by which tool? A useful performance clause defines four things.

• The target: for example, LCP of 2.5 s or less, INP of 200 ms or less and CLS of 0.1 or less at the 75th percentile, on mobile and desktop.
• The measurement method: CrUX field data in PageSpeed Insights or Search Console once enough data exists, and an agreed Lighthouse lab test on named pages at handover, since field data needs time to build.
• The scope: which templates are covered, such as home, service, product and contact pages.
• The exclusions and remedy: what happens if third-party scripts or content added after launch cause a failure, and how long the developer has to fix a defect they introduced.

Every StudAI Works build includes 30 days of defect fixes after launch. For ongoing monitoring and fixes, see our maintenance and support service, or run our free website and AI search check for a quick read-out.