How to fix Core Web Vitals

Core Web Vitals are three measurements Google uses to judge how a page feels to a real visitor: how fast the main content appears, how quickly the page responds to a tap, and how much the layout jumps around. Google uses them as one of many signals in search, and they are a good proxy for whether your site is pleasant to use on a phone.

The three numbers

Largest Contentful Paint (LCP) measures how long it takes for the biggest thing in view to appear, usually a hero image or a headline. Good is 2.5 seconds or less.
Interaction to Next Paint (INP) measures how long the page takes to respond visually after someone taps, clicks or types. Good is 200 milliseconds or less. INP replaced the older First Input Delay metric in March 2024.
Cumulative Layout Shift (CLS) measures how much content moves around unexpectedly while the page loads. Good is 0.1 or less.

Google assesses each one at the 75th percentile of real visits, so three out of four visits need to hit the target for the page to pass.

Where to find your real numbers

There are two sources, and it helps to know the difference.

Field data comes from real Chrome users and appears at the top of PageSpeed Insights and in the Core Web Vitals report in Google Search Console. This is what Google actually uses. Smaller sites may not have enough traffic to show it.
Lab data comes from a single simulated test (Lighthouse). It is useful for finding causes and checking fixes, but it can't measure INP directly, because nobody is tapping the page. It shows Total Blocking Time instead, which tends to move with INP.

Field data covers the last 28 days, so after you fix something, expect to wait about a month before the field numbers fully reflect it. Use the lab test to confirm the fix worked in the meantime.

Fixing a slow LCP

First, find out what the LCP element is. PageSpeed names it under "Largest Contentful Paint element". Then work through these:

Make the image smaller. If the LCP element is a photo, cut it down to the size it displays at and serve it as WebP or AVIF.
Don't lazy-load it. Lazy loading is good for images further down, but it delays the hero image. Remove loading="lazy" from the main image and add fetchpriority="high" instead.
Speed up the server. LCP can't happen before the HTML arrives. Page caching and better hosting both help here.
Clear render-blocking files. Large CSS and JavaScript files in the page head make the browser wait. Defer scripts that aren't needed straight away.
Avoid sliders in the hero. Carousels often load several large images and a script before the first slide shows.

Fixing a poor INP

INP problems almost always come from JavaScript keeping the browser busy, so it can't respond when someone taps.

Remove scripts you don't need. Old tracking tags, unused plugins and widgets all compete for the same processor time.
Delay third-party scripts. Chat widgets, heatmaps and social embeds can usually load after the page is interactive, or only when the visitor scrolls or clicks.
Look at long tasks. In Chrome DevTools, the Performance panel shows tasks over 50 milliseconds. These are the ones that block taps. Developers can break them up so the browser gets a chance to respond in between.
Keep the page smaller. Very large pages with thousands of HTML elements take longer to update after each interaction.

Fixing a high CLS

Layout shift happens when something loads late and pushes other content out of the way. The usual causes:

Images without dimensions. Add width and height attributes to every image so the browser reserves the space before the file arrives. Modern WordPress does this for images inserted through the editor.
Ads, embeds and banners. Give them a fixed-size container. Cookie banners and announcement bars should overlay the page or be in the HTML from the start, not slide in and push everything down.
Web fonts. When a custom font replaces the fallback font, text can reflow. Preload your main font file and choose a fallback with similar proportions.

Check your work

After each change, run PageSpeed again on mobile and compare the lab numbers. Make one change at a time where you can, so you know what helped. Then keep an eye on the field data over the following weeks. If you have Search Console, the Core Web Vitals report lets you mark an issue as fixed and starts a 28-day validation.

If your problem is general slowness rather than one metric, start with our guide on why websites are slow.

See where you stand

The free CrawlCare scan pulls your field data from Google when it exists, runs Lighthouse on mobile and desktop, and shows which of the three metrics need work. It is a quick way to get a starting point before you change anything.