Core Web Vitals cover three separate metrics, and each one fails for a different reason. This hub explains how to approach LCP, INP, and CLS on a WordPress site, and how to use field and lab data together rather than treating either one alone as proof of how visitors actually experience your pages.
What Core Web Vitals are
Core Web Vitals are a specific set of three page-experience metrics Google evaluates: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Each is assessed at the 75th percentile of real visits, separately for mobile and desktop, and a page is generally considered to pass the overall assessment only if all three individual metrics pass their “good” threshold. A page that passes two out of three still fails the overall assessment.
LCP, INP, and CLS, briefly
LCP measures how long the largest visible element takes to render and can be influenced by server response, resource discovery, image delivery, and render delay. INP measures responsiveness across a visitor’s session and can be affected by input delay, event-handler work, and the time required to present the next frame. CLS measures unexpected visual movement, often involving media, ads, embeds, or late layout changes without reserved space. Each metric has different causes, so the first step is identifying which one is failing rather than applying a generic performance fix.
Field data versus lab data
Field data reflects eligible real visitors using real devices and networks, aggregated over time; lab data reflects a single simulated test under defined conditions. The two can disagree because they measure different populations and time windows. A synthetic run is not proof of real-user experience, but it can help reproduce and investigate a suspected problem. Field data is also not available for every low-traffic URL, so the absence of a report is not proof that the page performs well.
URL-level and origin-level data
Field data can be reported for a specific URL or, when a URL doesn’t have enough traffic for its own data, aggregated across an entire domain (origin-level). Origin-level data is a useful general signal but can mask a much slower, low-traffic template elsewhere on the same site, so it isn’t a substitute for URL-level data where available.
When field data is unavailable
A PageSpeed Insights report may show no URL-level field data, and sometimes no origin-level data, when the Chrome UX Report does not have enough eligible samples. In that case, use lab tests, browser traces, and your own monitoring to investigate, but label the conclusion correctly: it is a controlled diagnostic result, not a statement about the 75th-percentile experience of real visitors. Revisit field data later as traffic and eligibility change instead of manufacturing certainty from a single synthetic score.
Mobile and desktop differences
Core Web Vitals reports separate mobile and desktop data because device capabilities and network conditions differ. Mobile results may be more constrained on some sites, but priorities should follow the site’s actual audience and available field evidence rather than an assumption that one form factor is always worse. Mobile-first indexing concerns the mobile version of content used for indexing; it should not be treated as proof that every performance diagnosis must begin with the same device profile.
Recommended reading order
Begin with the guide for the metric that is actually failing: Largest Contentful Paint in WordPress for loading, Cumulative Layout Shift in WordPress for visual movement, or Interaction to Next Paint in WordPress for responsiveness. INP diagnosis normally includes manually testing important interactions such as navigation, forms, filters, and accordions rather than relying on page-load metrics alone.
Related categories
Many Core Web Vitals fixes trace back to hosting, caching, or front-end asset weight, covered in the WordPress Speed hub, and are best diagnosed using the tools covered in Tools & Experiments, particularly PageSpeed Insights for field and lab data together and Chrome DevTools for detailed, hands-on diagnosis of a specific metric.
A note on scope
This category currently includes three published guides, one for each Core Web Vitals metric. SitePulse Labs has not measured or published its own visitor dataset, and does not claim to operate a dedicated field-data collection panel; guidance in this category is based on official Google documentation (web.dev and Chrome for Developers) and general diagnostic technique using publicly available tools, not an in-house test lab.