Algorithms

Core Web Vitals: Performance Metrics That Matter for SEO

Pedro Dias Last updated: 2026-04-23 ~18 min read

Understanding LCP, CLS, INP, and supporting metrics like TTFB and FCP. How to interpret field data vs lab data, and why chasing perfect scores rarely makes business sense.

Core Web Vitals influence rankings as a tie-breaker, not a primary factor—yet many teams over-invest in chasing perfect scores. This article covers what LCP, CLS, and INP actually measure, how to interpret field versus lab data, and when performance optimisation makes business sense.

What Core Web Vitals measure

Core Web Vitals (CWV) are Google's standardised metrics for measuring user experience on the web. They focus on three aspects of page experience: loading performance, visual stability, and interactivity.

Google uses these metrics as a ranking signal, though their weight is limited. Understanding how they factor into rankings matters as much as understanding what they measure (see "Core Web Vitals as a ranking factor" below).

The current Core Web Vitals are:

Largest Contentful Paint (LCP): How quickly the main content loads
Cumulative Layout Shift (CLS): How stable the page is visually
Interaction to Next Paint (INP): How responsive the page is to user input

These metrics complement each other. A page that loads fast but shifts around frustrates users. A stable page that takes ten seconds to respond to clicks fails at interactivity. All three must be acceptable for a good overall experience.

Core Web Vitals within page experience

CWV is one component of Google's broader "page experience" ranking systems. Other signals in this category include:

HTTPS: Secure connections are expected; HTTP pages are flagged as insecure
Mobile-friendliness: Content must display properly on mobile devices
No intrusive interstitials: Avoid pop-ups that block content immediately after navigation
Safe browsing: No malware, phishing, or deceptive content

Page experience signals don't carry equal weight. Google has stated that great page experience won't push mediocre content to the top, but among pages with similar relevance and quality, page experience can influence which ranks higher.

There's no single "page experience score" that Google uses. The ranking systems evaluate multiple signals holistically. Optimising one aspect while neglecting others won't produce consistent results.

The three Core Web Vitals

Largest Contentful Paint (LCP)

LCP measures the time from when the page starts loading until the largest content element becomes visible in the viewport. This is typically a hero image, main heading, or prominent text block.

Rating	LCP threshold
Good	≤ 2.5 seconds
Needs improvement	2.5 – 4.0 seconds
Poor	> 4.0 seconds

What affects LCP:

Server response time: Slow TTFB (Time to First Byte) delays everything that follows
Render-blocking resources: CSS and synchronous JavaScript in the <head> prevent the browser from painting content
Resource load time: Large images, web fonts, or other assets that form the LCP element
Client-side rendering: Content built via JavaScript waits for script execution before the LCP element exists

Common LCP elements:

<img> elements
<image> elements inside <svg>
<video> elements with poster images
Elements with background images loaded via CSS
Block-level text elements (<h1>, <p>, etc.)

The LCP element can change during page load. As new content appears, the browser recalculates which element is largest. Only the final LCP element at load completion counts toward the metric.

Identifying your LCP element:

In PageSpeed Insights, the LCP element appears in the "Diagnostics" section. You can filter to show only LCP-related issues using the metric tabs.

In Chrome DevTools:

Open the Performance panel and enable "Screenshots"
Click "Start profiling and reload page"
Find "LCP" on the timing graph
Click the node to reveal which element triggered it

Knowing which element is your LCP is essential. Optimising the wrong image or text block wastes effort.

Cumulative Layout Shift (CLS)

CLS measures visual stability: how much visible content moves unexpectedly during the page lifecycle. Each time an element shifts position without user interaction, it contributes to the CLS score.

Rating	CLS threshold
Good	≤ 0.1
Needs improvement	0.1 – 0.25
Poor	> 0.25

CLS is a unitless score calculated from the fraction of the viewport affected and the distance elements moved. A large element moving slightly might have the same impact as a small element moving significantly.

How CLS is measured:

