Core Web Vitals Explained:LCP, INP and CLS

Core Web Vitals are three metrics Google uses to describe real users' experience of a page:

• Largest Contentful Paint (LCP): how quickly the main content appears. Good: 2.5 seconds or less.
• Interaction to Next Paint (INP): how quickly the page responds to clicks, taps and key presses. Good: 200 milliseconds or less.
• Cumulative Layout Shift (CLS): how much the layout jumps around unexpectedly. Good: 0.1 or less.

A page passes when at least 75% of visits meet each "good" threshold. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.

Field data vs lab data

• Field data comes from real Chrome users (the Chrome UX Report), shown in PageSpeed Insights and Search Console. This is what Google uses for its page experience assessment.
• Lab data comes from a simulated test (Lighthouse). It is useful for debugging but does not capture real users' devices and networks, and it cannot measure INP directly (Total Blocking Time is a lab proxy).

Use field data to know whether you have a problem, and lab tools to find out why.

LCP: loading the main content

The LCP element is usually a hero image, a large heading or a video poster.

Common causes of poor LCP:

• slow server response (high Time to First Byte); see why is my website slow;
• a large, unoptimised hero image;
• the hero image being lazy-loaded or discovered late (for example set as a CSS background);
• render-blocking CSS and JavaScript;
• web fonts delaying text display.

Fixes: cache pages, compress and correctly size the hero image, do not lazy-load it, add fetchpriority="high", preload it if it is discovered late, reduce render-blocking resources, and use font-display: swap for fonts.

INP: responsiveness

INP measures the delay between a user's interaction and the next visual update.

Common causes of poor INP:

• long JavaScript tasks blocking the main thread;
• heavy third-party scripts (chat widgets, trackers, ads);
• expensive event handlers and large DOM updates;
• very large DOM sizes, common with page builders.

Fixes: remove or delay unnecessary scripts, break long tasks into smaller ones, keep event handlers light, reduce DOM size, and avoid running heavy work immediately after interactions.

CLS: visual stability

Common causes of layout shifts:

• images and videos without width and height;
• ads, embeds and banners inserted without reserved space;
• web fonts that change text size when they load;
• content injected above existing content (cookie bars, promotions).

Fixes: set dimensions or aspect-ratio on media, reserve space for ads and embeds, use font fallbacks with similar metrics, and add new content below the user's current position or in overlays.

How to measure and monitor

1. PageSpeed Insights for a page's field and lab data.
2. Search Console → Core Web Vitals report for groups of URLs across the site.
3. Chrome DevTools Performance panel to investigate long tasks and layout shifts.
4. The web-vitals JavaScript library to collect real-user data in your own analytics.

Worked example: fixing a failing LCP on a home page

PageSpeed Insights reports an LCP of 4.1 seconds for mobile users on a business home page. The investigation:

1. Identify the LCP element. The report's diagnostics name it: the hero banner image.
2. Check how it loads. The image is 2.4 MB, 3000 pixels wide, set as a CSS background, and lazy-loaded by a plugin.
3. Fix the image: resize to 1600 pixels wide, compress and convert to WebP (about 180 KB), and provide a smaller version for phones with srcset.
4. Fix how it is discovered: use a normal img element instead of a CSS background, remove lazy loading for it, and add fetchpriority="high".
5. Check server response: TTFB is 0.9 seconds because the page is not cached; enabling page caching brings it to about 0.2 seconds.
6. Re-measure: the lab LCP falls to about 1.8 seconds. Field data updates over the following weeks as real visits are collected.

The same pattern (find the element, then fix its size, discovery and the server response) solves most LCP problems.

Monitoring over time

Core Web Vitals can regress whenever someone adds a plugin, a tracking script or a large image. Keep an eye on:

• the Search Console Core Web Vitals report monthly;
• a lab test of key pages after significant changes;
• real-user data in your own analytics if you collect it.

How much do Core Web Vitals matter for ranking?

Google uses page experience signals, including Core Web Vitals, as part of its ranking systems, but relevance and content quality matter much more. Good Core Web Vitals mainly matter because they reflect a better experience for visitors, which affects conversions and engagement.

Frequently Asked Questions

Why do my lab and field results differ?

Lab tests use one simulated device and network; field data reflects your real visitors' devices, networks and behaviour.

Does hosting affect Core Web Vitals?

Yes, mainly through server response time, which feeds into LCP. Front-end issues affect INP and CLS more.

My site has no field data. What now?

Smaller sites may not have enough Chrome traffic. Use lab tools and real-user measurement in your own analytics instead.

Related reading

For WordPress-specific fixes, see how to speed up a WordPress website. For the overall build approach, see how to plan a website project. If hosting turns out to be the bottleneck, compare the plans on ServerNeed cloud hosting.

Sources

• web.dev: Web Vitals
• web.dev: Interaction to Next Paint (INP)
• Google Search Central: Core Web Vitals