Core Web Vitals (LCP, INP, CLS) measure how a page feels to a real user: how fast the main content loads, how responsive the page is to input, and how much the layout jumps around. Google's guidance is consistent: page experience is a soft signal for ranking, not a hard gate. But "soft" still means it matters. A page with otherwise strong AI Overview signals but bad CWV can be edged out by a competitor with good ones.
What Google says
“Provide a good page experience for those who arrive at your site. This includes ensuring your site displays well across all devices, reducing latency, and making it easy for people to distinguish your main content.”
Why this matters for AI Overviews
The three Core Web Vitals and their "good" thresholds, per Google:
| Metric | What it measures | "Good" threshold |
|---|---|---|
| LCP (Largest Contentful Paint) | Time until the largest content element renders | ≤ 2.5 seconds |
| INP (Interaction to Next Paint) | Responsiveness to user input across the session | ≤ 200 milliseconds |
| CLS (Cumulative Layout Shift) | How much the layout shifts unexpectedly | ≤ 0.1 |
Why this matters for AI Overviews specifically:
- Quality systems power both. Google has stated that AI Overviews are rooted in the same ranking quality systems as classic Search. Page experience is one of those systems. A page that underperforms in CWV underperforms across the board.
- AI Overview clicks are higher-intent. Google's own framing: "When people click from search results pages with AI Overviews, these clicks are higher quality." A slow page that does eventually get the click is more costly when the click was hard-earned.
- Mobile-first. AI Overview surfaces are designed primarily for mobile. Mobile CWV is the version that matters; desktop is secondary.
CWV is not a binary gate. A page with 3.0s LCP can still appear in AI Overviews. But against a competitor with 1.8s LCP and otherwise equivalent content, the competitor has an edge.
How to fix it
Step 1: Measure where you actually stand
Two tools, in this order:
- PageSpeed Insights for a specific URL. Shows field data (CrUX, real users) and lab data (Lighthouse, simulated). Field data is what Google uses for ranking.
- Search Console → Core Web Vitals report. Shows aggregated CWV across your site at scale, by URL group.
Our AI Overview Checker hits the PageSpeed Insights API when configured and reports CWV inline with the rest of the audit, so you see all the signals together.
Step 2: The fixes that actually move the numbers
In our experience the highest-leverage fixes per metric:
LCP (slow main content):
- Preload the hero image:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high"> - Serve hero images in modern formats (AVIF, WebP) at correct dimensions
- Use a CDN with caching close to your visitors
- Eliminate render-blocking JS in the head
- Server response time under 600ms (the cap below which everything else gets easier)
INP (sluggish interactions):
- Break up long JavaScript tasks; nothing single-thread heavier than ~50ms
- Defer non-critical third-party scripts (analytics, chat widgets, A/B testing)
- Audit hydration cost on React/Vue/Svelte pages; SSR + selective hydration usually wins
- Avoid heavy event handlers on common inputs (typing, scrolling)
CLS (jumpy layout):
- Set explicit
widthandheighton every image (or useaspect-ratioin CSS) - Reserve space for ads, embeds, and dynamic content with placeholder containers
- Use
font-display: optionalto avoid layout shift on font load - Avoid injecting content above existing content after the page loads
Step 3: Verify
Field data updates over a 28-day window. So you ship a fix, then wait a few weeks before the official measurement reflects it. Lab data updates immediately and is a fair predictor.
What not to spend time on
- "Optimizing for Lighthouse score." Lighthouse is lab data; field data is what Google uses for ranking. A 100/100 Lighthouse score with bad real-user CWV does not help.
- Micro-optimizations on a page that already passes. Marginal returns. Focus on the pages and URL groups that are failing in Search Console.
- Removing analytics or chat widgets entirely. The fix is usually deferring or async-loading them, not removing.
Common mistakes when implementing the fix
- Optimizing only desktop CWV. Mobile is the version that matters for ranking.
- Treating CWV as a hard gate. It is a soft signal. A 3.0s LCP page can still appear in AI Overviews; just at a disadvantage.
- Trusting Lighthouse over field data. Lab tests are not what Google ranks on.
- Adding more JavaScript "to fix performance." Usually the wrong direction.
