How to Fix Core Web Vitals: LCP, INP & CLS

Core Web Vitals are three metrics Google uses to measure how fast, responsive, and stable your pages feel to real users: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). To pass, you need a "good" score on all three for 75% of your traffic. This guide shows you what each metric means and the exact fixes that move it.

What You'll Learn

• What LCP, INP, and CLS measure, and the "good" threshold for each
• The specific fixes that improve each metric, in priority order
• How to tell field data from lab data, and why the difference matters
• How much Core Web Vitals really affect your Google rankings
• Which fixes you can own as a marketer, and which need a developer

What Core Web Vitals Actually Measure

Core Web Vitals score three things: loading, responsiveness, and visual stability. Google measures them from real Chrome users through the Chrome User Experience Report (CrUX), then reports the 75th percentile, meaning 75% of your visits must hit the "good" mark. Here are the thresholds straight from Google's web.dev documentation.

Metric	What it measures	Good	Needs work	Poor
LCP	Loading: when the largest element appears	2.5 s or less	2.5-4.0 s	Over 4.0 s
INP	Responsiveness: delay after an interaction	200 ms or less	200-500 ms	Over 500 ms
CLS	Visual stability: unexpected layout shifts	0.1 or less	0.1-0.25	Over 0.25

Thresholds: web.dev (Google), metric definition pages. One note on history: INP replaced First Input Delay (FID) as a Core Web Vital in 2024, so older guides that mention FID are out of date.

Field data vs. lab data

Two kinds of data measure these metrics, and only one counts for rankings. Field data comes from your actual visitors and feeds CrUX, which is what Google uses. Lab data comes from a single simulated test in a tool like Lighthouse. Lab data is great for debugging, but a perfect lab score won't pass you if real users still struggle.

How Much Do Core Web Vitals Affect Rankings?

Core Web Vitals are a ranking input, not a decisive one. Google confirms its ranking systems use Core Web Vitals, but good scores don't guarantee higher rankings, and Search still shows the most relevant content even when page experience is poor (Google Search Central). Treat Core Web Vitals as a tiebreaker and a genuine user-experience win, not a shortcut past better content.

How to Fix LCP (Largest Contentful Paint)

LCP is "good" at 2.5 seconds or less. It measures when the largest visible element, usually your hero image, headline, or a big block of text, finishes loading. Google splits LCP into four parts: server response time, resource load delay, resource load time, and render delay (web.dev). Work through these in order.

1. Speed up your server response. Use quality hosting, a content delivery network (CDN), and caching so the first byte of your page arrives fast. A slow server delays everything after it.
2. Make the LCP element easy to find. The browser can't load what it can't see early. Put the hero image directly in the HTML rather than loading it with a script, and ask your developer to add a fetchpriority="high" or preload hint so it loads first.
3. Shrink the LCP resource. Compress your images and serve modern formats like WebP or AVIF. Size each image to the space it fills, and serve it from a CDN.
4. Cut render-blocking code. Large CSS and JavaScript files delay the first paint. Minify them, defer non-critical scripts, and remove code you don't use.

For most marketing sites, LCP problems trace back to heavy images or slow hosting, which are also the two easiest wins.

How to Fix INP (Interaction to Next Paint)

INP is "good" at 200 milliseconds or less. It measures how quickly your page responds after a user taps, clicks, or types, across the whole visit rather than just the first interaction. Slow INP almost always means JavaScript is hogging the main thread, the single lane the browser uses to respond (web.dev).

1. Break up long tasks. Long JavaScript tasks block the browser from responding. Split heavy work into smaller chunks and yield to the main thread so the page can react between them.
2. Ship less JavaScript. Every script competes for the same thread. Audit your third-party tags, because chat widgets, heatmaps, and ad scripts are common culprits, and remove what you don't need.
3. Keep interaction handlers light. When someone clicks, show the visible change first, then handle the rest afterward. Defer analytics and non-urgent logic so they don't delay the response.
4. Reduce page complexity. A very large DOM (too many elements on the page) slows every interaction. Simplify templates and use content-visibility to skip rendering off-screen sections.

INP is the metric most marketing teams fail, because tag managers and third-party scripts pile up over time. A tag audit is often the single biggest fix.