Google updated CLS methodology to use a "session window" approach. Rather than accumulating all shifts throughout the entire page lifecycle, CLS now measures the maximum burst of layout shifts within a 5-second window. This prevents pages from being penalised for shifts that occur long after initial load (such as infinite scroll content).

Common causes of layout shift:

Images without dimensions: When width and height attributes are missing, the browser can't reserve space before the image loads
Ads, embeds, and iframes: Third-party content that injects itself without reserving space
Dynamically injected content: Banners, cookie notices, or promotional elements added after initial render
Web fonts: Font files loading late and causing text to reflow (Flash of Unstyled Text, or FOUT)
Late-loading JavaScript: Scripts that modify the DOM after visible content has painted

Always include width and height attributes on images, even lazy-loaded ones. Modern browsers use these to calculate aspect ratio and reserve space before the image downloads.

Interaction to Next Paint (INP)

INP measures responsiveness: the delay between a user interaction (click, tap, or keypress) and the browser's visual response. It replaced First Input Delay (FID) as a Core Web Vital in March 2024.

Rating	INP threshold
Good	≤ 200 milliseconds
Needs improvement	200 – 500 milliseconds
Poor	> 500 milliseconds

Unlike FID, which only measured the first interaction, INP considers all interactions throughout the page lifecycle and reports a value representative of the worst interactions. This makes it more comprehensive. A page could pass FID if the first click happened during an idle period, even if subsequent interactions were sluggish.

What affects INP:

Long tasks: JavaScript execution blocking the main thread for 50ms or more delays response to user input
Heavy event handlers: Complex processing triggered by clicks or keypresses
Main thread contention: Third-party scripts, analytics, and widgets competing for processing time
Hydration delays: On JavaScript framework sites, the page may look interactive before event handlers are attached

INP has three components: input delay (time before the browser can start processing), processing time (event handler execution), and presentation delay (browser rendering the update). All three contribute to the final score.

INP and lab testing:

Lab tools like Lighthouse can't measure real INP because there's no actual user to interact with the page. Instead, Total Blocking Time (TBT) serves as the proxy metric. TBT measures the total time the main thread was blocked by long tasks during page load. High TBT typically correlates with poor INP, making it useful for diagnosis even though it's not the actual metric Google uses for ranking.

Supporting performance metrics

Core Web Vitals don't exist in isolation. Several supporting metrics help diagnose performance issues and provide additional context.

Time to First Byte (TTFB)

TTFB measures how long it takes for the browser to receive the first byte of response from the server. It includes DNS lookup, TCP connection, TLS negotiation, and server processing time.

Rating	TTFB threshold
Good	≤ 800 milliseconds
Needs improvement	800 – 1800 milliseconds
Poor	> 1800 milliseconds

TTFB isn't a Core Web Vital, but it directly affects LCP. A slow server response pushes everything else later. If TTFB is 2 seconds, LCP cannot be under 2 seconds; there's a hard floor.

TTFB contributors:

Server-side processing (database queries, API calls, rendering)
Network latency between user and server
CDN cache misses requiring origin fetches
TLS handshake overhead

Beyond user experience, TTFB affects discoverability. AI systems assembling responses in real-time are particularly sensitive to latency, and slow pages may timeout during retrieval operations. For content targeting AI citations, sub-200ms TTFB becomes a practical threshold.

First Contentful Paint (FCP)

FCP measures when the browser renders the first piece of DOM content: any text, image, or canvas paint. It's earlier than LCP because it doesn't wait for the largest element.

Rating	FCP threshold
Good	≤ 1.8 seconds
Needs improvement	1.8 – 3.0 seconds
Poor	> 3.0 seconds

FCP indicates perceived load speed. Users see something happening even if the main content hasn't loaded yet. A large gap between FCP and LCP suggests the hero content is loading slowly relative to initial page rendering.

First Input Delay (FID) (deprecated)

FID measured the delay between a user's first interaction and the browser's response. It was retired as a Core Web Vital in March 2024, replaced by INP, which measures responsiveness across all interactions rather than just the first one.

