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

If Google Search Console says your pages are failing Core Web Vitals, here is how to fix them in five steps:

Measure with field data, not a lab score. Open the Core Web Vitals report in Search Console or the field section of PageSpeed Insights.
Find the failing metric. It will be LCP, INP or CLS. Each one has a different cause and a different fix.
Find the element responsible. The largest image, the slow click handler, or the block that jumps.
Apply the fix for that element, using the sections below.
Re-verify after 28 days. Field data is a rolling 28-day window, so the report lags your changes.

This guide is for site owners and the people who look after their websites. If you want the background on what the metrics mean first, read our Core Web Vitals explainer.

Key takeaways

Google grades each metric on real Chrome users, so a passing lab score can still fail. Use field data to decide what to fix.
LCP failures are almost always one element: the hero image or the server response before it.
INP failures are JavaScript on the main thread, usually third-party scripts.
CLS failures are content arriving without reserved space: images without dimensions, fonts swapping, banners injected at the top.
Fix one metric at a time and wait for the 28-day window before judging the result.

The thresholds and where to start

Metric	Good threshold	Most common cause	First fix to try
LCP (Largest Contentful Paint)	2.5 seconds or less	An oversized hero image, or a slow server response before it	Compress and resize the LCP image, then check TTFB
INP (Interaction to Next Paint)	200 milliseconds or less	Long JavaScript tasks, usually from third-party scripts	Remove or delay non-essential scripts
CLS (Cumulative Layout Shift)	0.1 or less	Images without width and height attributes	Add dimensions to every image and embed

The thresholds come from Google’s definitions of LCP, INP and CLS. A page passes a metric when at least 75 percent of visits hit the good threshold, which is why a fast desktop test can hide a failing mobile experience: the slower quarter of your visitors sets the grade.

How to fix a poor LCP

LCP is the time until the largest visible element has rendered, usually a hero image or a large heading. Google’s guide to optimising LCP splits the metric into time to first byte, resource load delay, resource load time and render delay. Your fix depends on which part is slow.

Find the LCP element

Run the page through PageSpeed Insights and open the “Largest Contentful Paint element” audit in the diagnostics. It names the exact element. Test on mobile, because mobile is what Google indexes and where LCP fails.

Fix the image

If the LCP element is an image, its size and how it is delivered control the metric.

Resize it to the displayed width. A 2400 pixel image in a 1200 pixel slot is four times the pixels it needs. Use srcset so phones get a phone-sized file.
Compress it and change the format. A hero image should usually come in under 200 KB. WebP is typically 25 to 35 percent smaller than JPEG at similar quality, and AVIF is smaller again.
Do not lazy-load it. loading="lazy" on the LCP image tells the browser to wait. Remove it from anything above the fold.
Give it priority. Add fetchpriority="high" to the LCP <img> so the browser fetches it before other images.
Avoid CSS background images for the hero. They are only discovered after the CSS has parsed. A real <img> in the HTML is found immediately.

Fix the server response

Time to first byte (TTFB) is the floor under your LCP. If the HTML takes 1.5 seconds to arrive, nothing can render before then. Aim for under 800 milliseconds, and under 200 milliseconds for cached pages.

Enable full-page caching. On WordPress that means a caching plugin or host-level cache, so the server sends stored HTML instead of rebuilding the page for every visit.
Use a CDN so cached HTML and images are served from near the visitor.
Move hosting if TTFB stays high with caching on. Overloaded shared hosting cannot be fixed from the front end. Our WordPress speed optimisation service includes the hosting assessment.

Remove render-blocking CSS and JavaScript

Stylesheets and synchronous scripts in the <head> stop the browser painting until they have downloaded and run. Every one sits between the visitor and your LCP element.

Inline the critical CSS for above-the-fold content and load the rest asynchronously.
Add defer to scripts not needed for the first paint. Most are not.
Remove unused CSS and JavaScript. Page builders and multipurpose themes ship code for features you never enabled; PageSpeed Insights lists the unused bytes per file.

Preload what the browser cannot see early

If the LCP image is set in CSS or injected by JavaScript, add <link rel="preload" as="image" href="..."> in the <head> so the download starts with the HTML. Do the same for the web font used in a large LCP heading. Preload only the one or two resources that decide LCP; every extra preload competes for bandwidth.

How to fix a poor INP

INP measures the delay between a user interaction (a tap, click or key press) and the next frame the browser paints. It considers every interaction during the visit and reports one of the worst. INP replaced First Input Delay in March 2024 and is harder to pass, because it covers the whole visit rather than the first click. Google’s guide to optimising INP is the reference for the fixes below.

Break up long tasks

JavaScript runs on the browser’s main thread, and while a task is running, the browser cannot respond to the user. Any task over 50 milliseconds counts as a long task. The Chrome DevTools performance panel flags them with a red triangle.

Split large pieces of work into smaller chunks with setTimeout or scheduler.yield() so the browser can handle input between them.
Move heavy computation into a Web Worker, which runs off the main thread.
Avoid processing large data sets synchronously when the user clicks.

Cut third-party scripts

Analytics, chat widgets, tag managers, advertising tags, social embeds and A/B testing tools are the most common source of long tasks on small business sites.

Audit every script on the page and remove any that no longer earns its place.
Delay the rest until after the first interaction or scroll. A chat widget does not need to load before anyone has read the page.
Load embedded iframes (videos, maps) with loading="lazy", so their scripts do not run until they are near the viewport.

