Core Web Vitals Audit: A Complete Guide to LCP, INP and CLS
Core Web Vitals are a set of user-centered metrics used to evaluate important aspects of page experience: loading, responsiveness and visual stability. A serious audit should not stop at a single Lighthouse score. It should combine real-user field data, controlled lab testing and technical diagnostics so that you can identify the cause of a problem rather than simply observe a number.
What a Core Web Vitals audit should answer
A useful audit answers four questions: Are real users experiencing a problem? Which pages or templates are affected? What technical component is creating the problem? What change should be implemented and how will it be verified?
1. LCP — Largest Contentful Paint
LCP measures when the largest relevant content element in the viewport becomes rendered. Common LCP elements include a hero image, large heading, poster image or prominent text block. A good target is 2.5 seconds or less at the 75th percentile. When LCP is slow, investigate server response time, resource discovery, image delivery, render-blocking CSS and client-side rendering.
Practical LCP checklist
- Improve HTML document response time and backend processing.
- Preload the actual LCP image when appropriate and avoid lazy-loading the LCP resource.
- Serve responsive images in modern formats such as WebP or AVIF when supported by your delivery pipeline.
- Reduce render-blocking CSS and unnecessary third-party resources.
- Make critical content discoverable in the initial HTML instead of waiting for JavaScript.
2. INP — Interaction to Next Paint
INP measures how responsive a page is to user interactions throughout the visit. A good target is 200 milliseconds or less at the 75th percentile. High INP is often related to long JavaScript tasks, excessive event-handler work, expensive rendering or too much main-thread activity.
How to improve INP
- Break long JavaScript tasks into smaller units.
- Remove unnecessary JavaScript and reduce the amount of work executed after interaction.
- Defer non-critical scripts and third-party code.
- Keep event handlers lightweight and avoid unnecessary synchronous layout work.
- Profile slow interactions in Chrome DevTools Performance.
3. CLS — Cumulative Layout Shift
CLS measures unexpected visual movement. A good target is 0.1 or less. Layout shifts commonly occur when images or embeds have no reserved dimensions, fonts change layout after rendering, or dynamic components insert content above existing content.
CLS checklist
- Declare width and height or an appropriate aspect ratio for images and video.
- Reserve space for ads, embeds and dynamic modules.
- Avoid inserting content above already-rendered content unless it is triggered by user interaction.
- Manage web fonts to reduce layout instability.
- Use browser tooling and field data to locate the actual shifting elements.
Field data vs. Lighthouse lab data
Field data describes what real users experienced over an eligible collection period, while lab data is a controlled test performed under simulated conditions. They answer different questions. Field data is valuable for measuring user experience at scale; lab testing is valuable for reproducing problems and diagnosing their causes.
| Metric | What it measures | Good target | Typical causes of poor results |
|---|---|---|---|
| LCP | Loading of the largest visible content | ≤ 2.5s | Slow server, late resource discovery, large images, render blocking |
| INP | Responsiveness to user interaction | ≤ 200ms | Long tasks, excessive JavaScript, expensive rendering |
| CLS | Unexpected visual movement | ≤ 0.1 | Unreserved media, injected content, font/layout changes |
A repeatable audit workflow
- Identify important page templates rather than testing only the homepage.
- Check available field data for the affected URLs or origin.
- Run mobile and desktop lab tests to reproduce the issue.
- Map the failing metric to concrete Lighthouse audits and browser traces.
- Prioritize changes by user impact, implementation cost and affected traffic.
- Deploy one logical group of fixes at a time and retest.
- Monitor field data after deployment instead of assuming a lab improvement equals a real-user improvement.
What not to do
Do not chase a perfect Lighthouse score at the expense of useful functionality. Do not treat a single test run as a permanent measurement, and do not assume that improving one lab metric automatically fixes field Core Web Vitals. Performance is a continuous engineering process.