How do you improve Core Web Vitals? LCP, INP and CLS fixes that move the score

Those thresholds come from web.dev's Web Vitals guide, as of September 30, 2026. If you would rather hand the work off, see a performance audit and fixes for your site. The service page puts the timeline at several days to two weeks, depending on site complexity. The rest of this article is the method, step by step.

Short answer: the three thresholds

Each metric has a "good" line and a "poor" line. Everything between them is "needs improvement." Google measures all three at the 75th percentile of page loads, split by mobile and desktop. A page passes only when all three are good at that percentile.

The poor lines come from Google's write-up on defining the Core Web Vitals thresholds, checked on September 30, 2026. INP is the newest of the three. It replaced First Input Delay as a Core Web Vital on March 12, 2024. Old audits that still quote FID are out of date.

Does any of this affect rankings? Google's Search Central page on Core Web Vitals says good scores align with what its core ranking systems seek to reward. It stops short of calling them a deciding factor. Treat them as a tiebreaker and a conversion issue.

Read the right data: field vs lab

Two kinds of data exist. Field data comes from real Chrome users. Lab data comes from a simulated load on one device and one connection. Search Console only looks at field data.

There are three places to read field data:

• Search Console, Core Web Vitals report. It groups similar URLs and shows the 75th-percentile value for each group over the last 28 days, per the Search Console help page as of September 30, 2026. A group's status equals its worst metric.
• PageSpeed Insights, top section. It pulls CrUX data for the URL and the origin. According to the PageSpeed Insights documentation, this data covers a trailing 28-day period and refreshes daily.
• CrUX itself. The Chrome UX Report is the dataset behind both. Its BigQuery tables update monthly and hold origin-level data only.

Then there is the lab score. The big number at the top of PageSpeed Insights is a Lighthouse score from 0 to 100. The docs call 90 or above good and below 50 poor. It is useful, but it is still a single simulated run.

Why the PSI score and field data disagree

This confuses almost everyone at least once: a page scores 45 in the lab and passes in the field. Another scores 92 and fails. Both are normal.

The lab run throttles CPU and network to a fixed profile. Your real visitors might be on fast desktops, or on slow Android phones. Lab tests also cannot measure INP properly, because nobody clicks anything. And CLS in the lab only counts shifts during load. Shifts that happen while a user scrolls show up in field data only.

So use the lab to find causes. Use field data to judge results. Never report the lab score to a client as the verdict.

Fixing LCP: four subparts, four kinds of fix

Google's Optimize LCP guide splits every LCP value into four subparts with no gap or overlap between them. This is the most useful idea in the whole topic. It tells you which fix to try first.

1. Time to First Byte (TTFB). From the request to the first byte of HTML.
2. Resource load delay. From TTFB until the browser starts fetching the LCP image or font.
3. Resource load duration. How long that file takes to download.
4. Element render delay. From download finished to the element actually painting.

The guide suggests a healthy split: roughly 40% TTFB, under 10% load delay, roughly 40% load duration, under 10% render delay. The two "delay" parts should sit near zero. If either one is large, start there.

Chrome DevTools shows the breakdown in the Performance panel. PageSpeed Insights lists the LCP element and its phases too.

What to do for each part:

• High TTFB. Cache full HTML pages at the server or CDN. Cut redirects. Look at slow database queries on uncached pages. Hosting upgrades help only when the server is the actual bottleneck.
• High load delay. The browser found the image late. Put the hero image in the HTML as a normal <img>, not a CSS background or a JavaScript slider. Add fetchpriority="high" to it. If the image is referenced from CSS, preload it with <link rel="preload" fetchpriority="high">. Never lazy-load the LCP image.
• High load duration. The file is too heavy. Serve AVIF or WebP. Size it for the viewport with srcset. Serve it from a CDN close to the user.
• High render delay. Something blocks painting. Usually it is render-blocking CSS or JavaScript, or a script that hides content until it runs. A/B testing tools and hero sliders are frequent offenders.

One trap from the guide deserves a note. Compressing the image does nothing if the element stays hidden until a script loads. The saved time just moves into render delay. Measure the subparts before and after every change.

Fixing INP: long tasks and heavy handlers

INP looks at nearly every interaction during a visit and reports one of the slowest. The Optimize INP guide breaks each interaction into three parts: input delay, processing duration and presentation delay.

The main thread runs one task at a time. Any task over 50 milliseconds counts as a long task, per Optimize long tasks. While it runs, clicks wait.

