Core Web Vitals: what LCP, INP and CLS measure, the thresholds, and what Google says

The three metrics and their thresholds

web.dev recommends judging each metric at the 75th percentile of page loads, segmented across mobile and desktop: a page passes when three out of four visits meet the good threshold.

What Google Search says about them

Google Search Central's page on Core Web Vitals states that they align with what Google's core ranking systems seek to reward. The same page is clear about the limits: good scores do not guarantee top rankings, and relevance remains more important. It points site owners to the Core Web Vitals report in Search Console to see how their pages perform.

So speed is worth fixing, mainly because visitors feel it, and as one signal among many. A fast page that does not answer the search will not outrank a slower one that does.

LCP: making the main content appear fast

According to web.dev, the elements that can count as the largest contentful paint are images (including images inside SVG), the poster image or first frame of a video, elements with a background image loaded through CSS, and block-level elements containing text. On most pages, it is the hero image or the main heading.

• Serve the hero image in a modern format, at the size it is displayed, and do not lazy-load it.
• Avoid making the main content wait for large scripts or a slow server response.
• Load fonts so that text can show before the custom font arrives.
• Keep pages light: every extra script and widget competes with the main content.

INP: making clicks and taps feel instant

INP looks at clicks with a mouse, taps on a touchscreen and key presses; hovering and scrolling are not counted. For most sites, the interaction with the worst latency is reported; on pages with many interactions, one highest interaction is ignored for every 50, to discount random hiccups. web.dev notes that INP is best measured with real users in the field; in the lab, Total Blocking Time can be a reasonable proxy but is not a substitute.

• Cut or defer heavy JavaScript, especially third-party tags.
• Break long tasks so the browser can respond between them.
• Give immediate visual feedback on a click, then do the slower work.

CLS: stopping the page from jumping

web.dev lists the usual causes of layout shifts: images and videos without dimensions, third-party ads and widgets that resize themselves, content injected after load, and web fonts that render differently from their fallback. Shifts that happen within 500 milliseconds of a user's click, tap or key press are excluded, because the user expects them.

• Set width and height (or an aspect ratio) on every image and video.
• Reserve space for banners, embeds and ads before they load.
• Do not insert content above what the visitor is already reading.
• Choose fallback fonts close to the custom font in size.

Field data and lab data

Two kinds of numbers circulate. Field data comes from real visitors and is what the 75th-percentile thresholds above are about. Lab data comes from a test run in a controlled environment; it is useful to debug and to check a change before release, but it is not what your visitors experienced. When the two disagree, trust the field and use the lab to find the cause.

How we build fast sites at Takat

We build fast static websites by default: little JavaScript, images sized and compressed, dimensions set to avoid layout shifts, and no third-party widget without a reason. Our own agency site scores 100 in Lighthouse. A lab score is not a ranking, so we also read the field data in Search Console after launch. See Websites and Audits.