Core Web Vitals

Core Web Vitals are three metrics Google uses to judge how a page feels to the people who actually visit it: how fast the main content shows up, how quickly the page reacts when someone taps or clicks, and whether the layout holds still while it loads. They are part of Google's page experience signals, so they matter for search as well as for users. This guide covers what each metric measures, the thresholds that count as good, where the data comes from and the fixes that move the numbers most.

From PerfDelta's measurements: 49% of the 4,277 websites with field data pass all three Core Web Vitals. 71% have a good LCP, 74% a good INP and 74% a good CLS, which makes INP the metric large websites fail most often. More in the data section below.

What Core Web Vitals are

The set has three members, each covering one part of the experience:

• Largest Contentful Paint (LCP) measures loading: the time until the largest visible element in the viewport is rendered.
• Interaction to Next Paint (INP) measures responsiveness: how long the page takes to show a visual response after a click, tap or key press.
• Cumulative Layout Shift (CLS) measures visual stability: how much content moves around unexpectedly.

The list changes over time. In March 2024 INP replaced First Input Delay (FID). FID only looked at the delay before the first interaction was handled; INP looks at every interaction during the visit, including the time it takes to process it and paint the result, which makes it a far better picture of how sluggish a page feels.

Good Core Web Vitals thresholds at the 75th percentile

Google rates each metric in three bands. The assessment uses the 75th percentile of real page loads, so a page passes a metric when at least three out of four visits reach the good threshold.

Metric	Good	Needs improvement	Poor
LCP (loading)	2.5 s or less	2.5 to 4 s	more than 4 s
INP (responsiveness)	200 ms or less	200 to 500 ms	more than 500 ms
CLS (visual stability)	0.1 or less	0.1 to 0.25	more than 0.25

A page passes the Core Web Vitals assessment only when all three metrics are good. Mobile and desktop are assessed separately, and mobile is where most sites fail: slower processors and weaker connections push the 75th percentile up. According to the HTTP Archive Web Almanac 2025, about 48 percent of websites pass all three metrics on mobile and about 56 percent on desktop.

Largest Contentful Paint: when the main content appears

LCP marks the moment the biggest element above the fold is painted, usually a hero image, a background image or a large block of text. It stands in for the point where a visitor feels the page has loaded. Its timeline has four parts: the time to the first byte of HTML, the delay before the browser discovers the LCP resource, the download of that resource and the time to render it. Slow LCP almost always comes from one of those four.

• Cut server response time with page caching and a CDN, see reducing initial server response time.
• Remove or defer render-blocking resources in the document head.
• Serve the hero image at the right size and in WebP or AVIF, see properly sizing images and next-gen image formats.
• Make the LCP image discoverable in the HTML, give it fetchpriority="high" and never lazy-load it.

Interaction to Next Paint: how fast the page reacts

INP observes every click, tap and key press during a visit and reports a value close to the slowest one. Scrolling and hovering do not count. Each interaction has three phases: the input delay while the main thread is busy with other work, the processing time of the event handlers, and the presentation delay until the next frame is painted. High INP is nearly always a busy main thread, caused by large JavaScript bundles, expensive event handlers or third-party scripts running at the wrong moment.

• Break long tasks into smaller chunks and yield to the browser in between.
• Ship less script, see reducing unused JavaScript.
• Keep event handlers to the work needed for the visible response and defer the rest.
• Move heavy computation into a web worker.

INP needs real interactions, so lab tools cannot measure it directly. Total Blocking Time is the lab metric that tracks it best: pages with high TBT tend to have poor INP.

Cumulative Layout Shift: whether the layout stays put

CLS adds up unexpected layout shifts, grouped into short windows, and reports the worst window of the visit. It is the moment a button moves just as you tap it because an image or an ad loaded above it. The value has no unit; it combines how much of the viewport moved and how far. Shifts within half a second of a user input are expected and do not count.

• Give images and videos width and height attributes or a CSS aspect-ratio.
• Reserve fixed space for ads, embeds and cookie banners.
• Do not inject content above content that is already visible.
• Load web fonts with font-display: swap and a fallback font with matching metrics.

Field data and lab data measure different things

Core Web Vitals exist in two forms, and mixing them up is the most common source of confusion.

• Field data comes from real Chrome users and is published in the Chrome UX Report (CrUX) as a rolling 28-day window. This is the data Google uses for page experience. It is available per URL when a page has enough traffic, otherwise only for the whole origin.
• Lab data comes from a single controlled run, for example in Lighthouse. It is repeatable and ideal for debugging, but it does not feed into rankings.

The practical consequence: a fix shows up in the lab immediately, while the field data follows over the next weeks as the 28-day window rolls forward. CLS is where the two differ most, because the lab only watches the initial load while the field records the whole visit, including scrolling and content that loads later.

Core Web Vitals and the PageSpeed score

The 0 to 100 score in PageSpeed Insights and Lighthouse is not the same thing as the Core Web Vitals. The score is a weighted blend of lab metrics, among them First Contentful Paint, Speed Index, Total Blocking Time, LCP and CLS. It is a diagnostic tool. A page can score 90 in the lab and still fail the field assessment when its real visitors use slower phones, and a page with a mediocre score can pass in the field. For search, the field values count; the score helps you find the causes.

Core Web Vitals as a ranking factor

