What Core Web Vitals Measure and Why They Matter

Core Web Vitals are a set of specific metrics Google uses to evaluate the experience a visitor has when loading a webpage. They are part of the ranking algorithm used to determine where a page appears in search results. Pages that load quickly, respond to input promptly, and keep their layout stable tend to perform better in search than pages that shift, stutter, or take a long time to display content.

The three Core Web Vitals are Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). Google previously used First Input Delay (FID) as a metric but replaced it with INP in 2024. If you are still seeing FID referenced in older articles or tools, it is worth understanding that INP is the current measurement for interactivity.

Understanding what each metric actually measures gives you a clear path to identifying problems and fixing them. This guide covers each metric in detail, explains common causes of poor scores, and walks through practical improvements you can apply to your website.

Largest Contentful Paint (LCP)

LCP measures the time from when page navigation begins to when the largest visible content element renders on screen. This is usually a hero image, a large banner, a video poster frame, or a prominent heading. The browser considers whichever content element occupies the most space in the viewport at the time of rendering.

A good LCP score is 2.5 seconds or less. Scores between 2.5 and 4 seconds need improvement. Anything over 4 seconds is considered poor. These thresholds represent the range within which most users expect to see meaningful content appear.

Common causes of poor LCP

  • Slow server response time: The browser cannot display anything until it receives and parses the HTML from the server. If the server is slow to respond, everything downstream is delayed.
  • Render-blocking JavaScript and CSS: Scripts and stylesheets in the <head> section pause rendering while the browser downloads and processes them. The larger or more numerous these resources are, the longer the delay.
  • Unoptimised images: Large image files that are not compressed, not served in modern formats, or loaded without consideration for size add significant load time.
  • Client-side rendering: Single-page applications that build content in the browser after the initial HTML loads typically take longer to display the largest visible element compared to server-rendered pages.

How to fix LCP

Improving server response time is a good starting point. This might mean upgrading your hosting, enabling caching on the server side, or moving to infrastructure that responds more quickly to requests. Using a content delivery network to serve assets from edge locations closer to your users reduces the distance data needs to travel.

Eliminating render-blocking resources means moving non-critical CSS and JavaScript out of the critical rendering path. Scripts can be deferred or loaded asynchronously so they do not stop the page from displaying while they download.

For image optimisation, compress files before uploading, use modern formats like WebP, and ensure the most important image on a page loads eagerly rather than lazily. Preloading the largest contentful image tells the browser to fetch it as early as possible.

Interaction to Next Paint (INP)

INP replaced First Input Delay (FID) as a Core Web Vitals metric in March 2024. Where FID only measured the delay on the first interaction a user made with a page, INP evaluates the responsiveness of all interactions throughout the entire page lifecycle. This makes it a more comprehensive measure of how a page responds to user input.

INP records the latency of every click, tap, and keyboard input during a page visit. It then reports the longest interaction as the overall INP score. A good INP score is 200 milliseconds or less. Poor INP is over 500 milliseconds.

The main thread becomes blocked when the browser is executing JavaScript. Long tasks that run on the main thread prevent the browser from responding to user interactions until they finish. If a user clicks a button while a long task is running, the browser queues that input and responds only after the task completes. That delay is what INP captures.

Common causes of poor INP

  • Large JavaScript bundles executed on page load: Third-party scripts, analytics, advertising, and chat widgets often run heavy JavaScript early in the page lifecycle, blocking the main thread.
  • Long-running functions: Synchronous operations that process large amounts of data, manipulate the DOM extensively, or perform complex calculations without yielding can freeze the interface.
  • Unthrottled event handlers: Scroll or resize event handlers that trigger expensive operations on every event cause repeated long tasks that degrade responsiveness.

How to improve INP

Break up long JavaScript tasks using techniques like requestIdleCallback or setTimeout to yield the main thread periodically. This allows the browser to process user interactions between chunks of work rather than waiting for an entire task to complete.

