Core Web Vitals: How to Improve User Page Experience

Core Web Vitals are Google's three measures of real page experience: how fast the main content loads, how quickly the page responds to a tap or click, and how still the layout stays while it loads. Google's ranking systems use them, so a slow or jumpy page costs you visitors and some ground in search. This guide explains what each metric measures, the scores that count as good, how to fix each one and which tools report them. Aemorph's guide to how search engines work explains how Google crawls, renders, indexes and ranks pages.

See Aemorph's technical SEO service

Written by Kevin Dam, founder of Aemorph, who has practised SEO since 2010 and sits on the Forbes Agency Council. Aemorph is a Google Partner. LinkedIn

Originally published 20 February 2024 on aemorph.com/seo/technical/core-web-vitals/. Updated October 2026.

What Are Core Web Vitals?

Core Web Vitals are three metrics Google uses to score the loading, interactivity and visual stability of a page for real visitors: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Each metric has a "good" threshold, a "needs improvement" band and a "poor" band, set out on Google's web.dev Web Vitals page.

Core Web Vitals thresholds, as published by Google.

Sources: web.dev, October 2024 and others

What changed in March 2024?

Interaction to Next Paint replaced First Input Delay (FID) as the Core Web Vital for responsiveness on 12 March 2024. FID timed only the delay before the browser started handling the first interaction on a page. INP times every click, tap and key press across the visit, through to the moment the screen updates, so it reflects how responsive the page feels from start to finish (web.dev, INP becomes a Core Web Vital). Pages written before 2024 that still list FID and its 100-millisecond threshold describe a retired metric.

How does Google decide whether a page passes?

A page passes the Core Web Vitals assessment when the 75th percentile of its real visits is "good" on all three metrics. The 75th percentile means three in four visits are at or better than that value. Google measures mobile and desktop separately, so a page passes on desktop and fails on mobile when its mobile visits are slower. A metric also moves through three stages before it counts: experimental, pending and stable. Only stable metrics form the Core Web Vitals.

Why Do Core Web Vitals Matter for SEO?

Google states that Core Web Vitals are used by its ranking systems and recommends good scores "for success with Search". The same page also says good scores in Search Console or other tools do not guarantee top rankings, because there is more to page experience than Core Web Vitals (Google Search Central, page experience).

Do Core Web Vitals decide rankings on their own?

No: Google always aims to show the most relevant content, even when its page experience is below par, so relevance comes first and Core Web Vitals work alongside it. Google lists Core Web Vitals with secure delivery over HTTPS, mobile-friendly display, no excessive ads, no intrusive interstitials and main content that is easy to tell apart from the rest of the page. Beyond Core Web Vitals, Google says those other aspects do not directly lift rankings, though they make a site more satisfying to use. A fast page with thin content still loses to a slower page that answers the query better. Aemorph's guide to mobile SEO covers mobile-first indexing and the checks a phone layout needs.

How do most websites score?

Fewer than half of websites pass on mobile: 48% of mobile sites and 56% of desktop sites achieved a good overall Core Web Vitals result in June 2025. Those figures come from the HTTP Archive Web Almanac 2025, which Aemorph's AI search statistics hub tracks with its source and year.

Source: HTTP Archive, 2025

How Do You Improve Largest Contentful Paint (LCP)?

You improve LCP by getting the largest element in view, usually a hero image or a headline block, to the visitor's screen sooner: a faster server response, an earlier start to the image download, a smaller file and nothing blocking the render. LCP counts images, poster images on videos, elements with a CSS background image and block-level elements that hold text (web.dev, LCP).

What slows LCP down?

LCP breaks into four parts, and the slow part tells you what to fix: server response, the wait before the LCP resource starts loading, the time it takes to download, and the delay before it renders. For a well-optimised page, Google's guide suggests roughly 40% of the LCP time goes on server response (time to first byte), under 10% on the load delay, roughly 40% on the download itself and under 10% on the render delay (web.dev, Optimise LCP). A long load delay usually means the browser found the image late, for example because JavaScript inserts it or it sits in a CSS file.

How do you fix a slow LCP?

Fix LCP in the order of its four parts: answer requests faster, let the browser find the LCP image early, shrink the file and remove anything that blocks rendering.

1. Speed up the server response. Serve pages from a content delivery network (CDN) and cache rendered HTML, so the first byte arrives sooner.
2. Never lazy-load the LCP image. Lazy loading delays the one image the metric times. Keep loading="lazy" for images further down the page.
3. Tell the browser the image matters. Add fetchpriority="high" to the LCP image, or preload it when it sits in CSS, so the download starts with the HTML.
4. Render the main content on the server. Content that waits for JavaScript to build it appears later than content already in the HTML.
5. Shrink the image. Serve modern formats such as WebP or AVIF at the size the layout displays. The image SEO guide covers formats and compression.

How Do You Improve Interaction to Next Paint (INP)?

You improve INP by keeping the browser's main thread free, so every click, tap and key press gets a visible response within 200 milliseconds. INP records the interactions during a visit and reports the longest one, ignoring rare outliers on pages with many interactions (web.dev, INP).

What makes INP slow?

