Core Web Vitals are Google's way of measuring how a page feels to a real visitor: how quickly the main content appears, how fast the page reacts when someone taps, and whether things jump around while it loads.
They matter for two reasons. They are part of Google's page experience signals, and — more importantly — slow, jumpy pages lose customers. Here is what each metric means and the fixes that actually move it.
The three metrics and their targets
Google measures each metric at the 75th percentile of real page loads, on mobile and desktop separately. To pass, 75% of visits need to hit the "good" threshold.
| Metric | Measures | Good |
|---|---|---|
| LCP — Largest Contentful Paint | When the main content (usually the hero image or heading) has loaded | 2.5 seconds or less |
| INP — Interaction to Next Paint | How quickly the page responds to taps, clicks and key presses | 200 milliseconds or less |
| CLS — Cumulative Layout Shift | How much the layout jumps around while loading | 0.1 or less |
INP replaced the older First Input Delay (FID) metric in March 2024. It is stricter: FID only looked at the first interaction, INP looks at all of them.
Fixing LCP: get the main content on screen fast
LCP is usually the hero image or the main heading. The biggest wins, in order:
- Serve the hero image properly. Use modern formats (WebP or AVIF), size it for the screen, and never lazy-load the image that is above the fold.
- Tell the browser early. Add
fetchpriority="high"to the hero image and preload critical fonts. - Cut server response time. Slow hosting and uncached pages delay everything. Page caching and a CDN often shave a full second off.
- Remove render-blocking resources. Large CSS and JavaScript files in the page head make the browser wait before it paints anything.
Fixing INP: make every tap feel instant
Poor INP almost always comes from too much JavaScript running on the main thread.
- Audit third-party scripts. Chat widgets, heatmaps, multiple analytics tags and ad pixels are the usual culprits. Remove what nobody uses; load the rest after the page is interactive.
- Break up long tasks. Any single script task over 50ms blocks the page from responding. Split heavy work into smaller pieces.
- Show feedback immediately. When a button starts a slow action, update the button state first, then do the work.
- Avoid giant DOM trees. Pages with thousands of elements are slow to update on every interaction.
Fixing CLS: stop the page from jumping
Layout shift is the most annoying problem for users and often the easiest to fix.
- Give every image and video a width and height (or an aspect ratio) so space is reserved before it loads.
- Reserve space for embeds and ads instead of letting them push content down.
- Load web fonts carefully. Use
font-displayand fallback fonts with matched metrics so text does not reflow when the real font arrives. - Never insert content above existing content, such as cookie banners or promo bars, unless space is reserved for it.
How to measure it properly
There are two kinds of data, and you need both:
- Field data comes from real Chrome users. You see it in Google Search Console's Core Web Vitals report and in PageSpeed Insights. This is what Google uses.
- Lab data comes from a single simulated test, such as Lighthouse. It is useful for debugging but is not what Google ranks on.
A common mistake is chasing a 100 Lighthouse score while real users on mid-range Android phones still have a slow experience. Always test on a real, average phone on mobile data.
Where to start
If you only do three things this month:
- Optimise and prioritise the hero image.
- Remove or defer third-party scripts you do not need.
- Add dimensions to every image and embed.
Every site we build ships with Core Web Vitals checked before launch. If your current site is slow, we can audit it and send you a prioritised fix list.