If you see FID in older reports or tools, it's now a diagnostic metric rather than a Core Web Vital. Focus on INP for current optimisation work.

Lab data vs field data

Understanding the difference between lab (synthetic) and field (real user) data is essential for interpreting Core Web Vitals correctly. These data sources measure the same metrics but often report different results.

Lab data (synthetic testing)

Lab data comes from controlled testing environments: tools like Lighthouse, WebPageTest, or Chrome DevTools. These tools load your page under simulated conditions with predetermined network speeds, device capabilities, and geographic locations.

Characteristics of lab data:

Reproducible: Run the same test repeatedly for consistent comparisons
Controlled variables: Isolate specific issues by changing one factor at a time
Immediate feedback: Test changes before deployment
No user interaction: Cannot measure INP meaningfully (uses TBT as proxy)
Single device/network profile: Typically simulates mid-tier mobile on throttled 4G

Limitations:

Lab data represents one possible experience, not the distribution of actual user experiences. A Lighthouse test from a well-connected server might score 95 while real users on slow mobile connections score 45.

Field data (Real User Monitoring)

Field data comes from actual users visiting your site. Google collects this through the Chrome User Experience Report (CrUX), which aggregates anonymised performance data from Chrome users who have opted in.

Characteristics of field data:

Representative of real users: Captures the actual distribution of experiences
Includes diverse conditions: Different devices, networks, locations, and usage patterns
Measures actual INP: Real user interactions, not simulated ones
Delayed reporting: CrUX data is aggregated over 28-day periods
Minimum traffic requirements: Sites with insufficient traffic won't have CrUX data

Where field data appears:

Search Console Core Web Vitals report
PageSpeed Insights (when available)
CrUX public dataset via BigQuery
Third-party RUM providers (not Google's data, but your own field data)

How CrUX collects data

Not all users contribute to CrUX. To be included, users must:

Use Chrome (desktop or Android). Safari and Firefox users are never counted.
Enable usage statistic reporting in Chrome
Sync their browser history (be signed in to Chrome)
Not have a Sync passphrase enabled

This Chrome-only collection has practical implications. iPhone users are never counted in CrUX data because Chrome on iOS uses Apple's WebKit rendering engine, not Chromium. For sites with significant iOS traffic, CrUX may over-represent Android users, who often have slower, more variable device performance.

Pages must also meet minimum traffic thresholds. Low-traffic pages may not have individual CrUX data; Google may use data from similar page groups or the origin as a whole.

The 75th percentile threshold

Google evaluates Core Web Vitals at the 75th percentile of user experiences, not the average or median. This means 75% of your users must have a "good" experience for the page to pass.

If 70% of users experience "good" LCP and 5% experience "needs improvement," your page fails the threshold, even though most users had an acceptable experience. This percentile approach ensures that a poor experience for a significant minority isn't masked by good experiences for the majority.

Geographic impact on scores

User location matters. CrUX data includes all users globally, weighted equally. Sites with significant traffic from regions with slower internet connectivity or older devices will see this reflected in their scores.

Lower scores from geographic distribution aren't a penalty; they reflect actual user experience. If your users are distributed globally, your infrastructure needs to serve them all acceptably. CDN usage becomes critical for sites with international audiences, as it reduces TTFB for users far from the origin server.

Google uses field data (CrUX) for ranking purposes, not lab data. Your Lighthouse score doesn't directly affect rankings. What matters is how real Chrome users experience your pages.

Why scores differ between lab and field

Several factors cause discrepancies:

Device diversity: Lab tests typically simulate one device; field data includes everything from old Android phones to new iPhones
Network conditions: Throttled lab connections don't capture the variability of real-world networks
Geographic distribution: Users far from your servers experience higher latency
Third-party scripts: Ad networks, analytics, and widgets may behave differently under real load
User behaviour: Scroll patterns, interaction timing, and session length affect CLS and INP
Caching: Return visitors have different experiences than first-time visitors; lab tests typically don't account for this

A site can pass lab tests while failing in the field (or vice versa). Both data sources are valuable for different purposes: lab data for debugging and development, field data for understanding actual user experience.

Real User Monitoring (RUM)

RUM involves collecting performance metrics from actual users as they browse your site. While CrUX is Google's RUM data, you can implement your own RUM to get more granular insights.

Why implement RUM beyond CrUX

CrUX has limitations:

Chrome only: Doesn't include Safari, Firefox, or other browsers
28-day aggregation: Can't detect issues immediately
Limited segmentation: Page-level data without custom dimensions
Traffic thresholds: Low-traffic pages may not appear
No session context: Can't correlate performance with user journeys

Custom RUM solutions (Google Analytics 4 with Web Vitals integration, or dedicated RUM platforms) provide:

Real-time alerting: Detect performance regressions immediately
Custom segmentation: Slice data by user type, device, geography, or custom attributes
Session correlation: Understand how performance affects conversions and engagement
All browsers: Not limited to Chrome
Page-level granularity: Data for every page, not just those meeting CrUX thresholds

Implementing basic RUM

The web-vitals JavaScript library provides a standardised way to collect Core Web Vitals:

import { onLCP, onCLS, onINP, onFCP, onTTFB } from 'web-vitals';

function sendToAnalytics(metric) {
  // Send to your analytics endpoint
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    delta: metric.delta,
    id: metric.id,
  });
  
  // Use sendBeacon for reliability during page unload
  navigator.sendBeacon('/analytics', body);
}

