What Are Core Web Vitals?

What Core Web Vitals are

Core Web Vitals (CWV) are a set of three specific metrics used by Google to measure the page experience of a website. These metrics quantify aspects of user experience such as loading performance, interactivity, and visual stability. Google introduced Core Web Vitals as a significant factor in its ranking algorithms, emphasizing their role in providing a positive user experience.

The three Core Web Vitals are:

• Largest Contentful Paint (LCP): Measures loading performance.
• Interaction to Next Paint (INP): Measures interactivity.
• Cumulative Layout Shift (CLS): Measures visual stability.

To achieve a "good" rating from Google, a webpage must meet the specified thresholds for all three CWV metrics at the 75th percentile of its traffic. This means that at least 75% of user visits to the page must satisfy the "good" criteria for LCP, INP, and CLS.

While Core Web Vitals are a confirmed ranking signal, their weight is modest compared to the quality and relevance of content. A page with excellent content that clearly addresses user intent will typically outrank a faster page with weaker, less relevant content, even if the former has poorer CWV scores. Google prioritizes delivering the most useful and authoritative information to its users. Core Web Vitals serve as a tie-breaker or a minor enhancement to rankings when content quality is otherwise comparable.

LCP: Largest Contentful Paint (<2.5s)

Largest Contentful Paint (LCP) measures how long it takes for the largest content element on a webpage to become visible within the user's viewport. This metric is a key indicator of loading performance. The "largest content element" can be an image, a <video> element, or a block of text, among other things. It's the point at which the main content of the page has likely loaded.

Thresholds:

• Good: Less than 2.5 seconds
• Needs Improvement: Between 2.5 and 4.0 seconds
• Poor: Greater than 4.0 seconds

For a page to pass the LCP assessment, 75% of user visits must experience an LCP of less than 2.5 seconds. For example, if 100 users visit a page, at least 75 of those users must see the largest content element load within 2.5 seconds.

Factors influencing LCP:

• Slow server response times
• Render-blocking JavaScript and CSS
• Slow resource load times (e.g., large images, videos)
• Client-side rendering

Optimizing LCP typically involves addressing these factors to ensure the primary content loads quickly.

INP: Interaction to Next Paint (<200ms)

Interaction to Next Paint (INP) measures the responsiveness of a page to user interactions. It assesses the latency of all interactions that occur during a user's visit to a page and reports a single, representative value. An interaction can be a click, tap, or keyboard input. The metric measures the delay from when a user initiates an interaction until the browser visualizes the next frame, showing the visual update resulting from that interaction.

INP replaced First Input Delay (FID) as a stable Core Web Vital in March 2024. While FID only accounted for the delay of the first interaction, INP considers the latency of all interactions, providing a more comprehensive measure of overall page responsiveness.

Thresholds:

• Good: Less than 200 milliseconds
• Needs Improvement: Between 200 and 500 milliseconds
• Poor: Greater than 500 milliseconds

To pass the INP assessment, 75% of user visits must have their interactions processed and visually updated within 200 milliseconds. If 100 users interact with a page, at least 75 of them must experience a consistent interaction latency of under 200ms across all their clicks, taps, or key presses.

Factors influencing INP:

• Long-running JavaScript tasks that block the main thread
• Complex or inefficient event handlers
• Large layout shifts after interaction
• Slow server response and resource fetching for subsequent interactions.

Optimizing INP often involves improving the efficiency of JavaScript execution and reducing the time the main thread is blocked.

CLS: Cumulative Layout Shift (<0.1)

Cumulative Layout Shift (CLS) measures the visual stability of a webpage. It quantifies the total sum of all individual layout shift scores for every unexpected layout shift that occurs during the entire lifespan of the page. An unexpected layout shift happens when a visible element changes its starting position from one rendered frame to the next without user initiation. These shifts can be disorienting and lead to poor user experiences, such as accidentally clicking the wrong button.

Thresholds:

• Good: Less than 0.1
• Needs Improvement: Between 0.1 and 0.25
• Poor: Greater than 0.25

