Understanding Core Web Vitals - The Essential Metrics of a Healthy Website

Core Web Vitals are Google’s shared measurements for three parts of page experience: loading speed, responsiveness and visual stability. The current metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS).

First Input Delay (FID) is no longer a Core Web Vital. INP replaced FID in March 2024, so an audit or report that still treats FID as the responsiveness metric is out of date.

For each metric, Google recommends looking at the 75th percentile of real visits, split across mobile and desktop:

Metric	What it measures	Good	Needs improvement	Poor
LCP	Loading performance	2.5 seconds or less	2.5–4 seconds	More than 4 seconds
INP	Interaction responsiveness	200 ms or less	200–500 ms	More than 500 ms
CLS	Visual stability	0.1 or less	0.1–0.25	More than 0.25

Largest Contentful Paint (LCP)

LCP measures how long it takes the largest visible image or text block in the initial viewport to render. It is a useful proxy for the moment a page feels meaningfully loaded.

What affects LCP?

Common causes include:

• Slow server response and page generation
• Render-blocking CSS, fonts or JavaScript
• A large hero image that is discovered late or served at the wrong size
• Important content that appears only after client-side JavaScript runs

How to improve LCP

• Cache HTML where appropriate and use a content delivery network
• Compress and correctly size the LCP image, using modern formats
• Make the hero image discoverable in the initial HTML and give it high fetch priority
• Inline or prioritise critical CSS and defer non-critical scripts
• Prefer server-rendered or static content for the initial view

Do not lazy-load the image that becomes the LCP element. Lazy loading is useful below the fold, but it can delay the most important visual on the page.

Interaction to Next Paint (INP)

INP measures the latency of user interactions across the visit, not only the first interaction. It observes clicks, taps and keyboard input, then reports a representative value from the slowest interactions.

What affects INP?

• Long JavaScript tasks that block the main thread
• Event handlers that do too much work before updating the interface
• Large component trees that are expensive to render
• Repeated layout calculations caused by DOM reads and writes
• Third-party scripts competing for main-thread time

How to improve INP

• Break long tasks into smaller work so the browser can respond between them
• Reduce unnecessary JavaScript and delay non-critical third-party code
• Update the interface quickly, then perform non-visual work afterwards
• Avoid layout thrashing by grouping DOM reads and writes
• Use a Web Worker for suitable CPU-heavy work that does not need the DOM

Cumulative Layout Shift (CLS)

CLS measures unexpected movement of visible content. A page has a poor CLS when text, buttons or images shift after the user has started reading or interacting.

What affects CLS?

• Images and video without dimensions or an aspect ratio
• Ads, embeds and iframes without reserved space
• Cookie banners or notices inserted above existing content
• Late-loading fonts that substantially change text dimensions
• Dynamic content added above what the user is viewing

How to improve CLS

• Set width and height attributes, or a CSS aspect ratio, on media
• Reserve the final amount of space for embeds and dynamic components
• Use overlays for notices that should not push the page down
• Preload critical fonts and choose sensible fallback metrics
• Animate with transform and opacity instead of layout-changing properties

Field data and lab data answer different questions

PageSpeed Insights can show both:

• Field data comes from opted-in Chrome users in the Chrome User Experience Report. It reflects real devices, networks and visits over a rolling period.
• Lab data runs a controlled Lighthouse test. It is useful for debugging, but it does not replace field data and does not include INP because there is no real user interaction.

If a page lacks enough field traffic, instrument real-user monitoring with the web-vitals library and send results to your analytics platform.

Do Core Web Vitals affect SEO?

Google includes Core Web Vitals in its page-experience systems, but performance is not a substitute for relevant, useful content. Treat the metrics as a way to make pages genuinely better for users, then combine that work with clear information architecture, crawlable content and strong answers to search intent.

A practical audit order

1. Check Search Console or PageSpeed Insights for field-data patterns.
2. Identify the affected template, device class and metric.
3. Reproduce the issue in a lab tool such as Lighthouse or Chrome DevTools.
4. Fix the largest shared cause instead of chasing a perfect score on one URL.
5. Deploy, monitor real-user data and account for the field-data reporting delay.

Additional resources

• Web Vitals overview
• Optimize Largest Contentful Paint
• Optimize Interaction to Next Paint
• Optimize Cumulative Layout Shift

Need help with this?

If your Core Web Vitals scores aren’t where they should be and you want help fixing them, get in touch. I’ll tell you what’s actually wrong and what’s worth fixing first.