How to Run a Core Web Vitals Audit: A Step-by-Step Workflow

You know your site has a performance problem. PageSpeed Insights shows red. Search Console flags URLs as "poor." Your team wants to fix it, but nobody is sure where to start — every audit tool produces a different score, every guide suggests a different fix, and the list of potential improvements looks overwhelming. A structured audit workflow cuts through the noise. This guide walks you step by step through running a Core Web Vitals audit that produces an actionable, prioritised fix list.

Why Audit Structure Matters

Running Lighthouse on your homepage and listing its suggestions is not an audit. It is a starting point, and a limited one: it measures a single synthetic page load under controlled conditions, which often diverges significantly from what real users experience.

A proper Core Web Vitals audit:

1. Starts with field data from real users
2. Uses lab tools to diagnose the causes of field failures
3. Tests the pages that matter most, not just the homepage
4. Produces a prioritised list of fixes with clear ownership

Following this structure means you spend engineering time where it has the most impact, rather than optimising lab scores on pages that represent a small fraction of your traffic.

Step 1: Establish Your Field Data Baseline

Before touching any tooling, collect your current field performance from real users.

Google Search Console: Navigate to Experience > Core Web Vitals. This shows your URLs grouped into Good, Needs Improvement, and Poor for both mobile and desktop. The groupings are based on CrUX (Chrome User Experience Report) data — real Chrome users visiting your pages over the past 28 days.

Note: Search Console groups similar URLs into URL groups. The LCP issue on your product detail pages is the same root cause across hundreds of URLs, so it shows as one issue affecting a large number of pages.

PageSpeed Insights: Enter specific page URLs at pagespeed.web.dev. The "Discover what your real users are experiencing" section shows field data for that specific URL if there is enough traffic. This is the metric Google uses for ranking.

Take a screenshot or record the current state. This is your baseline. Every fix you make should be measured against it.

Step 2: Identify Your Highest-Traffic Failing Pages

Search Console shows which URLs are failing. Cross-reference with your analytics to find the highest-traffic pages among the failing set. These are your audit targets.

For a typical content or e-commerce site:

• Homepage (high traffic but often disproportionately optimised)
• Category or listing pages (high traffic, often image-heavy)
• Product or article pages (medium-to-high traffic, often the actual problem)
• Landing pages used for paid acquisition (high business value, often poorly optimised)

Prioritise by: traffic volume x severity of failure x business value. A "poor" LCP on your highest-traffic product page is worth more engineering time than a "needs improvement" CLS on a low-traffic blog post.

Step 3: Diagnose LCP with Lab Tools

For each audit target, run a WebPageTest test (webpagetest.org). Use:

• Browser: Chrome
• Connection: 4G (for mobile parity with field data)
• Location: closest to your largest user geography

Look at the results:

Identify the LCP element: WebPageTest shows you exactly which element is the LCP and at what timestamp it rendered.

Examine the LCP waterfall phases: WebPageTest breaks LCP into TTFB, resource load delay, resource load duration, and element render delay. The longest phase is your primary bottleneck.

• Long TTFB: server or CDN problem — caching, geography, server processing time
• Long load delay: the LCP resource is discovered late — add a preload, check for render-blocking resources above the LCP
• Long load duration: the resource itself is too large — format conversion, resize, CDN delivery
• Long render delay: something is preventing the element from painting — CSS blocking, JavaScript delaying render

Check mobile specifically: Google ranks based on mobile field data. Run your WebPageTest audit with a real mobile connection profile and compare the LCP breakdown to desktop.

Step 4: Diagnose CLS

In Chrome DevTools, open the Performance panel and record a page load. Look for Layout Shift events in the Experience row (marked as purple triangles).

Click each layout shift event to see:

• Which element shifted
• What caused the shift (the "Moved From" and "Moved To" regions)
• The impact fraction and distance fraction

Common causes you will find:

• Images without width and height attributes (element dimensions unknown until download)
• Fonts swapping in after a fallback renders
• Dynamically injected content (ads, banners, cookie notices) pushing existing content

Also test the page after the initial load — interact with it, scroll, trigger any dynamic content. CLS accumulates across the page's lifetime, not just during load.

For field CLS data, CrUX and Search Console show the 75th percentile CLS across all real visits. Your lab test may not reproduce all shifts if they require specific interactions or timing.

Step 5: Diagnose INP

INP failures are harder to diagnose in the lab because they depend on real user interactions across the full page session.

For lab diagnosis:

1. Open Chrome DevTools Performance panel
2. Record a trace while performing your most common interactions: clicking navigation links, submitting forms, interacting with filters or search, expanding accordions
3. Look for long tasks (marked with red triangles) in the Main thread section around your interactions
4. Check the Interactions lane for each interaction's total INP breakdown

For field diagnosis:

• If you have a RUM (Real User Monitoring) tool, look for interactions with high input delay
• The web-vitals JavaScript library can report INP with onINP(), including the interaction's target element and breakdown

Common INP causes in JavaScript-heavy applications:

• Large React re-renders triggered by interaction
• Third-party scripts running long tasks on the main thread
• Unoptimised event handlers doing synchronous heavy computation

Step 6: Prioritise Fixes by Impact

After diagnosing all three metrics across your audit targets, group findings by:

Infrastructure changes (CDN, caching, TTFB): high impact, affects all pages, typically one-time changes. Fix first.

Asset delivery (image format, size, priority, preloading): high impact on LCP, one-time change per image type. Fix second.

HTML/CSS attributes (width/height on images, font-display, resource hints): high impact on CLS and LCP, typically one-line changes per element. Fix third.

JavaScript architecture (deferred scripts, long task breaking, INP fixes): medium-to-high impact, requires engineering time. Prioritise based on INP field data severity.

Third-party scripts: often high impact relative to effort (adding defer, changing load timing, removing unused scripts). Quick wins here.

Step 7: Measure After Each Change

Core Web Vitals field data updates on a rolling 28-day window. Changes you ship today will be visible in field data in about four weeks.

For faster feedback:

• WebPageTest and Lighthouse give immediate lab feedback on lab-measurable fixes (image size, TTFB, render-blocking resources)
• Set up Lighthouse CI in your deployment pipeline to catch regressions as you ship

Track your baseline field scores in a spreadsheet alongside the dates of each fix. This gives you a clear attribution between changes and score improvements over time.

The Audit Mindset

The goal of a Core Web Vitals audit is not to pass a test — it is to make your product faster for the people using it. Every LCP improvement means users see your content sooner. Every CLS fix means users stop accidentally clicking the wrong things. Every INP improvement means users get instant feedback from their interactions.

Good scores follow from good performance. Audit with that outcome in mind.

If you want a thorough Core Web Vitals audit with a concrete, prioritised fix plan for your product, the Clixo team delivers performance audits alongside the engineering capacity to execute the fixes.