A Core Web Vitals audit identifies which pages on your site are failing Google’s three user experience metrics — Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint — and surfaces the specific causes rather than a generic speed score. Passing Core Web Vitals is a confirmed ranking factor, and more importantly, the issues that cause failures tend to also cause users to leave before converting.

The Three Metrics and What Causes Them to Fail

Each metric has a distinct set of causes. Treating “site speed” as a single problem is why most speed improvement efforts underdeliver.

  • Largest Contentful Paint (LCP): Measures how long it takes for the largest visible element — usually a hero image or above-the-fold heading — to render. The most common causes are unoptimized images (wrong format, wrong size, not preloaded), render-blocking CSS or JavaScript, and slow server response times. LCP should be under 2.5 seconds. Most sites I review fail because the hero image is not preloaded in the document head and is being loaded via CSS background-image, which is not discoverable by the browser preloader.
  • Cumulative Layout Shift (CLS): Measures visual instability — elements jumping around as the page loads. The most common culprits are images without explicit width and height attributes, ads or embeds that inject content without reserved space, and web fonts causing text to reflow when they load. CLS should be under 0.1.
  • Interaction to Next Paint (INP): Replaced First Input Delay in March 2024 and measures responsiveness across all user interactions, not just the first one. Heavy JavaScript execution on the main thread is the primary cause. INP should be under 200ms.

Where to Pull the Data

There are two distinct data sets for Core Web Vitals, and conflating them is a common mistake:

  • Field data (real user data): Available in Google Search Console under Core Web Vitals, and via the Chrome User Experience Report (CrUX). This reflects what actual visitors on real devices and connections experience. This is what Google uses for ranking.
  • Lab data (simulated): Generated by PageSpeed Insights or Lighthouse. Useful for diagnosis because you can see a waterfall chart and specific recommendations, but it does not match field data exactly — especially on mobile where real-world conditions vary.

An audit should start with field data to identify which pages have failing URLs in Search Console, then use lab data on those specific pages to diagnose causes.

How to Run a Core Web Vitals Audit Step by Step

The process I follow starts in Google Search Console. Open the Core Web Vitals report, switch to the Mobile tab (mobile field data is what Google weights most heavily for ranking), and export the list of poor and needs-improvement URLs. That is your working list. Run each of those URLs through PageSpeed Insights — the tool will show you the CrUX field data for that specific URL alongside a Lighthouse lab analysis. The lab report identifies which elements triggered the LCP measurement, what caused CLS events, and which scripts are blocking the main thread for INP.

For a site-wide view, Screaming Frog with the PageSpeed Insights integration enabled will pull lab scores for every URL it crawls and flag the ones below threshold. This is useful for large sites where manually checking individual URLs is impractical. Log analysis can also surface slow pages — if your server response time for certain URL patterns is consistently above 600ms, those pages are likely failing LCP regardless of how well the front end is optimized.

Here is a minimal HTML pattern that gets LCP right for a hero image — preload hint in the <head>, explicit dimensions, no lazy loading on the element that will be the LCP candidate:

<!-- In <head> -->
<link rel='preload' as='image' href='/hero.webp' fetchpriority='high'>

<!-- Hero element in body -->
<img
  src='/hero.webp'
  width='1200'
  height='630'
  alt='Service description'
  fetchpriority='high'
>
<!-- Never add loading='lazy' to the LCP element -->

How to Prioritize Fixes

Not every failing page deserves the same attention. I prioritize based on three factors: search visibility (pages that rank and drive traffic matter more), conversion weight (your homepage and key service pages have disproportionate business impact), and fix complexity (some issues — like adding width and height to images — take 20 minutes; others, like refactoring third-party scripts, require significant development time). A realistic fix plan assigns effort estimates alongside each issue so you can sequence the work.

Common Fixes That Move the Needle

  • Convert hero images to WebP or AVIF and add a preload link hint in the document head for the LCP element.
  • Add explicit width and height attributes to all img tags so the browser reserves layout space before images load.
  • Defer or lazy-load non-critical JavaScript using the defer or async attributes.
  • Self-host Google Fonts or use font-display: swap to prevent layout shift from font loading.
  • Audit third-party scripts (chat widgets, analytics, ad pixels) and remove or delay any that are not essential — they are the most common source of INP failures.

What Passing Core Web Vitals Does Not Fix

A passing Core Web Vitals score is a floor, not a ceiling. I have seen sites achieve Good scores across all three metrics and still have ranking problems rooted in indexation errors, thin content, or weak internal linking. Core Web Vitals are a tiebreaker at the margin — they matter more when competing pages are otherwise equivalent. If your pages are not indexed, have canonicalization errors, or lack the depth that top-ranking pages have, fixing INP is not the highest-value use of your time. Run the CWV audit, but read it alongside the full technical picture.

Rendering and Core Web Vitals

A dimension of Core Web Vitals auditing that gets under-covered is the difference between what users see and what Googlebot renders. Googlebot uses a version of Chrome that lags behind the current release, and it renders pages under conditions that may not match what real users experience. Some JavaScript-heavy sites pass in the lab on a modern browser but produce higher LCP measurements in the field because older devices used by real visitors cannot execute the same JavaScript as fast. When field data and lab data diverge significantly, profiling the page in Chrome DevTools on a mid-range Android device under throttled conditions will surface causes that a desktop Lighthouse run misses. The Long Tasks panel is particularly useful for diagnosing INP — it shows which script executions are blocking the main thread beyond 50ms.

Core Web Vitals review is included in my website audit service as part of the technical SEO scope. If you want to understand the full technical picture beyond page speed, the technical SEO audit overview covers what else gets reviewed in the same engagement.