LCP, CLS and INP are Google's measure of real-user page experience — loading, stability and responsiveness. They're a ranking signal and a conversion lever at once. Here's what each one means and exactly how to improve it.
Three metrics that approximate how a page actually feels to a real user: does it load fast, stay stable, and respond quickly?
Google uses page experience as a ranking signal, and Core Web Vitals are its measurable core. They're assessed on real-user data, predominantly mobile. The goal isn't a perfect lab score — it's passing the "good" threshold for each metric for most of your visitors. The three vitals each capture a different part of the experience, and each has its own causes and fixes, covered below.
What each measures, the good threshold, and the fixes that move it.
Measures how long until the largest content element (usually the hero image or main heading) renders. Good: 2.5s or less. Fixes: compress, size and preload the hero image; serve modern image formats; cut server response time (TTFB) with caching and a CDN; remove render-blocking CSS/JS. The LCP element is most often an image, so image optimisation is usually the biggest win.
Measures how much the page unexpectedly jumps around as it loads. Good: 0.1 or less. Fixes: set explicit width and height (or aspect-ratio) on images, videos and embeds so space is reserved; reserve space for ads and dynamic content; use font-display: swap carefully and preload fonts to avoid text reflow. CLS is what makes you tap the wrong button because the layout shifted — eliminating it is mostly about reserving space up front.
Measures how quickly the page visually responds to user interactions (taps, clicks, key presses) across the whole visit. Good: 200ms or less. Fixes: break up long JavaScript tasks, defer non-critical scripts, minimise main-thread work, and avoid heavy work in event handlers. INP replaced First Input Delay as a Core Web Vital; it's a stricter, whole-session measure of responsiveness.
The audit also catches the unglamorous performance drains that feed into them.
Non-minified JavaScript and CSS · uncompressed (no gzip/brotli) assets · oversized pages · render-blocking resources · unoptimised images (the most common LCP killer) · missing viewport meta (breaks mobile rendering) · reliance on plugins. These don't appear in the three vital scores directly, but they're the underlying causes of poor LCP and INP — and they're concrete, fixable engineering tasks. Always validate fixes on mobile, where vitals are hardest to pass and where most of your users actually are.
They're a real but modest signal — most influential as a tiebreaker between pages of similar relevance and quality. Content relevance still dominates. The stronger reason to fix them is user behaviour: faster, more stable pages keep more of your existing visitors and convert better, so the payoff is both a small ranking lift and a real engagement gain.
Lab data (like a PageSpeed test run) is a controlled, repeatable simulation useful for debugging. Field data is real-user measurement over time, which is what Google uses for the page experience signal. Use lab tests to diagnose and fix, and field data to confirm the improvement reached real users.
No. The target is passing the "good" threshold for each vital for most users, not a perfect lab score. Chasing the last few points often has diminishing returns; getting LCP, CLS and INP into the green on mobile is what matters.
Free to start. Test your key pages and find the assets and templates slowing them down.
Start my free audit