The three Core Web Vitals
LCP (Largest a headless CMS Paint): how fast the largest content is visible. Target: <2.5s.
INP (Interaction to Next Paint): how fast the page responds to clicks/typing. Target: <200ms. Replaced FID since March 2024.
CLS (Cumulative Layout Shift): how stable the page loads (no jumping content). Target: <0.1.
Each of the three measures something different: LCP is about loading, INP about interaction, CLS about visual stability. You can have a perfect LCP score and still fail on INP if your page has heavy JavaScript components. Always treat them as three separate diagnoses, not one average score.
Why do CWV matter?
Google uses these metrics as a ranking factor (Page Experience signal). More importantly: they correlate strongly with conversion. Fast page = more revenue.
The correlation with conversion is well documented. Google's own data shows that sites meeting the 2.5s LCP threshold see 24% fewer users leave than sites just above it. For e-commerce, every extra second of load time costs an average 7% in conversion. That makes CWV a direct business metric, not just a technical SEO checkbox.
How do you measure Core Web Vitals?
Google Search Console (field data from real users), PageSpeed Insights (lab + field), Chrome Lighthouse. Always compare field data, not just lab values.
The distinction between lab and field data is crucial. Lab data (Lighthouse, PageSpeed lab tab) measures your page in a controlled environment. Field data (CrUX. Chrome User Experience Report) shows how real users experience your page on their own device and connection. Google uses field data for rankings. An excellent Lighthouse score does not fix your ranking problem if field data is red.
Real-world example
An SME webshop in Noord-Brabant had an LCP of 4.2s (red) due to an unoptimised hero image of 1.8 MB. After compression to WebP (220 KB) and preloading the LCP element, LCP dropped to 1.9s. Result: PageSpeed score rose from 48 to 84, and in the six weeks after, organic mobile traffic increased by 22%. Conversion rate rose by 11%, same product, same price, just loading faster.
How to fix CWV issues
Improve LCP: compress the hero image (WebP, max 200 KB for mobile), add a preload tag, use a CDN, and eliminate render-blocking resources.
Improve INP: identify heavy JavaScript tasks via the browser dev tools Performance tab. Code-splitting and deferring non-critical scripts with defer or idle callbacks are the main solutions.
Improve CLS: reserve dimensions for images and embeds (width/height attributes or aspect-ratio CSS), load ads and cookie banners only after layout is established.
Common mistakes
Only looking at Lighthouse: a high Lighthouse score in lab does not guarantee good field data. Always use both.
Fixing CWV once: after a site update or plugin install, scores can worsen. Schedule monthly monitoring.
Treating all pages the same: Google assesses CWV per page type (homepage, category page, product page). Fix highest-traffic pages first.
Ignoring INP: many teams focus on LCP and forget INP, while INP is the weakest link on JavaScript-heavy sites.
Related terms
Page Experience: the broader Google signal that includes CWV, plus HTTPS, mobile-friendliness and intrusive interstitials.
TTFB (Time To First Byte): how fast the server responds. High TTFB directly affects LCP, start with hosting if TTFB is above 600ms.
Lighthouse: Google's open-source audit tool that measures CWV and other web performance metrics in a controlled environment.
Want to know where your Core Web Vitals stand?
Request a CWV scan →