For a page to pass the CLS assessment, 75% of user visits must experience a CLS score of less than 0.1. This means that for 75% of your page's visitors, the total unexpected movement of elements on the screen, measured by Google's algorithm, must be minimal.

How CLS is calculated:

CLS is calculated by multiplying two factors:

• Impact fraction: Measures the instability of an element in the viewport area between two rendered frames.
• Distance fraction: Measures the greatest distance any element that moved in the layout shift moved, scaled as a fraction of the viewport's dimensions.

CLS = Impact Fraction * Distance Fraction

Factors causing layout shifts:

• Images or videos without dimension attributes (height and width)
• Dynamic content insertions (e.g., ads, embedded content) without reserving space
• Web fonts causing FOIT (Flash of Invisible Text) or FOUT (Flash of Unstyled Text)
• Actions waiting for a network response before updating the DOM

Optimizing CLS primarily involves reserving space for elements that load later and avoiding dynamic content injection above existing content.

Field data vs lab data — use field data

When analyzing Core Web Vitals, it is crucial to understand the difference between field data and lab data. Each provides valuable insights, but for assessing actual user experience and Google's ranking signals, field data is paramount.

Field Data (Real User Monitoring - RUM)

Field data, also known as Real User Monitoring (RUM) data, captures real-world performance metrics from actual user interactions with your website. This data is collected from users visiting your site in various environments, including different devices, network conditions, and locations.

Key characteristics of field data:

• Reflects actual user experience: Provides the most accurate picture of how your users experience your site.
• Includes all variables: Accounts for diverse factors like network latency, device performance, browser extensions, and user behavior.
• Used by Google for ranking: Google's algorithms primarily use field data (specifically, data from the Chrome User Experience Report, or CrUX) to assess Core Web Vitals for ranking purposes.
• Available in Google Search Console: The Core Web Vitals report in Google Search Console uses CrUX data.

Because field data represents the actual conditions your users encounter, it is the definitive source for understanding your Core Web Vitals performance as Google sees it.

Lab Data (Synthetic Monitoring)

Lab data, also known as synthetic monitoring data, is collected in a controlled environment using pre-defined settings. Tools like Lighthouse (available in Chrome DevTools), PageSpeed Insights (which uses Lighthouse), and WebPageTest generate lab data by simulating a page load under consistent conditions (e.g., specific device, network speed).

Key characteristics of lab data:

• Reproducible results: Useful for debugging and identifying performance bottlenecks in development.
• Consistent environment: Allows for precise measurement and comparison of specific changes.
• Immediate feedback: Can be run on demand, offering quicker insights during development.
• May not reflect real-world usage: Since it's simulated, lab data might not fully capture the variability of actual user experiences.

While lab data is excellent for debugging and pinpointing issues, it should not be the sole basis for judging your Core Web Vitals performance or predicting Google's assessment. A page might score well in a lab test but perform poorly for real users due to factors not simulated.

Conclusion: Prioritize Field Data

When evaluating your Core Web Vitals, always prioritize field data. It is the data source that matters most for search engine rankings and for truly understanding your users' experiences. Use lab data as a diagnostic tool to investigate issues identified in field data.

How LemRank measures CWV

LemRank integrates directly with the Google Search Console API to retrieve the Core Web Vitals report for your tracked properties. This means that LemRank displays the field data (Real User Monitoring data) that Google itself uses for ranking purposes.

When you link your Google Search Console account to LemRank, our platform imports the Core Web Vitals status for all pages and URLs within your verified properties. This data is updated regularly by Google.

LemRank presents this field data in an organized and actionable format. For each URL or group of URLs, you will see their status regarding LCP, INP, and CLS, categorized as "Good," "Needs Improvement," or "Poor," directly reflecting Google's assessment.

This approach ensures that the Core Web Vitals information available in LemRank is consistent with what Google reports in Search Console and what it uses to evaluate your site's page experience. LemRank does not generate its own simulated (lab) CWV data; instead, it provides a streamlined interface to monitor your site's performance based on Google's authoritative field data.

Related

• SERP features explained