Core Web Vitals are three measures Google uses to judge the user experience of a web page: LCP measures how long the largest element takes to appear, INP how quickly the page responds to a tap, and CLS how much content jumps while loading. To pass, LCP must be under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1.
LCP (Largest Contentful Paint) measures when the largest visible element appears - usually the hero image or the main heading. If the user stares at a blank screen for more than 2.5 seconds, LCP is poor. The usual culprits are unoptimised images and scripts that block rendering.
INP (Interaction to Next Paint) measures how long the page takes to visibly respond to a tap or click. It replaced the older FID metric in March 2024. Poor INP means the user presses a button and nothing happens - most often because heavy JavaScript is blocking the main thread.
CLS (Cumulative Layout Shift) measures how much content jumps while the page loads. The classic example is reaching to tap a link just as an image loads above it and pushes everything down. It is solved by giving images and ad slots declared dimensions.
Google sorts each measure into three bands. For LCP: good is under 2.5 seconds, needs improvement up to 4 seconds, poor above that. For INP: good under 200 ms, needs improvement up to 500 ms. For CLS: good under 0.1, needs improvement up to 0.25.
Importantly, the score is calculated from real visitors, not a laboratory test. Google uses Chrome field data at the 75th percentile - meaning three quarters of your visitors must have a good experience, not the average.
Less than people assume. Core Web Vitals are a ranking signal, but a weak one compared with content relevance. A fast page that does not answer the question will not overtake a slower page that does.
Their real significance is in conversion. A visitor waiting five seconds on a mobile network often gives up before seeing anything - and that is not measured as a position but as lost enquiries.
For checking, use PageSpeed Insights or the Core Web Vitals report in Google Search Console. Search Console shows real field data and groups pages by issue, which makes it more useful on larger sites.
The usual fixes run in this order: image compression and a move to WebP, loading="lazy" on images below the fold, explicit width and height attributes, gzip or brotli compression on the server, and deferring JavaScript not needed for the first render.
On most small sites images account for 80 percent of the problem. A single uncompressed 4 MB photo can wreck LCP across every device.
Loading speed is easiest to argue with numbers from your own analytics rather than theory. Compare the bounce rate on mobile against desktop - if mobile is noticeably worse while the content is identical, the cause is almost always speed.
On sales pages the link is direct: a visitor who waits loses patience before seeing the offer, so the loss shows up as fewer enquiries rather than a worse position. That is why speed optimisation often delivers more than any change to the copy.
A practical order if your time is limited: images first, then server compression, then deferring scripts. On a typical small site those three cover most of the problem and none of them requires redesigning anything.
It is also worth knowing that Core Web Vitals are measured per page, not per site. A fast home page does nothing for a sub-page carrying an uncompressed gallery.
Last updated: 17 August 2026
Send the address and we will tell you where you stand - no obligation.
Send an enquiry