// Break a long task into smaller chunks
function processItems(items) {
  let chunkSize = 10;
  let index = 0;

  function processChunk() {
    let chunk = items.slice(index, index + chunkSize);
    // process chunk
    index += chunkSize;
    if (index < items.length) {
      requestIdleCallback(processChunk);
    }
  }

  requestIdleCallback(processChunk);
}

Defer non-critical JavaScript so it does not compete with user interactions during the initial page load. Use the defer attribute on script tags to download scripts while parsing HTML but execute them only after parsing is complete. Use async with caution, as scripts that execute as soon as they download can interfere with the page layout if they manipulate the DOM.

<script defer src="analytics.js"></script>
<script async src="chat-widget.js"></script>

Throttle expensive event handlers. Instead of running a heavy operation on every scroll or resize event, use debouncing or a requestAnimationFrame loop to limit how often the operation runs.

Cumulative Layout Shift (CLS)

CLS measures how much the page layout shifts unexpectedly during loading. When elements move after they have already been rendered, users experience confusion and frustration. They may start reading a sentence only to have it jump to a different position, or they may click the wrong button because it shifted at the last moment.

A good CLS score is 0.1 or less. Scores between 0.1 and 0.25 need improvement. Anything above 0.25 is considered poor. Unlike LCP and INP which are time-based, CLS is dimensionless, calculated as a product of the distance an element moves and the proportion of the viewport affected.

Common causes of layout shift

  • Images and videos without dimensions: When an image loads without width and height attributes, the browser does not know how much space to reserve. Content below the image shifts down once the image loads.
  • Dynamically loaded content: Ads, embeds, iframes, and third-party widgets that load after the initial page render push surrounding content when they appear.
  • Web fonts causing text reflow: Fonts that load late can cause text to shift when the web font replaces the fallback system font. This is known as Flash of Unstyled Text (FOUT) or Flash of Invisible Text (FOIT).
  • Late-injected content: Cookie banners, consent notices, and chat widgets that appear after the initial render can push page content down.

How to fix CLS

Always set explicit width and height attributes on image and video elements. This allows the browser to calculate and reserve the correct space before the media loads.

<img src="photo.jpg" width="800" height="600" alt="Description" loading="eager">
<video src="clip.mp4" width="1920" height="1080" poster="poster.jpg"></video>

Reserve space for elements that load dynamically using the CSS aspect-ratio property. This is particularly useful for ad slots, video embeds, and iframes where the content size is unknown at render time.

.video-container {
  aspect-ratio: 16 / 9;
  width: 100%;
}

.ad-slot {
  aspect-ratio: 300 / 250;
  min-height: 250px;
}

For ads, set a fixed minimum height on the container so the slot reserves space even before the ad creative loads. This prevents the surrounding content from being pushed around when the ad arrives.

.ad-slot {
  min-height: 250px;
  width: 300px;
}

When loading web fonts, use font-display: swap in your @font-face declaration. This tells the browser to display text with the fallback font immediately and swap to the web font once it loads, rather than hiding text until the web font is ready.

@font-face {
  font-family: 'MyFont';
  src: url('/fonts/myfont.woff2') format('woff2');
  font-display: swap;
}

How to Measure Core Web Vitals

Google provides several tools for measuring Core Web Vitals, each with a different purpose. Using them together gives you both real-world data from actual visitors and controlled lab data you can use for debugging.

PageSpeed Insights combines field data from the Chrome User Experience Report (CrUX) with Lighthouse lab data. Field data shows how real users in the Chrome browser experience your site. Lab data is generated in a controlled environment and is consistent between runs, making it useful for testing changes. New websites with low traffic may not have CrUX field data available yet.

Chrome DevTools Lighthouse runs lab tests locally in your browser. The Performance tab shows a visual timeline with markers for LCP, INP, and CLS events. You can record a session, interact with the page, and then examine the timeline to see which operations caused delays or layout shifts.

