Core Web Vitals Explained: LCP, INP and CLS, and How to Improve Them

Core Web Vitals are three measurements of how a page feels to real visitors: how quickly the main content appears (LCP), how quickly the page responds to taps and clicks (INP), and how much the layout jumps around (CLS).

They matter for two reasons. Slow, jumpy pages lose visitors, and Google says good Core Web Vitals align with what its core ranking systems seek to reward. This guide explains each metric, the difference between field and lab data, and where to focus first.

The three metrics and their thresholds

Metric	Measures	Good	Needs improvement	Poor
Largest Contentful Paint (LCP)	Loading: when the largest image or text block appears	≤ 2.5 s	≤ 4 s	> 4 s
Interaction to Next Paint (INP)	Responsiveness: delay between an interaction and the next visual update	≤ 200 ms	≤ 500 ms	> 500 ms
Cumulative Layout Shift (CLS)	Visual stability: unexpected layout movement	≤ 0.1	≤ 0.25	> 0.25

INP replaced First Input Delay (FID) and became a stable Core Web Vital in 2024. All three are measured at the 75th percentile of page loads, segmented by mobile and desktop, so a page passes only if most real visits are good.

Field data vs lab data

	Field (real users)	Lab (simulated)
Sources	CrUX, Search Console report, PageSpeed Insights field section	Lighthouse, PageSpeed Insights lab section, DevTools
Measures INP?	Yes	No (uses Total Blocking Time as a proxy)
Best for	Knowing whether you pass	Diagnosing why and testing fixes
Limits	Needs enough Chrome traffic; 28-day window	One device and network profile; results vary between runs

Google’s web.dev guidance is that only field measurement captures the complete picture. New or low-traffic sites often have no field data: PageSpeed Insights shows “No Data” and the Search Console report omits URLs without enough reporting data. In that case use lab tests for direction, but don’t claim you pass or fail.

Do Core Web Vitals affect rankings?

Google says good Core Web Vitals, along with other page experience aspects, align with what its core ranking systems seek to reward, and it highly recommends achieving them. In practice they work more like a tiebreaker than a trump card: a fast page with weak content won’t outrank a slower page that answers the query far better. Treat them as a user experience and conversion priority first.

How to improve LCP

web.dev breaks LCP into four parts: time to first byte, resource load delay, resource load duration and element render delay. The two delays should be close to zero.

• Find the LCP element in PageSpeed Insights (often the hero image or the first heading).
• Don’t lazy-load it. web.dev says never to lazy-load the LCP image.
• Make it discoverable in the initial HTML and add fetchpriority="high" (on one or two images at most).
• Cut render-blocking CSS and JavaScript: remove unused CSS, inline critical CSS, defer scripts.
• Shrink the resource: right-sized images in WebP or AVIF; fewer, smaller web fonts.
• Speed up the server: page caching, a CDN, fewer redirects.

How to improve INP

INP covers three phases: input delay (the main thread is busy), processing (your event handlers run) and presentation delay (the browser renders the update).

• Reduce long JavaScript tasks during page load; audit third-party scripts and remove what you don’t need.
• Keep event handlers small and yield to the main thread between chunks of work.
• Defer non-urgent work (analytics, saving drafts) until after the visual update.
• Keep the DOM reasonably small and avoid reading layout right after changing styles.
• Use content-visibility for long pages with heavy off-screen sections.

How to improve CLS

• Set width and height (or CSS aspect-ratio) on images, videos and iframes.
• Reserve space for ads, embeds, cookie banners and late-loading widgets with min-height.
• Insert dynamic content below the fold, or in reserved space, not above existing content.
• Animate with transform rather than top or left.
• Use font-display: optional or matched fallback font metrics to limit font-swap shifts; preload key fonts.
• Keep pages eligible for the back/forward cache.

Tracking progress

1. Use Search Console’s Core Web Vitals report to see which URL groups are Poor or Need improvement on mobile and desktop.
2. Fix one template at a time (product, category, article) since URL groups usually share a template.
3. Test fixes with PageSpeed Insights lab data and record before/after numbers.
4. Click Start tracking in Search Console; Google monitors for 28 days. It doesn’t trigger reindexing.

For a broader view of technical health, start with the technical SEO checklist. Speed work on WordPress often comes down to caching, CSS and plugin choices; our WordPress SEO service covers that.

Frequently asked questions

Sources

• Google Search Central: Understanding Core Web Vitals and Google search results
• Search Console Help: Core Web Vitals report
• web.dev: Web Vitals
• web.dev: Optimize Largest Contentful Paint
• web.dev: Optimize Interaction to Next Paint
• web.dev: Optimize Cumulative Layout Shift

Last reviewed October 12, 2026.