Core Web Vitals: What They Are and How to Improve Them

Most websites fail Google's Core Web Vitals thresholds, with only 39% of pages passing all three metrics according to the latest Chrome UX Report data. These performance signals directly impact both user experience and search rankings, yet many businesses struggle to understand what they measure or how to improve them. Core Web Vitals represent Google's attempt to quantify the user experience through three specific metrics: loading performance, interactivity, and visual stability.

If you're looking for expert help in this area, explore how Indexed's technical SEO can drive measurable results for your business.

What Are Core Web Vitals

Core Web Vitals are a set of three user experience metrics that Google considers essential for measuring page experience. Introduced in 2020 and implemented as a ranking factor in 2021, these metrics focus on real-world user experience rather than purely technical performance measurements.

The Three Core Web Vitals Metrics

Each Core Web Vital measures a different aspect of user experience:

• Largest Contentful Paint (LCP) - Measures loading performance by tracking when the largest visible element renders
• First Input Delay (FID) - Measures interactivity by recording the delay between user interaction and browser response
• Cumulative Layout Shift (CLS) - Measures visual stability by quantifying unexpected layout changes during page load

According to Google's official documentation, these metrics are designed to capture the core aspects of user experience that matter most to real users browsing the web.

How Core Web Vitals Are Measured

Google collects Core Web Vitals data through the Chrome User Experience Report (CrUX), which aggregates anonymised performance data from Chrome users who have opted into usage statistics. This field data provides a more accurate representation of real user experience than synthetic testing alone.

The metrics are evaluated using the 75th percentile of page loads, segmented by device type (mobile and desktop). A page needs to meet the "good" thresholds for all three metrics to pass Core Web Vitals assessment.

Largest Contentful Paint (LCP)

Largest Contentful Paint measures how quickly the main content of a page loads by identifying when the largest visible element appears in the viewport. This metric provides a user-centric view of loading performance, as it correlates with when users perceive the page as mostly loaded.

LCP Thresholds and Common Elements

Google defines the following thresholds for LCP:

• Good: 2.5 seconds or less
• Needs Improvement: Between 2.5 and 4.0 seconds
• Poor: More than 4.0 seconds

The largest contentful element is typically one of the following:

• Large images or image elements within containers
• Video poster images
• Block-level elements containing text
• Background images loaded via CSS

Common LCP Issues and Solutions

Research from web.dev identifies four main factors that affect LCP performance:

Slow server response times can be addressed by:

• Optimising server-side code and database queries
• Implementing robust caching strategies
• Using a Content Delivery Network (CDN)
• Upgrading hosting infrastructure

Render-blocking JavaScript and CSS require:

• Minifying and compressing CSS and JavaScript files
• Deferring non-critical JavaScript
• Inlining critical CSS
• Removing unused code

Slow resource load times benefit from:

• Optimising and compressing images
• Preloading important resources
• Using modern image formats like WebP
• Implementing lazy loading for below-the-fold content

First Input Delay (FID)

First Input Delay measures the time between when a user first interacts with your page and when the browser begins processing that interaction. This metric captures the frustration users experience when they click, tap, or press keys but nothing happens immediately.

FID Measurement and Thresholds

FID only measures the delay before processing begins, not the time it takes to complete the interaction or update the UI. Google's thresholds are:

• Good: 100 milliseconds or less
• Needs Improvement: Between 100 and 300 milliseconds
• Poor: More than 300 milliseconds

It's important to note that FID can only be measured with real user data, as it requires actual user interactions. Lab tools like Lighthouse use Total Blocking Time (TBT) as a proxy metric for FID optimisation.

Improving First Input Delay

FID problems typically stem from heavy JavaScript execution blocking the main thread. Google's JavaScript optimisation guide recommends several strategies:

Reduce JavaScript execution time:

• Split large JavaScript bundles using code splitting
• Remove unused JavaScript code
• Minimise and compress JavaScript files
• Use web workers for CPU-intensive tasks

Optimise third-party JavaScript:

• Load third-party scripts asynchronously
• Use resource hints like dns-prefetch and preconnect
• Implement lazy loading for non-critical third-party content
• Regular audit and removal of unnecessary third-party scripts

Cumulative Layout Shift (CLS)

Cumulative Layout Shift measures visual stability by quantifying how much visible content shifts during the page load process. Unexpected layout shifts can cause users to accidentally click wrong elements or lose their place while reading, creating a frustrating browsing experience.

How CLS Is Calculated

CLS is calculated by multiplying the impact fraction (how much of the viewport was affected) by the distance fraction (how far elements moved). The score represents the sum of all unexpected layout shifts that occur during the page's lifetime.