# Use web.dev Measure to audit your site
# https://web.dev/measure

web.dev Measure is a straightforward tool that audits a URL against Core Web Vitals and provides a report with specific recommendations for improvement.

For ongoing monitoring, consider setting up the web-vitals JavaScript library on your site to capture real user measurements and send them to your analytics platform. This gives you continuous visibility into how your pages perform for real visitors over time, rather than relying on periodic tool checks.

Optimising Images for Better Core Web Vitals Scores

Images are the largest content element on most pages and therefore have the greatest impact on LCP. Even if your server is fast and your code is clean, unoptimised images can drag your scores down significantly.

Start by using modern image formats. WebP images are typically 25 to 35 percent smaller than equivalent JPEG files at the same visual quality. AVIF offers even smaller file sizes in many cases, though browser support is less widespread. Serve WebP with a fallback to JPEG for browsers that do not support the newer format.

<picture>
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" width="800" height="600" alt="Description">
</picture>

Preload your largest contentful image so the browser fetches it early in the page lifecycle rather than waiting for it to discover the image through the normal parsing process.

<link rel="preload" fetchpriority="high" as="image" href="hero.webp">

Enable server-side compression. In Nginx, gzip or Brotli compression reduces the size of text-based assets significantly. Make sure image formats are included in your compression configuration.

# In Nginx, enable gzip compression
gzip on;
gzip_types image/webp image/jpeg image/png text/css application/javascript;
gzip_min_length 1000;

If you are considering a CDN to improve delivery speed for UK visitors and beyond, a CDN setup with Cloudflare can serve assets from edge servers distributed across multiple locations, reducing latency for users who are not close to your origin server.

WordPress-Specific Considerations

WordPress sites face particular challenges with Core Web Vitals because of the way themes, plugins, and page builders interact. Many WordPress plugins inject JavaScript on every page load, even on pages where the plugin functionality is not needed. This increases the JavaScript payload and affects INP scores.

Audit your active plugins regularly. Deactivate and remove any plugin that you no longer use. For plugins that you need, check whether they have settings to defer their scripts or limit them to specific pages. Some performance-focused plugins can help you identify which scripts are loading and where.

Using a lightweight theme that does not load heavy assets by default makes a noticeable difference. Themes that come with large JavaScript frameworks and extensive CSS libraries can affect all three Core Web Vitals simultaneously.

For a more detailed walkthrough of WordPress-specific performance improvements, see the WordPress performance guide which covers caching, database optimisation, image handling, and plugin management in more depth.

Server and Hosting Factors

The speed of your origin server affects every metric. Shared hosting environments where multiple sites compete for the same server resources tend to have slower response times, which directly impacts LCP. Upgrading to a server with more predictable resource allocation, enabling server-side caching, and ensuring your hosting provider uses modern PHP versions and HTTP/2 or HTTP/3 can improve baseline performance.

For business websites that rely on consistent performance, considering how your hosting setup handles traffic spikes is worth doing before a performance issue becomes a ranking problem. A practical review of your current hosting and server configuration can identify bottlenecks that are not immediately obvious.

Why Core Web Vitals Matter for Your Website Ranking

Google has confirmed that Core Web Vitals are ranking signals used in its algorithm. Pages that meet the thresholds for good user experience tend to rank higher than pages with poor Core Web Vitals scores, all else being equal. This is particularly noticeable in competitive search results where multiple pages are competing for the same keywords.

Beyond ranking, Core Web Vitals reflect real user experience. A page that loads quickly, responds to input without delay, and does not shift around as it loads is simply more usable. Visitors are more likely to stay, read content, complete forms, or make a purchase on a site that performs well. Poor Core Web Vitals are often correlated with higher bounce rates and lower conversion rates.

Improving Core Web Vitals is not just about satisfying a ranking algorithm. It is about building a website that works well for the people who visit it.