Core Web Vitals & PageSpeed: Why Slow Pages Cost You Customers & Rankings

Core Web Vitals are three metrics defined by Google for the user experience of a web page: Largest Contentful Paint (LCP) for loading performance, Interaction to Next Paint (INP) for interactivity, and Cumulative Layout Shift (CLS) for visual stability. They factor into Google ranking as a page experience signal. As of 2026.

What Are Core Web Vitals, and Which Three Metrics Count in 2026?

The three current Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). According to web.dev (Google), they measure a page's loading performance, interactivity and visual stability. This way they cover the three moments in which users experience a page as fast or sluggish: loading, reacting to clicks and the layout staying still.

An important change: INP officially became a Core Web Vital on March 12, 2024, replacing First Input Delay (FID), as confirmed by web.dev (Google). FID is therefore no longer a Core Web Vital. Anyone still optimizing for FID is measuring the wrong metric.

Which Thresholds Count as Good, Needs Improvement and Poor?

Google sets fixed limits for each Core Web Vital, measured at the 75th percentile of all page visits. That means: only once 3 out of 4 visits reach the target level does a page count as good. Important: according to web.dev (Google, 2020), the thresholds themselves are identical for mobile and desktop, only the 75th percentile measurement is collected separately per device type, not the threshold itself.

Metric	Good	Poor	Measurement point
LCP (loading performance)	≤ 2.5 s	> 4 s	75th percentile
INP (interactivity)	≤ 200 ms	> 500 ms	75th percentile
CLS (stability)	≤ 0.1	> 0.25	75th percentile

Values between good and poor count as needs improvement. These thresholds are not arbitrary: Google explicitly confirms the 2.5-s/4-s boundary for LCP and the 0.1/0.25 boundary for CLS in web.dev (2020) as reasoned limits that balance a good user experience with real world achievability.

What Does Largest Contentful Paint (LCP) Measure, and Why 2.5 Seconds?

LCP measures how long it takes until the largest visible element in the viewport has rendered, usually a hero image or a large heading. According to web.dev (Google), LCP counts as good at ≤ 2.5 seconds and as poor above 4 seconds, each measured at the 75th percentile.

The 2.5 seconds mark the point at which users still perceive a page as having loaded quickly. If the main element is delayed beyond that, the page feels sluggish, even if the rest has long since arrived. LCP thus reflects the perceived loading speed, not just the first pixel.

What Does Interaction to Next Paint (INP) Mean, and How Does It Differ From FID?

INP measures how quickly a page visibly responds to input. According to web.dev (Google), it counts as good at ≤ 200 milliseconds and as poor above 500 milliseconds (75th percentile). What is measured is the span from the input to the next rendered frame.

The difference to the replaced FID is crucial: FID only measured the input delay of the very first interaction. According to web.dev, INP observes all interactions on a page, from the input delay through the event handlers to the next rendered frame. This means INP also captures janky reactions deep in the usage history, which FID simply ignored.

What Is Cumulative Layout Shift (CLS), and Why Does My Layout Jump?

CLS measures how much the layout shifts unexpectedly while a page loads. According to web.dev (Google), the value counts as good at ≤ 0.1 and as poor above 0.25 (75th percentile). Unlike LCP and INP, CLS is not a time but a dimensionless shift score.

Layout jumps typically arise from images without reserved space, ads inserted after the fact, or late loading fonts. The practical damage: someone who wants to click a button, and the layout jumps at that exact moment, ends up on the wrong element. CLS penalizes exactly this kind of frustration.

Do Core Web Vitals Really Influence Google Ranking?

Yes, but as part of a bundle, not as an isolated single factor. Google classifies Core Web Vitals in Google Search Central as part of the page experience aspects: "This, along with other page experience aspects, aligns with what our core ranking systems seek to reward." So it is a ranking relevant signal, but not a single weighted lever that catapults a weak page to the top.

The honest assessment: good Core Web Vitals do not replace good content. With comparable relevance, though, they can tip the balance, and poor values are an avoidable disadvantage. A technically well built page, of the kind professional web design delivers, has this foundation under control from the start.

Do Slow Pages Really Cost Customers?

Yes, and it can be quantified. According to Google/SOASTA data, the probability of a bounce on mobile pages increases by 32 % when load time rises from 1 to 3 seconds, as shown by Think with Google / SOASTA (2017). Going from 1 to 5 seconds, it is +90 %, and from 1 to 10 seconds, +123 %.

