LCP, INP, and CLS explained — what Google really measures
Core Web Vitals are not Lighthouse scores. They are three metrics from real user data (CrUX) that Google uses as ranking and quality signals. This page explains for each metric what goes wrong, how to measure it, and what actually makes a difference on WordPress sites.
- ✓ LCP, INP & CLS thresholds
- ✓ Field data vs lab
- ✓ Search Console CWV report
- ✓ WordPress-specific fixes
More on website performance
Related performance guides
What are Core Web Vitals?
Core Web Vitals are three performance metrics defined by Google based on real user data: LCP (Largest Element Load Rate), INP (Response to Interaction), and CLS (Visual Stability). They appear in Search Console and PageSpeed Insights as field data — not as a Lighthouse Lab Score.
For the full performance context (TTFB, caching, WordPress bottlenecks, conversion impact), see our guide. website speedThis page focuses on the three CWV metrics themselves — thresholds, causes, and fixes.
All performance guides are located under the collection. website performance — hub → subhub → guide.
The three metrics and their Google thresholds.
75th percentile field data determines green/orange/red in Search Console.
Good: ≤ 2.5s · Moderate: 2.5 – 4.0s · Poor: > 4.0s
Good: ≤ 200ms · Moderate: 200 – 500ms · Poor: > 500ms
Good: ≤ 0.1 · Moderate: 0.1 – 0.25 · Poor: > 0.25
Largest Contentful Paint
Loading time of the largest visible element (hero image, heading block, video poster).
Typical on WordPress: Slow TTFB, uncompressed hero, background image via CSS, late font swap, render blocking CSS.
Direction fixes: Server/page cache, <img> hero with fetchpriority, WebP/AVIF, preload LCP resource, critical CSS.
Interaction to Next Paint
Responsiveness after interaction (click, tap, key) until the next paint — replacement for FID.
Typical on WordPress: Heavy JS bundles, page builder scripts, WooCommerce fragments, third-party chat/heatmap long tasks.
Direction fixes: Defer non-critical JS, code splitting, tag audit, disable cart fragments outside shop, INP debugging in DevTools.
Cumulative Layout Shift
Visual stability — how much content shifts during loading (layout shifts).
Typical on WordPress: Images without width/height, late web fonts, dynamically loaded banners/cookie bars, ads.
Direction fixes: Explicit dimensions, font-display: optional/swap with fallback metrics, reserve space for embeds.
CrUX field data vs Lighthouse.
Trust field data for SEO and business; use the lab for debugging.
| Aspect | Field data (CrUX) | Lab (Lighthouse) |
|---|---|---|
| Data source | CrUX — 28 days aggregated Chrome users (75th percentile) | Lighthouse / WebPageTest — simulated throttling, one run |
| Google ranking | Official CWV signal in Search Console & rankings | Diagnostic — no direct ranking signal |
| Device | Real devices & visitor networks | Simulated mobile/desktop profile |
| When trust | Business decisions, CWV report, SEO | Debug waterfall, reproduce fixes locally |
CWV overlap with technical SEO — crawl, indexation, and mobile usability are related to performance.
FAQ about Core Web Vitals
Three metrics from real Chrome user data (CrUX): LCP (largest element load time), INP (response after interaction), and CLS (layout stability). Google displays them in Search Console and uses field data as a quality and ranking signal — independent of a Lighthouse lab score.
LCP ≤ 2.5 seconds at the 75th percentile field data is considered “good”. Between 2.5 and 4 seconds is “moderate”, above 4 seconds “poor”. On WordPress, LCP is often a slow hero image, high TTFB, or render-blocking CSS — see also website speed.
Interaction to Next Paint measures how quickly the page responds to all interactions (not just the first one). FID only looked at the first input. INP ≤ 200ms is shown in green on field data. Slow INP is often caused by heavy JavaScript, page builders, or third-party scripts.
Reserve space for images and embeds (width/height), prevent late font swaps without fallback metrics, and do not load banners over existing content. Cookie bars and ads that push content are a common source of CLS on SMB sites.
In Google Search Console under “Core Web Vitals” (field data per URL group) and in PageSpeed Insights under “Discover what your real users are experiencing”. Lighthouse in DevTools is lab data — useful for debugging, not for basing rankings on.
Lighthouse simulates a single visit with throttling. Field data aggregates 28 days of real users. You can score Lighthouse 95 while CrUX shows “Needs improvement” — trust field data for SEO decisions. More context on our performance hub.
Yes, as a page-level signal within the broader ranking mix. Slow CWV correlates with higher bounce and lower conversion. Technical SEO (crawl, indexation, structured data) and performance overlap — see technical SEO.
Yes. We start with CrUX/Search Console and a waterfall per metric (LCP, INP, CLS). Then targeted fixes on server, cache, assets, or scripts — no blind package. For implementation on WordPress: WordPress website or request a quote.
CWV red in Search Console? We measure field data first.
No score-hunting for Lighthouse alone. We link LCP, INP, and CLS to concrete bottlenecks on your WordPress site — server, assets, scripts, or builder overhead.