Google's CLS thresholds are:

• Good: 0.1 or less
• Needs Improvement: Between 0.1 and 0.25
• Poor: More than 0.25

Common Causes of Layout Shift

According to web.dev research, the most common causes of poor CLS scores include:

Images and videos without dimensions:

• Always specify width and height attributes for images and videos
• Use CSS aspect-ratio property for responsive images
• Reserve space for dynamically loaded content

Dynamically injected content:

• Reserve space for ads and embeds
• Avoid inserting content above existing content
• Use transform animations instead of changing layout properties

Web fonts causing FOIT or FOUT:

• Use font-display: swap for custom fonts
• Preload important font files
• Match fallback font metrics to custom fonts

Measuring Core Web Vitals

Accurate measurement requires both field data from real users and lab data for debugging and optimisation. Understanding the differences between these measurement approaches helps prioritise improvements effectively.

Field Data vs Lab Data

Field data represents real user experiences and should be the primary focus for Core Web Vitals optimisation:

• Google Search Console provides Core Web Vitals reports with field data
• Chrome UX Report offers historical performance data
• Real User Monitoring (RUM) tools provide detailed insights
• PageSpeed Insights combines both field and lab data

Lab data helps identify specific issues and test optimisations:

• Lighthouse provides detailed performance audits
• WebPageTest offers comprehensive testing options
• Chrome DevTools enables real-time debugging
• GTmetrix combines multiple testing tools

Tools for Core Web Vitals Analysis

Data from HTTP Archive shows that websites using multiple measurement tools achieve better Core Web Vitals scores than those relying on single tools.

Essential tools for Core Web Vitals monitoring include:

Implementation Strategies

Successful Core Web Vitals improvement requires a systematic approach that prioritises high-impact changes based on real user data. The most effective strategies focus on addressing the root causes rather than symptomatic fixes.

Prioritising Improvements

Start with pages that receive significant traffic and currently fail Core Web Vitals thresholds. Google's page experience documentation suggests focusing on:

• High-traffic landing pages and conversion paths
• Pages with the worst Core Web Vitals scores
• Template-level improvements that affect multiple pages
• Mobile performance, as mobile-first indexing prioritises mobile experience

Technical Implementation Approach

Phase 1: Quick wins and low-hanging fruit

• Optimise images with proper sizing and modern formats
• Implement basic caching strategies
• Remove or defer non-critical third-party scripts
• Add missing width and height attributes to images

Phase 2: Structural improvements

• Implement advanced caching and CDN strategies
• Optimise server response times and database queries
• Refactor JavaScript to reduce main thread blocking
• Implement resource prioritisation and preloading

Phase 3: Advanced optimisations

• Implement service workers for advanced caching
• Use advanced image optimisation techniques
• Implement sophisticated JavaScript optimisation strategies
• Deploy performance monitoring and alerting systems

FAQ

Do Core Web Vitals directly affect search rankings?

Yes, Core Web Vitals are confirmed ranking factors as part of Google's page experience signals. However, Google has stated that content relevance remains the primary ranking factor, and good page experience won't overcome poor content quality. The impact is most noticeable when competing pages have similar content quality and relevance.

Should I focus on mobile or desktop Core Web Vitals first?

Prioritise mobile Core Web Vitals, as Google uses mobile-first indexing for most websites. Mobile devices typically have more constrained processing power and network conditions, making performance optimisation more challenging but also more impactful for user experience. Desktop improvements often benefit from mobile optimisations as well.

How long does it take to see improvements in Core Web Vitals scores?

Google's Core Web Vitals data typically updates every 28 days, reflecting the previous month's user experience data. After implementing improvements, you'll need to wait for this data refresh cycle to see updated scores in Google Search Console and other Google tools. However, you can monitor improvements immediately using lab tools and real user monitoring.

Can third-party scripts significantly impact Core Web Vitals?

Yes, third-party scripts are often the primary cause of poor Core Web Vitals scores. Research from HTTP Archive's Web Almanac shows that pages with multiple third-party scripts typically have worse performance scores. Common culprits include advertising networks, analytics tools, chat widgets, and social media embeds. Regular auditing and optimisation of third-party scripts is essential for maintaining good Core Web Vitals scores.

Related Reading

For more insights into technical SEO and website performance optimisation, explore these related articles:

• Why Technical SEO Matters
• Technical SEO: Complete Guide
• Does Technical SEO Require Coding?
• What Redirects Are SEO Friendly?
• Why Does My Website Have a Redirect Loop?