Translated into everyday terms: every second of load time costs reach before the content is even seen. Anyone putting budget into ads or content gives part of it away to a slow page. Speed is therefore not a technical detail but a conversion factor.

Lab Data vs. Field Data: What Does PageSpeed Insights Really Tell You?

PageSpeed Insights combines two data sources that are often confused. The field data comes from real user sessions: according to Google for Developers, the tool shows values for FCP, INP, LCP and CLS from the Chrome User Experience Report (CrUX) over the last 28 days. This field data is ranking relevant.

The lab data, on the other hand, comes from a simulated Lighthouse measurement under standard conditions, reproducible but not what real users experience. According to Google, the Lighthouse performance score counts as good from 90 up, 50 to 89 as needs improvement, and under 50 as poor. Important: the lab score is a diagnostic tool, the CrUX field data is the standard for the assessment.

How Do I Concretely Improve My Core Web Vitals?

The most effective levers differ by metric. web.dev (Google) names concrete measures with the biggest effect for each of the three metrics.

Improving LCP: Prioritize Loading Performance

• Make the LCP resource discoverable in the initial HTML (a real img src instead of loading it later via JavaScript).
• Set fetchpriority="high" on the LCP image and remove loading="lazy" there.
• Use a CDN: according to web.dev, only 33 % of HTML documents are delivered through a CDN.

Improving INP: Increase Responsiveness

• Break up long tasks and yield frequently so the main thread stays free.
• Reduce unnecessary JavaScript: through code splitting and removing dead code.
• Minimize rendering work, for example by avoiding forced layouts and using CSS containment.

Improving CLS: Stabilize the Layout

• Set width/height or CSS dimensions for images: according to web.dev, 66 % of pages have at least one image without dimensions.
• Enable the back/forward cache (bfcache).
• Avoid layout changing animations and use CSS transform instead.

FAQ: Frequently Asked Questions About Core Web Vitals and PageSpeed

What Are the Three Core Web Vitals in 2026?

The three Core Web Vitals are LCP (loading performance), INP (interactivity) and CLS (visual stability), as defined by web.dev (Google). INP has replaced the earlier First Input Delay (FID) since March 12, 2024.

Which LCP Value Is Good?

LCP counts as good at ≤ 2.5 seconds and as poor above 4 seconds, measured at the 75th percentile of all page visits (source: web.dev, Google).

Is INP the Same as FID?

No. FID only measured the delay of the first interaction. INP observes all interactions on a page up to the next rendered frame and has been the official Core Web Vital since March 12, 2024 (source: web.dev, Google).

What Is the Difference Between Lab Data and Field Data?

Lab data comes from a simulated Lighthouse measurement, field data from real user sessions in the Chrome User Experience Report over 28 days. For the assessment, the field data counts (source: Google for Developers).

From What PageSpeed Score Is a Page Good?

The Lighthouse performance score counts as good from 90 up, 50 to 89 as needs improvement, and under 50 as poor (source: Google for Developers). This lab score is a diagnostic value, not the ranking standard.

Do Core Web Vitals Influence Ranking?

Yes, as part of the page experience signals, but not as an isolated single factor. Google describes them as an aspect that aligns with what the core ranking systems reward (source: Google Search Central).

How Does Load Time Affect Bounces?

If mobile load time rises from 1 to 3 seconds, the bounce probability increases by 32 % (source: Think with Google / SOASTA, 2017). Going from 1 to 5 seconds, it is +90 %.

Sources

• web.dev (Google): Web Vitals (2024)
• web.dev (Google): How Core Web Vitals thresholds were defined (2020)
• web.dev (Google): INP becomes a Core Web Vital on March 12 (2024)
• Google Search Central: Understanding Core Web Vitals and Google Search (2024)
• Think with Google / SOASTA Research: Mobile Page Speed Benchmarks (2017)
• Google for Developers: About PageSpeed Insights (2024)
• web.dev (Google): The most effective ways to improve Core Web Vitals (2024)

Note: this article provides general technical information and does not constitute a binding performance or ranking guarantee. Thresholds and evaluation logic reflect the state documented by Google as of 2026 and may change. Author: Alexander Weipprecht. As of June 2026.