Every time the search world shifts, the same question reliably comes back: are Core Web Vitals still worth caring about? Now that AI Overviews and chat assistants drive part of the buyer journey, does the old performance work still matter?
The short answer: yes, it matters more, not less. The longer answer is worth understanding because the way it matters has changed slightly.
What Core Web Vitals actually are
Three real-user performance metrics Google measures for every page on the open web:
LCP (Largest Contentful Paint): how quickly the main content of the page becomes visible. Target: under 2.5 seconds for 75% of visits.
INP (Interaction to Next Paint): how quickly the page responds when a user interacts. Target: under 200 milliseconds for 75% of visits. Replaced the older FID metric in 2024.
CLS (Cumulative Layout Shift): how stable the page is as it loads — whether things jump around as resources arrive. Target: under 0.1.
The numbers come from real users visiting your site through Chrome, aggregated through the Chrome User Experience Report. Not from synthetic Lighthouse tests on a developer's laptop — though Lighthouse is useful as a debugging tool, it is not what counts for ranking.
What changed with AI
Three things.
First, the surfaces that consult Core Web Vitals have expanded. Google still uses them as a ranking signal in traditional search. But AI engines pulling content in real time — for citations in chat answers, for AI Overviews, for related-page suggestions — also prefer sites that respond quickly. A slow page that times out during retrieval is a page that does not get cited.
Second, the bar for "fast enough" has effectively risen. As more sites do the performance work, the median has improved, and the relative penalty for being slow has grown. Five years ago a 3-second LCP was middle-of-the-pack. Today it is below the threshold for "good" on most measurements.
Third, the user expectation has changed. Real visitors arriving from an AI citation are often arriving with context: they were told this page would answer their question. Slow load times in that context feel worse than they did when the visitor was randomly clicking a search result.
What is the same
The underlying mechanics of making a site fast have not changed dramatically:
Cache the right things. Full-page cache for content that does not vary per visitor. Object cache for database query results. Fragment cache for dynamic bits inside otherwise cacheable pages. CDN cache for assets, with sensible cache lifetimes.
Compress and optimize images. WebP or AVIF instead of JPEG/PNG where it works. Responsive image sizes so phones do not download desktop-resolution images. Lazy load below-the-fold images so they do not block initial paint.
Defer non-critical JavaScript. Most marketing pages do not need 300KB of analytics, chat widgets, and A/B testing libraries to load before the main content paints. Most do anyway. The fix is technical but real.
Reduce render-blocking CSS. Inline the critical bits. Defer the rest. Skip the CSS framework's "kitchen sink" file when you use a tenth of it.
Sane fonts. Self-hosted, preloaded, with proper font-display, in a single weight per family unless you really need more. Web fonts done badly can single-handedly tank LCP.
We covered these in more depth in why your website feels slow even when hosting looks fine, but the short version is: Core Web Vitals are downstream of basic engineering hygiene, not a separate discipline.
What people get wrong
Treating Lighthouse scores as the target. Lighthouse runs synthetic tests in a controlled environment. It is great for diagnosing what is slow and why. It does not measure what Google actually uses for ranking. A site with a Lighthouse score of 100 and real-user CrUX data that says LCP is 4 seconds will be penalized for the 4 seconds, not rewarded for the 100.
Adding a performance plugin and calling it done. The right caching plugin can move metrics meaningfully. The wrong one — or the right one configured wrong — can make things slower. We have audited sites where a "performance plugin" was the largest single contributor to slow load times, because it was minifying inline scripts in a way that broke the page or shipping deferred JavaScript that blocked render anyway.
Optimizing the home page only. Google measures Core Web Vitals at the page level, aggregated by domain. A great home page with terrible category pages still gets penalized. Performance work needs to span the templates that real visitors actually land on.
Ignoring mobile. Most real users are on phones. Most phones are slower than developers' devices. Designing and testing only on desktop is how sites end up with great-looking metrics that bear no resemblance to what most visitors experience.
How AI citation specifically rewards fast sites
This is the newer dynamic worth understanding.
When an AI engine pulls a page in real time to inform an answer, it has a time budget. Some engines will give a page 2-3 seconds to respond, others longer, none unlimited. A page that responds slowly — or that loads its main content client-side via JavaScript that takes another second to execute — is more likely to be skipped or to have its content read incompletely.
The result is that the same fast-loading, server-rendered, semantic HTML that wins at Core Web Vitals also wins at AI retrieval. The two reward the same engineering. Getting cited in ChatGPT goes into more detail on the citation side.
Where to focus first
If your Core Web Vitals are currently in the "needs improvement" or "poor" range, the highest-yield work is usually:
Image strategy first. Heavy, unoptimized images are the most common LCP killer. Audit the home page and the top 5 landing pages. Convert to WebP. Add responsive sizes. Lazy-load below-the-fold.
JavaScript audit second. Identify the scripts that block render or run unnecessarily on initial load. Defer, async, or remove.
Cache layer third. Object cache (Redis or Memcached), full-page cache where appropriate, CDN with sensible rules.
Theme and plugin triage fourth. The slowest sites we see are usually slow because a specific plugin or theme is doing something expensive on every page load. Fixing that single thing often moves all three metrics meaningfully.
Real-user measurement throughout. Watch the CrUX data over a 4-8 week window after changes. Synthetic tests will tell you what improved; real-user data will tell you whether visitors actually felt it.
The honest bottom line
Core Web Vitals are not a separate AI-era thing. They are the same performance fundamentals search engines have been pushing for years, now enforced more strictly and consulted by a broader set of engines. The work to fix them is well-understood. The payoff is visible across rankings, AI citations, conversion rates, and the simple fact that visitors stick around longer on pages that feel fast.
If your site is slow and you are not sure exactly why, our performance optimization work usually starts with a diagnostic pass that identifies the actual bottleneck — and the actual bottleneck is rarely what people guess. Get in touch if you want a real read on what is happening on your site.