onLCP(sendToAnalytics);
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onFCP(sendToAnalytics);
onTTFB(sendToAnalytics);

This captures metrics as users experience them, providing your own field data independent of CrUX.

The law of diminishing returns

Performance optimisation follows a steep curve. The initial improvements (fixing obvious issues) yield dramatic gains. But as scores improve, each additional point requires disproportionately more effort.

The 80/20 principle in practice

A small number of high-impact fixes typically account for most of the measurable improvement. The common ones:

Compress and properly size images: Often the single biggest LCP improvement
Add dimension attributes to images: Eliminates a major source of CLS
Defer non-critical JavaScript: Improves both LCP and INP
Enable compression and caching: Server configuration that benefits all metrics
Use a CDN: Reduces TTFB for geographically distributed users

These basic optimisations can take a site from failing to passing thresholds. The remaining refinements (shaving milliseconds off an already-fast LCP, eliminating minor layout shifts, optimising JavaScript execution) require increasingly specialised work.

When perfect scores don't matter

Consider what "passing" means:

Metric	Good threshold	Benefit of exceeding
LCP	≤ 2.5s	Minimal ranking benefit; user perception similar
CLS	≤ 0.1	Users don't notice difference between 0.05 and 0.02
INP	≤ 200ms	Sub-100ms feels "instant" but doesn't rank better

Once you're in the "good" category, further optimisation has negligible ranking impact. A site with LCP of 2.0s isn't disadvantaged compared to one at 1.0s; both pass. The ranking signal is binary: good or not good.

Chasing a Lighthouse score of 100 is rarely a good use of resources. The score is a diagnostic tool, not a target. A score of 85 with all Core Web Vitals passing is effectively equivalent to 100 for ranking purposes.

Opportunity cost

Time spent pursuing marginal performance gains has opportunity cost. That engineering effort could instead go toward:

Creating new content that serves user needs
Improving site functionality
Fixing bugs that affect conversions
Building features users are requesting

Performance optimisation should be prioritised relative to business impact, not pursued as an end in itself.

Platform-level improvements

The ecosystem is increasingly handling optimisations at the platform level. WordPress now preloads the first image by default. Cloudflare has rolled out Early Hints, Signed Exchanges, and HTTP/3. Browsers themselves are becoming smarter about resource prioritisation.

For sites on modern platforms with current CDN configurations, the effort required to achieve passing scores is often minimal. Manual optimisation matters most for legacy systems, custom implementations, or sites with unusual performance constraints.

Core Web Vitals as a ranking factor