Each interaction has three phases, and a delay in any of them raises INP: input delay, processing duration and presentation delay. Input delay is the wait before your event handler starts, usually because another script is still running. Processing duration is the time your handler takes. Presentation delay is the time the browser needs to lay out and paint the next frame, which grows with a large or complex page.

How do you fix a slow INP?

Break long JavaScript tasks into smaller ones, do the least work possible inside each event handler and keep the page structure small.

1. Yield to the main thread. Split long tasks so the browser responds to input between them; web.dev shows setTimeout as one way to yield (web.dev, Optimise INP).
2. Keep event handlers short. Update what the visitor sees first, then defer analytics calls and other background work.
3. Reduce the size of the DOM. A page with fewer elements lays out and paints faster after each interaction.
4. Skip off-screen rendering. The CSS property content-visibility lets the browser delay rendering content outside the viewport.
5. Avoid layout thrashing. Reading layout values straight after changing styles forces the browser to recalculate layout over and over; group reads before writes.

How Do You Improve Cumulative Layout Shift (CLS)?

You improve CLS by reserving space for everything that loads late, so text and buttons stay where the visitor first saw them. CLS groups layout shifts into session windows, each closing after a gap of one second or five seconds in total, and reports the largest window. Shifts within 500 milliseconds of a visitor's input do not count, because the visitor expected them (web.dev, CLS).

What causes layout shifts?

Most layout shifts come from images, videos, ads, embeds and iframes without set dimensions, content injected above existing content, and web fonts that swap in at a different size. Animations that change an element's size or position also move the content around them.

How do you fix CLS?

Give every late-loading element a reserved space and load fonts so the text does not jump.

1. Set width and height on images and videos, or a CSS aspect-ratio, so the browser reserves the space before the file arrives.
2. Reserve space for ads, embeds and banners. Give each slot a fixed minimum height, and add new content below what the visitor is reading rather than above it.
3. Control web fonts. Preload key fonts, use font-display: optional where a late swap is not worth a shift, and use size-adjust to match the fallback font's size.
4. Animate with transforms. CSS transform animations move an element without shifting the content around it.
5. Keep the back/forward cache working. web.dev lists keeping pages eligible for the browser's back/forward cache among its CLS fixes (web.dev, Optimise CLS).

Which Other Performance Metrics Help You Diagnose Problems?

Time to First Byte (TTFB) and First Contentful Paint (FCP) explain a slow LCP, and Total Blocking Time (TBT) is the lab stand-in for INP; none of them is a Core Web Vital. Google calls these diagnostic metrics: they point to the cause of a poor Core Web Vitals score. Lighthouse, Google's lab testing tool, blends five metrics into its performance score.

Lighthouse 10 performance score weights, from Chrome for Developers. Scores of 90 to 100 are good, 50 to 89 need improvement and 0 to 49 are poor.

Does a high Lighthouse score mean your page passes Core Web Vitals?

No: a Lighthouse score comes from one simulated page load, while the Core Web Vitals assessment comes from real visits over 28 days. A simulated load has no visitor clicking, so Lighthouse reports Total Blocking Time in place of INP. Use Lighthouse to find causes and the field data to judge the result.

Sources: Chrome for Developers and others

Which Tools Measure Core Web Vitals?

Five Google tools report Core Web Vitals: PageSpeed Insights, the Search Console Core Web Vitals report, Chrome DevTools, Lighthouse and the Chrome UX Report (CrUX). Field data shows what real visitors experienced; lab data shows one controlled test you repeat while you fix.

Core Web Vitals tools compared.

How does the Search Console report group your pages?

Search Console groups URLs that give a similar experience and rates each group by its poorest metric, so one failing metric marks the whole group as poor. When a page has too little data of its own, the report rates it with its origin group. After you fix a group, select "Start Tracking" to begin a 28-day validation (Search Console Help, Core Web Vitals report).

Why do field data and lab data disagree?

Field data comes from real Chrome visitors on their own devices and networks; lab data comes from one simulated load, so the two rarely match. CrUX collects data only from Chrome users who opted in, and it leaves out Chrome on iOS, Android WebView and other Chromium browsers. A page also needs enough public traffic to appear in CrUX at all (Chrome for Developers, CrUX methodology). PageSpeed Insights' mobile lab test simulates a mid-tier phone (Moto G4) on a mobile network, so its result reflects one device and one connection, not your visitors' mix.

What happened to the Web Vitals Chrome extension?

Google ended support for the Web Vitals extension on 7 January 2025 and moved its features into the Chrome DevTools Performance panel. The panel's real-time metrics view arrived with Chrome 129 in September 2024 (Chrome for Developers blog). Guides that still recommend the extension point to a tool that no longer receives updates.

Sources: Google Search Console Help and others

Turn Core Web Vitals Into a Faster Site

Core Web Vitals improve when you fix the cause at the template level and then watch the field data for 28 days, because one template fix corrects every page built on it. Start with the Search Console report to find the failing groups, use PageSpeed Insights and DevTools to find the cause, fix it, then start validation. If you prefer an experienced team to run this for you, Aemorph's technical SEO service crawls your site, measures each template against Google's good thresholds and specifies each fix for your developers, who set the pace.