Core Web Vitals Audit: Measure and Improve LCP, INP, and CLS

What Are Core Web Vitals

Core Web Vitals are three page-experience metrics: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability. Google recommends good values at the 75th percentile of page loads.

Use Chrome User Experience Report field data to assess real-user performance and lab tools to diagnose a particular load. Google says good Core Web Vitals support page experience, while relevant content can still rank when page experience is weaker.

LCP: Largest Contentful Paint

LCP measures how long it takes for the largest visible element to render on screen. This is usually a hero image, a large text block, or a video poster frame. It represents when the user perceives the page as "loaded."

Thresholds:

• Good: 2.5 seconds or less
• Needs Improvement: over 2.5 seconds and up to 4.0 seconds
• Poor: Over 4.0 seconds

Common causes of poor LCP:

• Slow server response (TTFB): TTFB consumes part of the LCP timeline, but the remaining subparts determine the final value. Measure redirects, connection, backend and cache state before choosing a remedy.
• Unoptimised hero images: A 3MB JPEG hero image will tank LCP. Convert to WebP/AVIF, serve responsive sizes with srcset, and preload the hero image.
• Render-blocking resources: Large CSS files or synchronous JavaScript in the head delay rendering. Inline critical CSS and defer non-critical resources.
• Client-side rendering: If your LCP element is rendered by JavaScript (React, Vue), the browser has to download, parse, and execute JS before showing content. Use server-side rendering or static generation.
• Web font loading: When the LCP element is text, inspect font discovery, transfer, display policy and fallback metrics. Preload only a font required early on that page; test font-display and fallback choices for both paint timing and layout shift.

How to fix LCP:

1. Identify your LCP element using Chrome DevTools Performance panel or PageSpeed Insights
2. If it is an image, inspect discovery, priority, format, intrinsic size and responsive candidate; preload or raise priority only when the trace supports it
3. If it is text, inspect the font request and fallback; test preload and display policy rather than applying them universally
4. Measure TTFB by location and cache state then address the slow layer
5. Remove or defer render-blocking CSS and JavaScript

INP: Interaction to Next Paint

INP replaced First Input Delay (FID) in March 2024. It measures the responsiveness of your page to user interactions — clicks, taps, and keyboard input. Unlike FID which only measured the first interaction, INP measures all interactions throughout the page lifecycle and reports the worst one (with some statistical smoothing).

Thresholds:

• Good: 200 milliseconds or less
• Needs Improvement: over 200 milliseconds and up to 500 milliseconds
• Poor: Over 500 milliseconds

Common causes of poor INP:

• Long JavaScript tasks: Any JS task over 50ms blocks the main thread and delays response to user input. Break long tasks into smaller chunks using requestIdleCallback or setTimeout.
• Third-party scripts: Analytics, chat widgets, ad scripts, and social embeds often run heavy JavaScript. Audit your third-party scripts and remove or defer non-essential ones.
• Expensive DOM updates: Use a performance trace to find style recalculation, layout and rendering work during the slow interaction.
• Expensive event handlers: Click handlers that trigger complex calculations, large DOM updates, or synchronous API calls block responsiveness.

How to fix INP:

1. Use Chrome DevTools Performance panel to identify long tasks during interactions
2. Break JavaScript into smaller chunks using yield-to-main patterns
3. Defer non-critical third-party scripts with async or defer attributes
4. Use web workers for CPU-intensive operations
5. Reduce DOM size and complexity

CLS: Cumulative Layout Shift

CLS measures visual stability — how much the page layout shifts unexpectedly while content loads. Nothing frustrates users more than clicking a button just as the page shifts and hitting something else instead.

Thresholds:

• Good: 0.1 or less
• Needs Improvement: over 0.1 and up to 0.25
• Poor: Over 0.25

Common causes of poor CLS:

• Images without dimensions: If width and height aren't set on img elements, the browser can't reserve space before the image loads.
• Ads and embeds without reserved space: Ad slots that inject content after page load push everything below them down the page.
• Web fonts causing FOIT/FOUT: When a web font loads and replaces a fallback font with different metrics, text reflows and causes shifts.
• Dynamically injected content: Banners, cookie notices, or notification bars that push content down after initial render.

How to fix CLS:

1. Add explicit width and height attributes to all images and video elements
2. Reserve space for ads and embeds using min-height or aspect-ratio CSS
3. Use font-display: optional or size-adjust to minimise font swap shifts
4. Reserve space for late content and avoid unexpected insertion above existing content; user-initiated changes are excluded from CLS only within the metric's interaction window
5. Use CSS contain: layout on dynamic content areas

How to Measure Core Web Vitals

• Google Search Console: The Core Web Vitals report groups similar URLs using CrUX field data. Use it to find site-wide patterns; it does not isolate ranking impact.
• PageSpeed Insights: Shows Lighthouse lab data and, when CrUX has sufficient eligible observations, URL-level or origin-level field data. Check the scope label before interpreting it.
• Chrome DevTools: Performance panel shows detailed timing data including LCP, CLS, and long tasks. Essential for debugging specific issues.
• Chrome DevTools live metrics: The Performance panel's live metrics view replaces the retired Web Vitals extension and can capture local interactions for diagnosis.
• CrUX Dashboard: Google's free Looker Studio dashboard showing CWV trends over time for your domain.

Field Data vs Lab Data

This distinction is critical and often misunderstood:

Field data from CrUX is collected from eligible Chrome users. It reflects real devices, networks and behaviour over a rolling 28-day period. Low-traffic URLs may show origin-level data or no data; Google does not publish a fixed visit threshold.

Lab data (Lighthouse, PageSpeed Insights lab section) is simulated on a controlled device with throttled CPU and network. It's reproducible and useful for debugging, but it doesn't directly affect rankings. Lab scores can differ significantly from field data.

If your lab scores are great but field data fails, the problem is likely that real users on slow devices or poor connections have a worse experience than the lab simulation predicts. Focus on optimising for the 75th percentile of real users, not just lab conditions.

How CWV Affects Rankings

Core Web Vitals contribute to the page-experience signals that Google's core ranking systems seek to reward. Google does not describe CWV as a fixed tiebreaker or publish a weighting. Interpret changes with search relevance and other signals in mind.

• Google does not publish a rule that lets an auditor predict a ranking change from a metric change
• Top Stories eligibility does not require a Core Web Vitals pass, although page experience can help users
• A failing metric identifies a user-experience problem; do not claim a traffic or ranking lift without measuring it
• Google evaluates CWV at the page level, but groups pages by similar type (product pages, blog posts, etc.) for reporting

Action Plan

1. Check GSC first: Open the Core Web Vitals report to see which URLs fail and which metric is the problem
2. Run PageSpeed Insights on failing URLs: Look at the field data section first, then use lab data diagnostics to identify specific issues
3. Prioritise observed harm: Start with the failing metric, affected page group and user task that carries the greatest impact, then trace its subparts.
4. Make a scoped change: Tie each image, layout or interaction change to the evidence and check for regressions in the other metrics.
5. Verify locally and in RUM: Repeat the same lab flow and monitor available real-user measurements after release.
6. Interpret the CrUX window: CrUX reports a rolling 28-day period, so monitor incremental movement while recognising that a full post-release window takes 28 days.

Use Google's current Core Web Vitals documentation and the web.dev guide to metric thresholds and the 75th percentile when interpreting results. The professional audit service can scope performance review with the wider site.