Google confirms that Core Web Vitals are used by its ranking systems as part of page experience. They are one signal among many and do not outweigh relevance: a slow page with the best answer will still rank. The effect is largest where several results are similarly relevant and where poor performance drives visitors away before they read anything. Consistency matters too. A fast homepage does not help if the category or product templates that carry most of the traffic fail, and Google also aggregates data at the origin level for pages without enough traffic of their own.

Common causes of poor Core Web Vitals

The same problems appear on most sites. For LCP they are oversized images, slow server responses and render-blocking scripts in the head. For INP it is too much JavaScript on the main thread. For CLS it is images and ad slots without reserved space and late-loading fonts. Third-party code shows up in all three: tag managers, chat widgets, A/B testing tools and consent banners delay loading, occupy the main thread and shift the layout when they inject content. Reviewing every external script is often the most effective first step, because removing one can improve two or three metrics at once.

How to measure Core Web Vitals

• PageSpeed Insights shows field and lab data for one URL and lists concrete opportunities.
• The Core Web Vitals report in Google Search Console groups the URLs of your whole site into good, needs improvement and poor, which helps you find the templates that fail.
• Chrome DevTools shows live LCP, INP and CLS values while you use the page and lets you record a performance trace to find the long tasks behind poor INP.
• Regular monitoring tells you whether values improve over time or slip after a release.

Test more than the homepage. A homepage, an article and a product page usually differ a lot, and the pages with the most traffic weigh most in the origin data. PerfDelta tests several page types of a site on mobile and desktop in one run, shows field and lab data side by side and compares your field values with your competitors. Which Google APIs PerfDelta queries, the Lighthouse test conditions and why values for the same page can differ between sections of a report are described in the PerfDelta methodology.

How often sites on WordPress, Wix, Squarespace and other platforms pass is shown in the Core Web Vitals benchmark, and how the sites tested with PerfDelta perform in your sector in the Core Web Vitals benchmarks by industry.

Improving Core Web Vitals in a sensible order

Many fixes help more than one metric. Less JavaScript speeds up loading and frees the main thread, which improves LCP and INP together. Fixed image dimensions prevent layout shifts and help the browser lay out the page early. An order that works on most sites:

1. Lower the server response time, since every loading metric builds on it, see Time to First Byte.
2. Remove render-blocking CSS and JavaScript from the critical path.
3. Optimize the LCP image and lazy-load the images below the fold.
4. Reserve space for images, ads and embeds to bring CLS down.
5. Reduce and split JavaScript, and audit third-party scripts to improve INP.

Measure again after each change, because a fix in one place can have side effects elsewhere, and check the field data a few weeks later to confirm the improvement reached real users.

How often to monitor Core Web Vitals

A single test is a snapshot. Values change with every release, plugin update and marketing tag, and because the field data covers 28 days, a regression takes weeks to show up fully and weeks to disappear after the fix. Testing after every larger release and at least monthly catches problems before they settle into the field data. Tracking several page types over time also shows whether an optimization held or was undone by a later change.

Related guides

Each metric has its own guide with thresholds, causes and fixes. The first three are the Core Web Vitals, the other four are supporting metrics that explain why a Core Web Vital fails.

• Largest Contentful Paint (LCP): how fast the main content appears.
• Interaction to Next Paint (INP): how fast the page responds to input.
• Cumulative Layout Shift (CLS): how stable the layout stays while loading.
• First Contentful Paint (FCP): when the first content becomes visible.
• Time to First Byte (TTFB): how fast the server starts to respond.
• Total Blocking Time (TBT): how long long tasks block the main thread.
• Speed Index: how fast the visible area fills in during load.

All fix guides are listed in the performance audits overview.

Core Web Vitals by platform

WordPress

WordPress sites in our measurements pass the Core Web Vitals more often than the overall average, with LCP as the metric most likely to fail because of slow server responses and render-blocking plugin assets. See the WordPress guide.

Shopify

Shopify stores pass more often than the average too, despite being among the heaviest pages; INP is where they fail, driven by app scripts. See the Shopify guide.

Next.js

Next.js sites pass less often than the average in our data, almost entirely because of INP, which hydration of large client-component trees pushes up. The benchmark by CMS and the website speed statistics show the current figures for all platforms. See the Next.js guide.

Frequently asked questions

What are Core Web Vitals?

Three metrics Google defines for page experience: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability.

What are good Core Web Vitals scores?

LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, each measured at the 75th percentile of real page loads.

Are Core Web Vitals a ranking factor?

Yes. Google uses them as part of its page experience signals, based on field data from real Chrome users. They are one signal among many and do not replace relevant content.

What replaced First Input Delay?

Interaction to Next Paint replaced First Input Delay in March 2024. INP covers every interaction during a visit, from input to the next paint, instead of only the delay before the first one.

Why do my lab and field results differ?

Lab data comes from one simulated run on a fixed device and connection. Field data reflects your real visitors over 28 days, with their devices, networks and behavior. Google uses the field data.

How long until improvements show up?

Lab results change right away. Field data in the Chrome UX Report covers a rolling 28-day window, so an improvement takes up to four weeks to show in full.

How do I check Core Web Vitals for my site?

Use PageSpeed Insights for single URLs, the Core Web Vitals report in Search Console for the whole site, and a tool that tests several pages at once to compare templates and track changes over time.