A Core Web Vitals SEO audit helps you identify which performance problems affect real visitors, connect each issue to the right technical owner, and prioritize fixes that can be verified after release. This guide covers the current reference thresholds for LCP, INP, and CLS, explains field versus lab data, and provides a recurring monitoring checklist for templates, scripts, deployments, and URL groups.
Overview
Core Web Vitals are user-focused performance measurements used to evaluate loading, responsiveness, and visual stability. They are useful in a technical SEO audit because slow or unstable pages can create friction for search visitors, reduce the usefulness of landing pages, and signal regressions after code or template changes. They should not be treated as a substitute for crawlability, indexation, content quality, or search intent analysis. Instead, use them as one workstream within a broader technical SEO checklist.
The three metrics to track are:
- Largest Contentful Paint (LCP): how long it takes for the largest visible content element to render.
- Interaction to Next Paint (INP): how quickly a page responds visually after a user interaction.
- Cumulative Layout Shift (CLS): how much visible content moves unexpectedly during a page visit.
Use the following reference thresholds when reviewing performance. The values describe the boundary between good, needs improvement, and poor results. Measurement methods and official terminology can change, so confirm the definitions during scheduled reviews.
| Metric | Good | Needs improvement | What it indicates |
|---|---|---|---|
| LCP | 2.5 seconds or less | More than 2.5 to 4 seconds | Loading speed of the main visible content |
| INP | 200 milliseconds or less | More than 200 to 500 milliseconds | Responsiveness after clicks, taps, or keyboard input |
| CLS | 0.1 or less | More than 0.1 to 0.25 | Unexpected movement of visible page elements |
For SEO reporting, record whether a URL group passes each metric rather than relying only on a site-wide average. A site can appear healthy overall while a product template, checkout flow, article layout, or regional version experiences a meaningful regression.
What to track
Field data and lab data
Field data reflects visits from real users and devices. It is useful for understanding how performance varies by connection, hardware, geography, browser, and page type. Use it to assess the experience visitors are actually receiving and to identify affected URL groups.
Lab data comes from a controlled test environment. It is useful for debugging because it can expose render-blocking resources, oversized images, long JavaScript tasks, unused code, and layout changes under repeatable conditions. Lab results will not represent every visitor, so use them to diagnose likely causes rather than to replace field measurements.
Track both sources with the date, test location or device profile, URL, template, release identifier, and metric value. This context makes it easier to distinguish a genuine regression from normal variation.
Diagnostics and likely owners
| Signal | Common causes to investigate | Likely owner |
|---|---|---|
| LCP is slow | Large hero images, slow server response, render-blocking CSS or JavaScript, delayed font or content requests | Frontend and platform developers |
| INP is high | Long JavaScript tasks, expensive event handlers, excessive third-party scripts, repeated rendering work | Frontend developers and application owners |
| CLS is high | Images or embeds without reserved dimensions, injected banners, late-loading fonts, dynamically inserted content | Frontend developers, design systems, and content operations |
Useful diagnostic inputs include Google Search Console's Core Web Vitals reporting, browser performance tooling, Lighthouse-style lab tests, real-user monitoring, server logs, and deployment records. Search Console can help group similar URLs, while browser tools can help isolate the request, script, or layout event behind a result. Keep the diagnostic source beside the measurement in your audit record.
URL groups and business context
Segment the audit by templates and user journeys: home pages, category pages, articles, documentation, product pages, account areas, and campaign landing pages. Also record whether a page is a major organic entry point, a conversion step, or a frequently reused template. A moderate issue on a high-traffic template may deserve attention before a severe issue on a rarely visited page, provided the latter is not blocking a critical journey.
Cadence and checkpoints
A recurring Core Web Vitals checklist should combine release testing with routine reporting. The following cadence is practical for most teams:
Before a release
- Record a baseline for representative URLs in each affected template.
- Identify changes to images, fonts, CSS, JavaScript, third-party tags, server configuration, and content modules.
- Test the most important pages in a controlled lab environment.
- Check that responsive layouts reserve space for images, ads, embeds, alerts, and other dynamic elements.
- Define an owner and acceptance criteria for each known performance risk.
After a release
- Repeat the same lab tests under comparable conditions.
- Compare LCP, INP, and CLS with the pre-release baseline rather than comparing unrelated test setups.
- Review browser console errors, network waterfalls, long tasks, and layout-shift records.
- Monitor field data as it accumulates and annotate the date of the deployment.
- Check affected URL groups, not just the individual page used for testing.
Monthly and quarterly reviews
During a monthly performance review, check unresolved issues, newly affected templates, changes in traffic mix, and regressions associated with recent script or content releases. During a quarterly technical SEO review, refresh the metric definitions, thresholds, browser tooling, Search Console terminology, and measurement documentation. Reconfirm that dashboards still use the intended URL groups and that retired templates are not distorting the trend.
How to interpret changes
Do not prioritize a fix solely because one test produced a poor score. First establish whether the change is repeatable, whether it affects field data, and whether it is concentrated in a template or release. A useful triage record includes the metric, affected URL group, change date, severity, likely cause, owner, traffic or journey importance, and verification method.
Prioritize issues using four criteria:
- Reach: how many important URLs or visitors are affected?
- Severity: is the metric in the poor range, or has it moved from good toward needs improvement?
- Confidence: do field and lab evidence point to the same problem?
- Effort and risk: can the change be made safely, and could it affect functionality or crawlability?
For LCP, start by separating server response delay from resource and rendering delay. For INP, inspect the interaction that produces the slow response and look for long main-thread tasks rather than simply reducing file size. For CLS, identify the exact element that moved and reserve its space before content arrives. These distinctions help developers choose targeted fixes instead of applying broad optimizations with uncertain results.
When a score improves in the lab but not in field data, check whether the tested URL, device, connection, browser mix, or release differs from the real audience. When field data worsens without an obvious deployment, investigate traffic changes, third-party services, regional infrastructure, and template-level content changes.
When to revisit
Revisit this audit after every substantial deployment, template change, navigation redesign, analytics or advertising script release, image-system change, hosting migration, or addition of dynamic content. These events can alter loading order, JavaScript execution, or layout stability even when the visible design appears unchanged.
At minimum, schedule a monthly review of affected URL groups and a quarterly review of definitions, thresholds, tools, and reporting views. Keep an open regression queue with the original baseline, latest result, owner, next action, and verification date. Close an issue only after the fix has been tested in the relevant environment and the corresponding field trend has had time to update.
For the next review, export the latest Core Web Vitals data, compare it with the prior period, annotate releases and major content changes, and select the three highest-priority issues using reach, severity, confidence, and effort. This creates a repeatable website performance audit rather than a one-time score check. If the investigation reveals broader crawl or indexation concerns, connect it with your crawl budget optimization checklist or review SEO log file analysis to keep performance work aligned with the rest of your technical SEO program.
