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

Core Web Vitals are three metrics Google uses to measure how quickly a page loads, how fast it responds to interaction and how much it shifts while loading: LCP, INP and CLS. When all three sit in the good range, visitors find the page smooth. This guide explains what each metric means, what usually breaks it and the fixes that work on small business websites.

The three metrics and their thresholds

Each metric splits real-user experiences into three bands: good, needs improvement and poor. The assessment uses the 75th percentile of visits. In other words, if three quarters of visitors have a good experience, the page passes.

Metric	What it measures	Good	Poor
LCP	Time until the largest content appears	2.5 seconds or less	Over 4 seconds
INP	Response time to clicks and taps	200 ms or less	Over 500 ms
CLS	Unexpected movement of the layout	0.1 or less	Over 0.25

These thresholds and the measurement method are set out on the Web Vitals page at web.dev. INP replaced FID in March 2024. If an old report still shows FID, look at INP instead.

Where to read your data

There are two kinds of data, and mixing them up is a common mistake. Field data comes from real people visiting your site in Chrome. Lab data is a simulation run on a single test device.

• Search Console: groups your pages into good, needs improvement and poor using field data.
• PageSpeed Insights: shows field data at the top and a lab test with recommendations below.
• Chrome DevTools: the Performance panel shows which file is causing a problem.

Google explains how page experience relates to search in its Search Central documentation. In short: good metrics help, but they do not replace relevant, useful content.

Sites with little traffic may have no field data at all. In that case, work from lab tests and run the same page several times at different hours. A single measurement can mislead you, depending on server load at that moment.

LCP: show the main content sooner

LCP is usually the large image or heading block at the top of the page. The later it appears, the more likely a visitor thinks the page is broken. The common causes and fixes are:

1. Heavy images: convert the hero image to WebP or AVIF and serve it at the size the screen needs.
2. Late discovery: use an img tag rather than a CSS background for the hero, and load it with high priority.
3. Slow server response: turn on caching and, if needed, move to faster hosting or a CDN.
4. Render-blocking resources: defer CSS and scripts that the top of the page does not need.

Lazy-loading the hero image is a frequent mistake. Lazy loading is for images further down the page; on the first screen it only adds delay.

INP: respond to clicks straight away

INP measures how long the page takes to react when someone presses a button or opens a menu. As the INP explainer notes, the metric is based on one of the slowest interactions during the visit.

Poor INP is mainly caused by JavaScript keeping the browser's main thread busy for too long. Ways to fix it:

• Remove plugins and third-party scripts you do not use: chat widgets, old tracking tags, heavy sliders.
• Break long tasks into smaller pieces; your developer can restructure the code to do this.
• Defer heavy work that follows an interaction until after the screen has updated.
• If you use an off-the-shelf theme, switch off features you do not need.

CLS: keep the layout steady

CLS measures how much the page jumps down or sideways while someone is reading. If the layout shifts just as a visitor goes to tap a link, they hit the wrong thing. It is irritating and it costs trust.

The usual causes and fixes:

• Images without dimensions: give every image a width and height, or fix its aspect ratio in CSS.
• Ads and embeds that load late: reserve space of a fixed height for them in advance.
• Web fonts: if text changes size as the font loads, tune the fallback font to similar metrics.
• Banners that open at the top: overlay them on the page instead of pushing the content down.

Notes for WordPress and site builders

On WordPress, the most common cause of slowness is plugins that have piled up over time. Each one can load its own CSS and JavaScript on every page. Review the list and delete anything that has not earned its place in the last six months.

Do not run more than one caching plugin. Two cache layers can conflict and create new errors rather than solving the old ones. Pick a single tool for image compression as well.

On closed platforms such as Wix, Squarespace and Shopify, your access to server settings is limited. The most effective steps there are smaller images, removing heavy apps and simplifying animated sections on the homepage. If the theme itself is very heavy, switching to a lighter one gains more than any amount of fine-tuning.

A priority order for small business sites

On most small business sites, the bulk of the problems come from a handful of sources. Working in this order gives the biggest gain for the least effort:

1. Compress images, resize them and set their dimensions.
2. Remove unused plugins and scripts.
3. Turn on server and browser caching.
4. Load the hero image with priority and lazy-load the rest.
5. Self-host fonts and serve only the weights you use.

Most of these steps can be done through settings without writing code. To see which pages have problems, try our free SEO checker. Speed is just one part of a full technical SEO audit, and that guide covers the other checks.

What to watch after the fixes

Field data is calculated from the last four weeks of visits, so the effect of a fix does not show in Search Console immediately. Note the date each change went live and check the report again four weeks later.

In the meantime, lab tests confirm whether the fix works. Once a month, log the share of good URLs, the slowest page group and contact form conversions side by side. Our Google Search Console guide explains how to read the Core Web Vitals report.