Core Web Vitals for Beginners: What They Are and What You Can Fix

Core Web Vitals are a set of metrics that describe what a real person experiences on a page. The Chrome team defines them, and Google Search Central includes them in its description of page experience. There are three, and each covers a different aspect.

• LCP (Largest Contentful Paint) is the time until the largest visible element appears. Usually that is a hero image, a video poster or a big block of text.
• INP (Interaction to Next Paint) measures how quickly the page responds visually to clicks, taps and key presses during the whole visit.
• CLS (Cumulative Layout Shift) adds up unexpected movement of content. If a button jumps away just as you press it, that is poor CLS.

In March 2024 INP replaced First Input Delay (FID) in the Core Web Vitals set. If you read an older guide that lists FID as the third metric, it is out of date. Definitions are on web.dev and in the Google Search Central documentation.

Why should a site owner care? A slow or unstable page annoys visitors. They leave before it finishes loading, or they tap the wrong thing. That hurts conversions whatever your search positions are.

Each metric has three ranges: good, needs improvement and poor. The figures below come from web.dev.

A page passes when the 75th percentile of real visits falls in the good range for all three metrics. In plain terms, at least three visits out of four must be at or better than the threshold.

Two practical consequences follow. First, a single fast test on your own laptop proves nothing: visitors use other devices, networks and distances from your server. Second, improving the slow tail of visits is what moves the 75th percentile, so look at mobile devices and weak connections, not only at your own machine.

TTFB (time to first byte) and FCP (first contentful paint) are not part of Core Web Vitals, but they help you find the cause of a slow LCP.

The same page can show different results in different tools, because there are two kinds of data.

Field data is collected from real Chrome users. It feeds the Chrome UX Report (CrUX), which PageSpeed Insights displays, and the Core Web Vitals report in Google Search Console. Field data gives the final verdict because it reflects real experience. The downside is that new or low-traffic pages may have no data at all.

Lab data comes from a single simulated load, for example in Lighthouse. It is repeatable, which makes it good for debugging: you change the code and see the effect at once. But a lab test does not know how real people behave, so INP is normally not measured in full in the lab.

A workable rule:

1. Take the Core Web Vitals verdict from field data.
2. Look for causes with lab tools.
3. After a fix, wait for field data to catch up. CrUX aggregates a period of several weeks, so results do not appear instantly.

If no field data is shown, that is not a site error. It means there are too few visits to report statistics.

Start by finding out what the LCP element is. PageSpeed Insights and the Performance panel in Chrome DevTools both mark it. Most often it is the hero image or a large heading.

Then work through the usual causes of a slow LCP:

• A heavy image. Compress it, serve a modern format (WebP or AVIF) and size it for how it is actually displayed. The srcset attribute lets mobile devices download a smaller version.
• Lazy-loading the main image. loading="lazy" belongs on images below the first screen. Do not put it on the LCP image, or the browser starts fetching it later.
• Render-blocking scripts and styles. Large CSS and synchronous scripts in the head delay the first paint. Move non-critical code out and add defer to scripts.
• A slow server response. If the server takes long to build the HTML, no image optimisation will rescue the metric. Check caching, compression (gzip or Brotli) and, if needed, a CDN.

Here is markup where the hero image loads straight away and the second one waits:

<img src="/images/hero.webp" width="1200" height="630" alt="Report overview" fetchpriority="high">
<img src="/images/chart.webp" width="800" height="450" alt="Score chart" loading="lazy">

The fetchpriority="high" attribute hints to the browser that the image matters. It is not magic, but it is a sensible choice for the LCP image.

INP is about interactivity, so it almost always comes back to JavaScript. When the main thread is busy with a long task, the browser cannot react to a click in time, and the user sees a button that appears frozen.

Where to begin:

• Find the long tasks. The Performance panel in Chrome DevTools marks them in red. Split big computations into smaller pieces so the main thread can handle input between them.
• Audit third-party scripts. Chat widgets, analytics, ad tags and A/B testing tools often do a lot of work on the main thread. Remove what earns nothing and load the rest later.
• Simplify event handlers. A click should not run heavy work synchronously. Show a visual response first and postpone the rest.
• Account for hydration cost. In applications built on modern frameworks, bringing the page to life can take a noticeable amount of time. Less JavaScript on the page means a faster response.

A site with almost no scripts rarely has an INP problem. A page packed with interactive features often finds INP is its weakest metric. More detail is on web.dev about INP.

Layout shifts nearly always have simple causes, and they are easy to fix once you know where to look.

• Images and video without dimensions. Set width and height or the CSS aspect-ratio property so the browser reserves space before the file arrives.
• Ads, banners and embedded widgets. Give them a container with a fixed minimum height in advance.
• Fonts. When a web font replaces the fallback, text can change size and push the page around. Pick a fallback font with similar metrics and a sensible font-display strategy.
• Content inserted above existing content. Consent banners, promo bars and hints that appear above text already on screen push it down. Add such elements on top of the content, for example as a fixed bar, or reserve room for them.

An example that reserves space for an embedded block:

<div style="aspect-ratio: 16 / 9; min-height: 240px;">
  <iframe src="https://example.com/embed" width="640" height="360" title="Embedded block"></iframe>
</div>

After the change, test on a slow network and a narrow screen. Shifts are most visible there.

You do not need a dozen paid services. Four free tools are enough to start.

1. PageSpeed Insights. Shows CrUX field data for the page (when there is enough) and a Lighthouse lab report with suggestions. A good starting point.
2. The Core Web Vitals report in Google Search Console. Groups your site's URLs by status for mobile and desktop and shows where the trouble sits.
3. The Performance panel in Chrome DevTools. Best for debugging: you can see long tasks, the LCP element and layout shifts.
4. The web-vitals JavaScript library. A small piece of code that collects LCP, INP and CLS from your real visitors. Useful when you want your own statistics rather than CrUX alone.

A sensible order: open the Search Console report first, find the group of problem URLs, check one typical page from the group in PageSpeed Insights, and only then dive into DevTools. That way you fix a template rather than a single page, and one fixed template improves many URLs at once.

Remember that Core Web Vitals are only one part of technical health. For the wider list of things to check, see the technical SEO checklist. Related topics: security headers and SEO and JSON-LD structured data.

Let us be direct: the SEOAudit scanner is passive and does not measure Core Web Vitals. It does not run the page in a browser, does not execute JavaScript and does not collect data from real visitors. In the report, Core Web Vitals field data is marked as unsupported (not assessed) and is never shown as passed. The scanner also does not estimate LCP, CLS or FCP from server response time, because such an estimate would be invented.

What it does report are indirect signals that often go together with poor metrics:

• the response time of the single main request (this is not a Core Web Vitals measurement);
• the size of the HTML document;
• images without width and height (a layout-shift risk indicator, not a measured CLS);
• legacy image formats and a missing srcset;
• a lazy-loaded first image;
• render-blocking scripts in the head and a large number of CSS and JS files;
• the number of third-party hosts and a missing preconnect;
• how web fonts are loaded, as declared in the HTML;
• compression, HTTP/2 and cache headers.

Treat these as a list of likely causes. Run the free scanner, note the hints, then confirm the effect in PageSpeed Insights and Search Console. What the SEO checks include is described on the SEO audit page. The security checks that run on the same request are covered on the security check page, and AI search readiness on the AI visibility page.