Start by finding the slow interactions. Field tools that report INP attribution tell you which element was clicked and which script ran. In the lab, record a Performance trace in DevTools while you click the same element.

The usual causes, in the order to check them:

• Third-party scripts. Chat widgets, tag managers, heatmaps, consent tools and ad scripts all compete for the main thread. Audit them first. Remove the ones nobody reads. Delay the rest until after the first interaction or until idle.
• Heavy event handlers. A click handler that updates the screen and also sends analytics, recalculates a cart and writes to storage is doing too much at once. Do the visual update first. Push the rest into a later task.
• Big DOM and expensive rendering. Pages with thousands of nodes make every style recalculation slow. Mega menus and long product grids built all at once are common culprits.

To split work, yield to the main thread. The simplest way is setTimeout, which starts a new task. The newer option is scheduler.yield(), which lets the continuation run ahead of other queued work. Check support before relying on it. As of September 30, 2026, MDN lists scheduler.yield() as limited availability: Chrome 129 and Firefox 142 support it, Safari does not. Use feature detection with a setTimeout fallback.

Fixing CLS: reserve the space

Layout shift is the easiest metric to understand and often the fastest to fix. Content moves because the browser did not know how much room something needed.

The Optimize CLS guide names the usual sources, as of September 30, 2026:

• Images and video without dimensions. Always set width and height attributes, or reserve space with CSS aspect-ratio. This single fix clears many reports.
• Ads, embeds and iframes. Reserve a fixed slot with min-height. Size it for the most common ad size.
• Banners that push content down. Cookie consent bars, promo strips and signup forms injected at the top of the page shift everything below. Overlay them, or reserve their space in advance.
• Web fonts. When the custom font replaces the fallback, text reflows. Use font-display: optional for body text if you can accept the fallback on slow loads. Otherwise tune the fallback with size-adjust, ascent-override and descent-override so both fonts take the same space. Preload the one or two fonts used above the fold.

Remember the scroll shifts. Lazy-loaded blocks without reserved space shift content while the user scrolls. That never shows in a load-only lab test. Field data catches it.

The diagnosis table

Use this table as a working sheet. One row per metric, left to right.

For LCP, map each subpart to its fix before you touch anything:

WordPress-specific fixes

WordPress already helps with the first LCP fix. Since version 6.3, core adds fetchpriority="high" to the image it judges most likely to be the LCP element. The WordPress core team reported that this typically improves LCP by 5–10%. Check that a slider or builder is not overriding it.

The bigger problems sit elsewhere:

• Page builders. They ship large CSS and JavaScript bundles and deep DOM trees. That hurts render delay and INP. Rebuilding the top templates in the block editor is often cheaper than tuning a builder forever.
• Plugin stacking. Each plugin can add its own scripts to every page. Audit which scripts load where. Unload the form plugin on pages without forms.
• Two optimization plugins at once. Caching and minification plugins that overlap break each other. Pick one and configure it deliberately.
• Themes with sliders on the homepage. A slider usually delays the LCP image and adds shifts. A single static hero is faster.

Speed also drifts. A new plugin or a marketing script can undo a month of work. Build monthly speed checks in your maintenance routine so a regression shows up within weeks.

How long until Search Console turns green

Plan on about a month after the fix ships. The Search Console report shows the 75th percentile over the last 28 days. Old slow visits keep counting until they age out.

When you think an issue is fixed, press Start tracking on the issue page. That launches validation for the URL group.

Groups matter here. Search Console clusters similar pages together, so fix by template: product page, article, category, homepage. One template fix can clear thousands of URLs. A single-URL fix on a template with a shared problem clears almost nothing.

A two-week work order

This plan fits most sites where the problems sit in templates.

1. Days 1–2: measure. Export failing URL groups from Search Console. Run PSI on two example URLs per group. Note which metric fails on mobile and which on desktop.
2. Day 3: rank templates. Sort by the number of URLs affected. The help page recommends fixing "Poor" before "Needs improvement," then the most-affected or most important URLs.
3. Days 4–9: fix. Start with the largest template. Apply fixes from the table. Change one thing at a time where you can.
4. Days 10–12: verify in the lab. Rerun DevTools traces and PSI lab tests on the same example URLs. Compare LCP subparts, long tasks and shifts against day 1.
5. Days 13–14: ship and start tracking. Deploy, clear caches, press Start tracking. Set a reminder 28 days out.

Then wait, and watch the PSI field section, which updates daily, for an early signal.