How to Fix CLS (Cumulative Layout Shift)

CLS is "good" at 0.1 or less. It measures how much your content jumps around while the page loads, the annoying shift that makes you tap the wrong button. Most CLS comes from elements that load without reserved space (web.dev).

1. Set dimensions on images and video. Always include width and height attributes (or a CSS aspect-ratio) so the browser reserves the right space before the file loads.
2. Reserve room for ads, embeds, and banners. Give dynamic slots a fixed size. Avoid inserting content above what's already on screen unless the user asked for it, and push late-loading content lower.
3. Fix your fonts. A late-swapping web font can reshuffle your text. Use font-display: optional or a well-matched fallback font, and align its size with size-adjust so the swap stays invisible.
4. Animate the right way. Animate with CSS transform instead of properties like top or left, which force the layout to shift.

CLS is usually the fastest to fix, often just adding image dimensions and reserving ad space.

A Simple Fix Order for Marketers

Start where the pain is. Pull your field data first, then fix the metric that's failing for the most users. If you're starting cold, this order wins fastest for most sites.

1. CLS quick, cheap, and high visible impact
2. LCP compress images and improve hosting
3. INP audit third-party scripts and tags

You can own image compression, tag audits, and content decisions yourself. Loop in a developer for preload hints, code splitting, and font tuning. A clear brief like "our LCP is 4.2 seconds on mobile, mostly from the hero image" gets you a faster fix than "make the site faster."

How to Measure Your Progress

Measure with field data, because that's what Google scores. Google's free PageSpeed Insights shows both your CrUX field data and a lab test in one report. Because field data is collected from real users over a rolling window of several weeks, your fixes won't show up instantly, so expect to wait before scores update (web.dev, CrUX documentation). Keep shipping fixes and let the data catch up.

Frequently Asked Questions

Are Core Web Vitals a Google ranking factor?

Yes, but a minor one. Google confirms its ranking systems use Core Web Vitals, yet good scores don't guarantee higher rankings, and relevant content still ranks even with poor page experience (Google Search Central). Fix them for users first, and treat the ranking benefit as a bonus.

What's the difference between field data and lab data?

Field data comes from real visitors and feeds Google's CrUX report, which is what counts for rankings. Lab data comes from a single simulated test like Lighthouse and is best for debugging. A page can pass in the lab but still fail in the field.

How long until my Core Web Vitals fixes show up?

Field scores update over a rolling window of real-user data, so expect several weeks, not days, after you deploy a fix. Lab tools show the change immediately, which helps you confirm a fix works while you wait for field data to move.

Do I need a developer to fix Core Web Vitals?

Not always. Marketers can compress images, audit third-party tags, and reserve space for ads on their own. Deeper fixes like code splitting, preload hints, and font tuning usually need a developer. A specific brief speeds up both.

Which Core Web Vital should I fix first?

Fix the one failing for the most real users, which you'll see in your field data. With no data to guide you, CLS is usually the quickest win, followed by LCP (images and hosting) and INP (script and tag cleanup).

The Bottom Line

Core Web Vitals reward the same thing your visitors want: pages that load fast, respond instantly, and hold still. Hit 2.5 seconds or less on LCP, 200 milliseconds or less on INP, and 0.1 or less on CLS for 75% of your traffic, and you've built a genuinely better experience with a modest ranking upside on top. Start with your field data, fix the biggest failure first, and measure again in a few weeks.

Sources

• Web Vitals web.dev (Google): https://web.dev/articles/vitals
• Largest Contentful Paint (LCP) web.dev: https://web.dev/articles/lcp
• Interaction to Next Paint (INP) web.dev: https://web.dev/articles/inp
• Cumulative Layout Shift (CLS) web.dev: https://web.dev/articles/cls
• Optimize Largest Contentful Paint web.dev: https://web.dev/articles/optimize-lcp
• Optimize Interaction to Next Paint web.dev: https://web.dev/articles/optimize-inp
• Optimize Cumulative Layout Shift web.dev: https://web.dev/articles/optimize-cls
• Understanding page experience in Google Search Google Search Central: https://developers.google.com/search/docs/appearance/page-experience
• Overview of CrUX Chrome for Developers: https://developer.chrome.com/docs/crux