Core Web Vitals Audit: The Complete Checklist Using PageSpeed API and CrUX Data
A poorly run Core Web Vitals audit often amounts to firing off PageSpeed Insights once, noting the score, and moving on. A rigorous audit systematically cross-references two different data sources - lab and field - and follows a checklist metric by metric instead of a single overall score that hides the real causes.
Lab Data vs. Field Data: The Distinction That Changes Everything
Lab data (generated by PageSpeed Insights, Lighthouse) simulates your page loading in a controlled environment, at one specific moment. It’s reproducible and great for debugging a precise technical cause, but it represents only one loading scenario out of the full diversity of network and hardware conditions your real visitors experience.
Field data (Chrome UX Report, or CrUX) aggregates metrics actually measured from real Chrome users who visited your site over the past 28 days. This is the data Google actually uses as a ranking signal - not the lab score.
A complete audit requires both: the field to know whether a problem actually exists for your visitors, the lab to understand precisely why and fix it.
The Complete Checklist, Metric by Metric
LCP (Largest Contentful Paint)
- Check the threshold: under 2.5 seconds is “Good”.
- Identify the exact LCP element (often a hero image or main text block) via Chrome DevTools’ Performance tab.
- Check whether that element is preceded by render-blocking resources (non-critical CSS, unpreloaded fonts).
- Confirm the LCP image isn’t accidentally set to
lazy loading- a lazy-loaded image by default delays its own render.
CLS (Cumulative Layout Shift)
- Check the threshold: under 0.1 is “Good”.
- Look for images and iframes missing explicit
width/heightdimensions, the most common cause of shift. - Check for web fonts without a proper
font-displaystrategy, which cause a layout change at load time. - Identify any content dynamically injected above existing content (cookie banners, ads) without a reserved space.
INP (Interaction to Next Paint)
- Check the threshold: under 200ms is “Good”.
- Confirm this data actually comes from the field (CrUX) - INP cannot be reliably simulated in a lab.
- If available, review PageSpeed’s Max Potential FID as a complementary lab indicator, knowing it isn’t exactly equivalent to real INP.
- Look for JavaScript Long Tasks as the likely cause - see our complete guide to optimizing INP for the full diagnostic process.
TTFB (Time to First Byte)
- Check the threshold: under 0.8 seconds is generally considered good.
- Measure TTFB via a direct request (curl or an equivalent tool), not solely through PageSpeed, which can be subject to quotas or additional latency.
- If TTFB is high, the cause is almost always server-side - hosting, missing caching, slow database queries.
The Most Common Mistake: Auditing a Single Page
The homepage is often a site’s most polished page - and therefore its least representative. A rigorous audit covers multiple page types: homepage, a category or service page, a product or article page, and a page with a form. The costliest regressions are almost always concentrated on the templates that are least reviewed internally, not the homepage.
Run Your Own Audit
Our free audit tool runs this exact checklist directly against your live site - PageSpeed data, real TTFB measured via a direct request, and crawlability verification - with no setup or signup.
Run a free Core Web Vitals audit →
Need a Fix, Not Just a Diagnosis?
Cross-referencing field and lab data to identify the exact technical cause of a regression, page by page, requires dedicated expertise. That’s the core of our technical SEO services.
Published by the Runkexpert Engineering Team. Last updated July 15, 2026.