Core Web Vitals are three numbers Google uses to describe whether your page feels fast to a real person. They are a ranking factor, but more importantly they correlate with whether visitors stay. Here is what each one actually means.
LCP — Largest Contentful Paint
How long until the biggest visible thing appears. Usually your hero image or your main heading.
- Good: under 2.5 seconds
- Needs work: 2.5 to 4 seconds
- Poor: over 4 seconds
What breaks it
- A huge hero image, uncompressed or served at desktop size on mobile
- The hero image lazy-loaded, so the browser deliberately delays the one thing it should not
- Webfonts blocking text rendering
- Slow server response before anything can start
- Content rendered only after JavaScript hydrates
How to fix it
- Identify the LCP element — PageSpeed Insights names it for you
- If it is an image: compress it, serve it in WebP or AVIF, size it correctly, and load it eagerly with high priority
- If it is text: preconnect to your font host and use font-display: swap
- Never animate the LCP element with JavaScript — use CSS so it does not wait for hydration
INP — Interaction to Next Paint
When you tap something, how long until the page visibly responds. This replaced the older First Input Delay metric because it measures every interaction, not just the first.
- Good: under 200 ms
- Needs work: 200 to 500 ms
- Poor: over 500 ms
What breaks it
- Too much JavaScript executing on the main thread
- Expensive work inside event handlers — filtering a large list on every keystroke
- Third-party scripts: chat widgets, tag managers, ad scripts
- React components re-rendering large trees unnecessarily
How to fix it
- Cut bundle size — check the Coverage tab for how much code is never used
- Load third-party scripts after the page is interactive
- Debounce expensive handlers like search-as-you-type
- Break long tasks up so the browser can respond between them
- Lazy-load components that are not visible yet
CLS — Cumulative Layout Shift
How much the page moves around while loading. This is the metric behind the universal experience of tapping a link and hitting an ad instead.
- Good: under 0.1
- Needs work: 0.1 to 0.25
- Poor: over 0.25
What breaks it
- Images without width and height, so the page reflows as each loads
- Ads or embeds injected with no reserved space
- Fonts swapping to a different size after load
- Banners or notices inserted at the top after render
- Animating properties that trigger layout instead of transform and opacity
How to fix it
Reserve space before the content arrives. Always set image dimensions or an aspect-ratio. Give ad slots a fixed minimum height. Animate transform and opacity, never top, left, width or height.
Lab data versus field data
PageSpeed Insights shows you two different things and people confuse them constantly:
- Lab data — a simulated load on a throttled connection. Immediate, repeatable, useful for debugging.
- Field data — real measurements from actual Chrome users over 28 days. This is what affects ranking.
A new or low-traffic site will show "insufficient real-world data" for field metrics. That is normal, not a problem. Optimise against lab data and the field data follows once traffic arrives.
How much does this affect ranking?
Less than people selling performance audits imply, and more than developers who dislike the topic admit. Google has been clear that Core Web Vitals are a tiebreaker: they will not lift bad content above good content, but between two comparable pages the faster one wins.
The stronger argument is commercial rather than algorithmic. Slow pages lose visitors before they read anything, and that shows up in conversions long before it shows up in rankings.
A sensible target
Aim for green on all three and a mobile score above 85. Chasing 100 is a poor use of time — the last ten points typically cost more effort than the first fifty and change nothing a user can feel.