Google confirmed Core Web Vitals as a ranking factor in the June 2021 Page Experience update. However, the way CWV affects rankings is commonly misunderstood.

Tie-breaker, not primary factor

John Mueller and other Google representatives have consistently characterised CWV as a tie-breaker. At Pubcon in September 2023, Gary Illyes stated that most sites won't see significant ranking benefit from CWV improvements. When two pages are otherwise equivalent in content quality, relevance, and authority, the one with better Core Web Vitals may rank higher.

In practice, the tie-breaker role means:

A page with mediocre content won't rank well just because it's fast
A page with excellent content won't be demoted to page five because of slow LCP
CWV matters most in competitive niches where content quality is similar across results

Content relevance, backlinks, and topical authority remain dominant factors. CWV is one signal among hundreds, weighted to reflect its role as a user experience indicator rather than a content quality measure.

When to prioritise CWV optimisation

Core Web Vitals work becomes strategically important when:

Content quality is already strong: You've addressed E-E-A-T, topical coverage, and user intent
Technical foundation is solid: Crawlability, indexing, and site structure are handled
Competitive position is established: You're competing for positions, not just visibility
User experience is a differentiator: E-commerce, news, and other high-competition verticals

For sites earlier in their SEO maturity, CWV optimisation is premature. Fix crawl errors, improve content quality, and build topical authority first. CWV is the polish, not the foundation.

Site-level vs page-level assessment

CrUX data is collected at page level but often assessed at URL group level. Google groups similar pages (e.g., all product pages, all blog posts) and may apply performance assessments at the group level rather than individual URL level.

URL grouping has practical implications:

One slow page won't necessarily drag down your entire site
Template-level fixes benefit all pages using that template
High-traffic pages contribute more to URL group scores
Low-traffic pages inherit group-level assessments

Understanding this grouping helps prioritise: fix the template used by thousands of pages before optimising a single low-traffic page.

Mobile vs desktop assessment

CrUX reports separate data for mobile and desktop, and Google ranks pages separately based on the device type of the search. Mobile Core Web Vitals affect mobile rankings; desktop metrics affect desktop rankings.

Mobile typically requires more attention because:

Google uses mobile-first indexing
Mobile devices have more constrained CPU and memory
Mobile networks are often slower and less reliable
The same page often performs worse on mobile than desktop

Both form factors appear in Search Console's Core Web Vitals report.

Diagnosing and fixing common issues

LCP optimisation

Diagnose with:

PageSpeed Insights "Diagnostics" section (shows the LCP element)
DevTools Performance panel with screenshots enabled
WebPageTest waterfall (see resource loading sequence)

Common fixes:

Preload the LCP image: <link rel="preload" as="image" href="hero.jpg">
Optimise image format: Use WebP or AVIF with appropriate compression
Eliminate render-blocking resources: Defer non-critical CSS and JavaScript
Improve server response time: Caching, CDN, server-side optimisation
Avoid client-side rendering for hero content: Server-render the LCP element
Don't lazy load above-the-fold images: Lazy loading the LCP element delays it; only lazy load images below the fold

CLS optimisation

Diagnose with:

Lighthouse "Avoid large layout shifts" diagnostic
DevTools Performance panel (layout shift timeline markers)
Layout Shift attribution in web-vitals library

Common fixes:

Specify image dimensions: Include width and height on all <img> tags
Reserve space for ads/embeds: Use min-height or aspect-ratio containers
Preload fonts: <link rel="preload" as="font" crossorigin>
Avoid inserting content above existing content: Append below, not above
Use transform for animations: transform doesn't cause layout shifts; top/left do
Ensure bfcache eligibility: Pages eligible for back/forward cache restore without layout shifts when users navigate with browser buttons

INP optimisation

Diagnose with:

Chrome DevTools Performance panel (long tasks)
Total Blocking Time (TBT) in Lighthouse as a proxy
web-vitals library with attribution
Real User Monitoring with interaction breakdown

Common fixes:

Break up long tasks: Split heavy JavaScript into smaller chunks using setTimeout or scheduler.yield()
Use requestIdleCallback for non-urgent work: Let browser prioritise user input
Reduce third-party script impact: Defer analytics and widgets until after interaction
Optimise event handlers: Keep click and input handlers lightweight
Use web workers for heavy computation: Move processing off the main thread

FAQs

Does Lighthouse score affect rankings?

No. Lighthouse is a lab tool; Google uses field data (CrUX) for ranking purposes. A Lighthouse score of 50 with passing CrUX metrics won't hurt rankings. See "Lab data vs field data" above for how these data sources differ.

How often does CrUX data update?

CrUX uses a rolling 28-day window, updated daily. After making performance improvements, it takes roughly a month for the data to fully reflect the changes. PageSpeed Insights and Search Console display this aggregated data.

What if my site doesn't have CrUX data?

Sites with insufficient Chrome traffic won't appear in CrUX. In these cases, Google may not have field data to use as a ranking signal. This isn't a penalty; the signal simply doesn't apply. Google may fall back to data from similar page groups or the origin as a whole. Focus on growing traffic and ensuring performance is acceptable through lab testing.

Are iPhone users included in Core Web Vitals data?

No. CrUX only collects data from Chrome on desktop and Android (see "How CrUX collects data" above for the full eligibility criteria). If your audience skews heavily toward iOS, your CrUX data may not represent the majority of your users.

Do Core Web Vitals affect Google Discover eligibility?

Yes. Google has stated that pages must meet Core Web Vitals thresholds for Discover eligibility. For content-driven sites relying on Discover traffic, CWV optimisation has direct traffic implications beyond search rankings.

Key takeaways

Three metrics matter: LCP (loading), CLS (stability), and INP (interactivity) are the current Core Web Vitals. TTFB and FCP are supporting metrics that help diagnose issues.
Field data trumps lab data: Google uses CrUX (real user data from Chrome) for rankings, not Lighthouse scores. Your synthetic test results are diagnostic tools, not ranking factors.
75th percentile, not average: 75% of your users must have a "good" experience for a page to pass. A poor experience for a significant minority will fail the threshold even if most users are fine.
CWV is a tie-breaker: It becomes relevant when content quality, relevance, and authority are comparable. For most sites, content and technical fundamentals matter more.
Passing beats perfection: Once you're in the "good" threshold for all metrics, additional optimisation has negligible ranking benefit. A score of 85 and 100 are equivalent if Core Web Vitals pass.
Prioritise based on maturity: CWV optimisation belongs late in the SEO roadmap, after content quality, site structure, and technical fundamentals are addressed.

Core Web Vitals: Performance Metrics That Matter for SEO

What Core Web Vitals measure

Core Web Vitals within page experience

The three Core Web Vitals

Largest Contentful Paint (LCP)

Cumulative Layout Shift (CLS)

Interaction to Next Paint (INP)

Supporting performance metrics

Time to First Byte (TTFB)

First Contentful Paint (FCP)

First Input Delay (FID) (deprecated)

Lab data vs field data

Lab data (synthetic testing)

Field data (Real User Monitoring)

How CrUX collects data

The 75th percentile threshold

Geographic impact on scores

Why scores differ between lab and field

Real User Monitoring (RUM)

Why implement RUM beyond CrUX

Implementing basic RUM

The law of diminishing returns

The 80/20 principle in practice

When perfect scores don't matter

Opportunity cost

Platform-level improvements

Core Web Vitals as a ranking factor

Tie-breaker, not primary factor

When to prioritise CWV optimisation

Site-level vs page-level assessment

Mobile vs desktop assessment

Diagnosing and fixing common issues

LCP optimisation

CLS optimisation

INP optimisation

FAQs

Does Lighthouse score affect rankings?

How often does CrUX data update?

What if my site doesn't have CrUX data?

Are iPhone users included in Core Web Vitals data?

Do Core Web Vitals affect Google Discover eligibility?

Key takeaways

Further reading