Reduce hydration and framework overhead

Sites built on JavaScript frameworks often ship a large bundle that must run before any button works, a process called hydration. During hydration, clicks queue up and INP suffers.

Ship less JavaScript: code-split by route so each page loads only what it uses.
Use partial or island hydration if your framework supports it, so static content is not made interactive for no reason.
On WordPress, the equivalent is theme and plugin scripts executing on every page. Dequeue scripts on pages that do not use them.

Keep event handlers light

A click handler should do the minimum needed to update the screen, then defer everything else: update the visible state first, send the analytics event and run the calculation afterwards. Avoid reading layout properties (such as offsetHeight) and then writing styles in the same handler, which forces repeated layout recalculation.

How to fix CLS

CLS measures how much visible content moves after it has rendered. The score is the size of the shifted area multiplied by how far it moved, summed over the visit’s worst burst of shifts. Anything above 0.1 fails. Google’s guide to optimising CLS covers the causes; the four below account for almost every failure we see.

Give images and embeds their dimensions

An <img> without width and height attributes takes up no space until the file arrives, then pushes everything below it down. This is the single largest cause of CLS.

Add width and height attributes to every image. Browsers use them to reserve space at the correct aspect ratio even when CSS makes the image responsive.
Use the CSS aspect-ratio property for containers whose content loads later.
Give iframes, video embeds and advertising slots a min-height so their space is reserved before the content loads.

Stop fonts from shifting text

When a web font replaces the fallback font, line lengths change and paragraphs reflow. The shift is small per line but adds up across a page.

Use font-display: swap or font-display: optional in your @font-face rules so text renders immediately.
Preload the main text font so the swap happens before the user has scrolled.
Match the fallback font’s metrics to the web font with size-adjust and ascent-override, so the swap changes almost nothing.
Or use a system font stack and avoid the swap entirely. This site does exactly that.

Keep banners and notices out of the flow

Cookie consent bars, promotional strips and app banners that appear after load and push content down are a classic CLS source. Anything that loads late should either overlay the page (fixed to the bottom of the viewport) or have its space reserved from the first render.

Reserve space for late-loading content

Related-products grids, comment sections, review widgets and personalised blocks that arrive after render all cause shifts if nothing was holding their place. Render a placeholder of the same size, or load them below the fold. Never insert new content above existing content unless the user has just asked for it.

Verify the fix with field data

Lab tools show whether a fix worked in a simulation. Only field data shows whether it worked for your visitors, and field data is what Google grades. The gap between the two is the subject of our post on the PageSpeed Insights score versus real-world speed.

Straight after a fix, re-run PageSpeed Insights and confirm the specific audit (LCP element, long tasks, layout shift elements) has changed.
Watch the Core Web Vitals report in Google Search Console over the following weeks. It groups URLs, so one template fix usually moves many pages at once.
Expect the field numbers to settle four to six weeks after the change, because of the 28-day window and the delay before Search Console refreshes.

If field data has not moved after six weeks, the fix did not reach the visitors who were failing. The usual reason is that it was tested on desktop while the failures were on mobile.

Which metric to fix first

Fix LCP first: it is the most commonly failed metric, its causes are the easiest to see, and improving it makes the whole site feel faster. Fix CLS second, because the fixes are mechanical and immediate. Fix INP last, since JavaScript problems take the most diagnosis, but do not skip it: a page that loads fast and then ignores taps still loses the visitor.

Core Web Vitals are one part of how Google evaluates a page. Our post on whether page speed affects SEO explains how much weight they carry in rankings. If you would rather have someone else find and fix the failing elements, our Core Web Vitals optimisation service handles all three metrics as one job, and the free speed report tells you which metric is failing and why within one working day.

Frequently asked questions

How long does it take to fix Core Web Vitals?

The fix itself is often a day or two of work for a typical small business site. Seeing the result in Google Search Console takes longer, because field data is collected over a rolling 28-day window. Most sites see the report change within four to six weeks of the fix going live.

Why do Core Web Vitals fail on mobile but pass on desktop?

Mobile visitors use slower processors and slower connections, so the same page takes longer to load and to respond. Google indexes the mobile version and grades each metric at the 75th percentile of visits, which means the slower quarter of your mobile visitors decides whether the page passes.

Can a WordPress site with a page builder pass Core Web Vitals?

Yes, but it needs more work. Page builders add large CSS and JavaScript files to every page, which hurts LCP and INP. Caching, removing unused assets and optimising images bring most page builder sites into the green. Some heavily customised sites are better served by a lighter theme.

What is the difference between lab data and field data?

Lab data comes from a tool loading the page in a simulated environment, such as Lighthouse in PageSpeed Insights. Field data comes from real Chrome users over 28 days, collected in the Chrome User Experience Report. Google uses field data for ranking, so a fix only counts when field data improves.

Do I need to pass all three Core Web Vitals?

Google assesses each metric separately, and a page needs all three in the good range to be considered as passing. A single failing metric is still worth fixing on its own, because each one reflects a real problem for visitors, and the ranking signal is a small piece of a bigger picture.

Which tool should I use to check Core Web Vitals?

Use Google Search Console’s Core Web Vitals report for the site-wide picture and PageSpeed Insights for an individual URL. Both show field data where enough traffic exists. Google’s documentation on Core Web Vitals and search results explains how the data is used.