Core Web Vitals are three measurements Google uses to describe how a page feels to use. Not how fast the server responds — how it feels to a real person on a real phone.
They're a ranking factor, though a modest one. The bigger reason to care is that they correlate strongly with revenue. Slow, jumpy pages lose customers regardless of where they rank.
Here's what each one measures, in language you can act on.
LCP — Largest Contentful Paint
What it measures: how long until the biggest visible element on screen finishes loading. Usually a hero image, video poster, or large block of headline text.
Target: under 2.5 seconds.
LCP is a proxy for "when does this page look like it's ready." A visitor staring at a blank space isn't reading your value proposition.
What usually causes bad LCP:
- Enormous unoptimized hero images (a 4MB JPEG is still remarkably common)
- Slow server response time
- Render-blocking CSS and JavaScript in the head
- Webfonts that delay text rendering
- Client-side rendering that requires JavaScript before anything appears
The fixes that matter most:
Compress and resize images properly, and serve modern formats — WebP or AVIF typically cut file size by 30–50% at equivalent quality. Use srcset so phones don't download desktop-sized images.
Preload your LCP image and mark it fetchpriority="high". This one attribute frequently shaves half a second.
Never lazy-load the hero image. Lazy loading is for content below the fold; applying it to the LCP element actively delays it.
Get a decent host. Shared hosting with 800ms response times caps your LCP before you've optimized anything else.
INP — Interaction to Next Paint
What it measures: how quickly the page responds visually when someone taps or clicks. It samples all interactions during a visit and reports roughly the worst one.
Target: under 200 milliseconds.
INP replaced First Input Delay in 2024 because FID only measured the first interaction, which flattered pages that felt sluggish thereafter.
What causes bad INP:
- Heavy JavaScript blocking the main thread
- Too many third-party scripts — chat widgets, heatmaps, ad pixels, A/B testing tools
- Large, inefficient event handlers
- Expensive layout recalculations triggered by interaction
The fixes:
Audit your third-party scripts and remove what you're not using. Most sites carry two or three tags from tools they stopped using a year ago, each still costing every visitor.
Break up long JavaScript tasks. Anything running over 50ms on the main thread should be split or deferred.
Defer non-critical scripts until after interaction. Chat widgets in particular don't need to load in the first second.
Provide immediate visual feedback on interaction — a button state change costs nothing and makes the wait feel intentional rather than broken.
CLS — Cumulative Layout Shift
What it measures: how much content jumps around while loading.
Target: under 0.1.
This is the one everyone has experienced: you go to tap a link, an ad loads above it, the page shifts, and you tap something else entirely. It's the most viscerally annoying of the three.
What causes bad CLS:
- Images and videos without width and height attributes
- Ads, embeds, and iframes inserted without reserved space
- Banners or notification bars injected at the top after load
- Webfonts swapping and changing text dimensions
- Content injected dynamically above existing content
The fixes:
Always set explicit width and height on images and video, or use CSS aspect-ratio. The browser then reserves the correct space before the file arrives.
Reserve space for anything loaded asynchronously — a min-height container for an ad slot or embed.
Use font-display: optional or preload your fonts, and pick a fallback with similar metrics so the swap doesn't reflow text.
Never insert content above existing content after load. If you need a cookie banner, overlay it rather than pushing the page down.
Lab Data vs Field Data
This trips people up constantly.
Lab data comes from tools like Lighthouse running a simulated test on your machine. It's repeatable and useful for debugging, but it's one synthetic run.
Field data comes from the Chrome User Experience Report — actual measurements from actual Chrome users over the previous 28 days. This is what Google uses for ranking.
They frequently disagree. A perfect Lighthouse score alongside failing field data usually means your real users are on slower devices and connections than your test environment.
Trust field data. Use lab data to find what to fix.
Check field data in Google Search Console under the Core Web Vitals report, or in PageSpeed Insights where it appears above the lab results.
What This Is Worth
Google's own guidance describes Core Web Vitals as a tiebreaker rather than a dominant signal. Excellent content on a mediocre-performing page still beats thin content on a fast one.
The commercial case is stronger than the SEO case. Published studies across retail and publishing consistently show conversion improvements in the range of several percent for each second of load time removed, and lower bounce rates on stable, responsive pages.
Put differently: fix these because they make you money, and take the ranking benefit as a bonus.
Where to Start
If you're triaging with limited time:
- Compress your images. Usually the largest single win, and often achievable in an afternoon.
- Set dimensions on every image. Fixes most CLS problems outright.
- Remove unused third-party scripts. Free performance, zero risk.
- Check your hosting response time. If it's over 600ms, no amount of front-end work will save you.
- Preload the LCP image. One line, frequently significant.
That list solves the majority of performance problems on the majority of sites. The remaining work gets specialized quickly — but you rarely need it until the basics are done.
Want to know your actual field scores? We'll run a full performance audit and hand you a prioritized fix list ordered by impact per hour of work.