Core Web Vitals are Google's page experience metrics — LCP, CLS and INP. They measure how fast your page loads, how stable the layout is, and how responsive it is to user input. All three are direct Google ranking factors.
⚡ Check Core Web Vitals All Audit Tools →Google uses field data — real measurements from actual Chrome users visiting your pages — for ranking decisions. Lab data, from tools like Lighthouse running in a controlled environment, is useful for diagnosis but does not directly affect rankings. If your site has enough traffic, the Core Web Vitals Checker pulls real field data from the Chrome User Experience Report.
The three Core Web Vitals are frequently treated as one "speed problem". They are not. They fail for different reasons, they are fixed by different work, and a team optimising the wrong one will spend a month and move nothing.
The moment the largest visible element in the viewport finishes rendering. Usually a hero image, sometimes a heading or a block of text. Good is under 2.5 seconds; anything over 4 seconds is poor.
The critical insight is that LCP is a single element. Find out which one it is before touching anything — teams routinely compress every image on a page when only one of them was the LCP element, and the score does not move. LCP breaks down into four phases: time to first byte, resource load delay, resource load time, and render delay. Whichever phase dominates tells you where the work is, and it is frequently not the one you assumed.
How much the page jumps around while loading. Good is under 0.1. Unlike the other two, CLS is not about time at all — a page can load instantly and still score terribly.
It is also the metric users notice most viscerally, because it does not merely annoy them, it makes them click the wrong thing. Tapping "cancel" when you meant "confirm" because an ad loaded above the button and pushed everything down is a genuinely bad experience, and it is caused by something trivial to fix.
How long the page takes to visibly respond after a user interacts with it. Good is under 200 milliseconds. INP replaced First Input Delay, and the change was significant: FID measured only the delay before processing began, which flattered pages that responded quickly and then did nothing useful. INP measures the whole interaction, through to the point where the screen updates — which is what the user actually experiences.
INP is almost always JavaScript. A page that paints fast and responds slowly is a page whose main thread is busy, and the culprit is code, not images.
Do not guess. The LCP element is reported by every measurement tool, and it is frequently not what the team expected — a background image on a container, a large paragraph of text, a logo. Optimising the wrong element is the single most common wasted effort in performance work.
The browser is waiting for the server. No amount of image work will help, because nothing has arrived yet. Look at hosting, at slow database queries, at cold serverless starts, and at whether a CDN is actually serving the HTML rather than only the assets.
The image was discovered late. This happens when the LCP image is set by CSS, injected by JavaScript, or lazy-loaded — the browser cannot start fetching it until it has parsed something else first. The fixes are direct: put the image in the HTML as an <img>, preload it, and never lazy-load the LCP element. loading="lazy" on the hero image is a self-inflicted wound that appears on a startling number of sites.
The image is simply too big. Convert to WebP or AVIF, serve responsive sizes so a phone is not downloading a desktop image, and compress properly. A 2MB hero image is not a design decision, it is an oversight.
The image arrived and could not be painted, because the main thread was blocked or a web font had not loaded. Render-blocking CSS and synchronous JavaScript in the head are the usual causes.
loading="lazy" from the LCP image, and add fetchpriority="high" to it. Both are one-line changes and together they frequently take a second off LCP on their own.CLS has a small number of causes and all of them are cheap to fix. It is the best return on effort of the three metrics, and it is routinely ignored because it does not sound as serious as "slow".
An <img> with no width and height attributes occupies zero space until it loads, then suddenly occupies several hundred pixels and shoves everything below it down the page. Always set width and height, or a CSS aspect-ratio. The browser then reserves the space in advance and nothing moves.
Third-party content of unknown size, injected into the document flow. Reserve a container of fixed minimum height. If the ad is smaller, you have a gap; if you do not reserve, you have a layout shift — and the gap is much cheaper.
The page renders in a fallback font, then the web font arrives and every line of text reflows because the metrics differ. Use font-display: swap with a fallback chosen to match the web font's metrics, or size-adjust to align them. Preload the font so the swap happens early rather than after the user has started reading.
A cookie banner, a promo bar, an "we noticed you're in the UK" notice — anything that appears at the top of the page after render pushes the entire document down. Either reserve the space, or overlay it rather than inserting it into the flow.
Animating top, left, width or height causes layout recalculation and counts as a shift. Animate transform and opacity instead — they are composited and cause no shift at all.
INP is the hardest of the three, because it is not a single fix — it is the accumulated cost of everything the page runs.
Any single JavaScript task over 50ms blocks the main thread, and while it is blocked the page cannot respond to a tap. Long tasks are the direct cause of poor INP. Split them, yield to the main thread between chunks, and move heavy computation off the critical path entirely.
When a user taps, update the screen before doing the expensive work. Show the button in its pressed state, show a spinner, change the state — then run the analytics call, the validation and the network request. INP measures the time to the next paint, so painting early is not a trick, it is the metric behaving as designed: the user has been told their tap registered.
A click handler that triggers three analytics events, a heatmap recording and a re-render of the entire component tree is doing far more than the user asked for. Much of it can be deferred, batched, or removed.
On framework sites, the worst INP is frequently during hydration — the page is visible, and completely unresponsive, while the JavaScript attaches itself to the DOM. Ship less JavaScript, and do not hydrate components that are not interactive.
It is worth being honest about the size of the effect, because it is routinely overstated by people selling performance work.
Core Web Vitals are a ranking factor. They are not a large one. Google has been consistent that relevance outweighs page experience: a slow page that answers the question will beat a fast page that does not, and no amount of optimisation makes an irrelevant page rank.
Where the metrics do decide outcomes is between comparable pages. If two results are otherwise close, the better experience wins — and that is a real and repeatable advantage, worth having. But a business ranking on page four does not have a speed problem, and treating Core Web Vitals as the reason is a comfortable way of avoiding the harder truth about the content.
The stronger argument for fixing them is not ranking at all. It is that layout shift, unresponsiveness and slow loading cost you conversions directly, measurably, and regardless of where you rank. That effect is larger than the ranking effect, and it applies to visitors who are already on the page.
They measure different things. Lighthouse is lab data — a simulated load on a throttled connection, in a controlled environment. Search Console reports field data from real Chrome users on real devices and networks. Field data decides rankings; lab data is for diagnosis. A perfect Lighthouse score with failing field data means your real users are having a worse time than your test environment suggests.
Pages with insufficient traffic have no CrUX data, and Google falls back to origin-level data or lab signals. New pages are therefore more sensitive to lab improvements than established high-traffic ones.
CLS, almost always. It is the cheapest to fix — dimensions on images, reserved space for embeds — and it has the most direct effect on whether users click the thing they meant to click. LCP second. INP last, because it is the most expensive and usually requires reducing JavaScript rather than configuring it.
Modestly, and only where you are already competitive. Page experience is a tiebreaker between comparable results, not a substitute for relevance. If you are ranking on page four, the problem is not your LCP.
INP. FID measured only the delay before an interaction began processing, which flattered pages that acknowledged input quickly and then did nothing useful. INP measures the full interaction through to the next paint — which is what a user actually experiences.
Run the Core Web Vitals Checker and get actionable results in minutes. Pay as you go — no subscription needed.
Check Core Web Vitals →aiwebpageseo.com is a data-driven SEO and AEO (Answer Engine Optimisation) platform providing a free suite of technical website tools. Rather than relying on AI-theorised assumptions, the platform analyses live URL performance, delivering objective diagnostics, page speed metrics, CLS debugging, and site crawl data alongside actionable technical tutorials.