Google's search documentation has been explicit about page experience signals — including Core Web Vitals — as ranking factors since 2021. What has become clearer in the AI search era is that these performance signals do not just influence rankings in the traditional results page. They influence whether AI systems — including AI Overviews, Gemini, and the emerging class of AI agents that browse on behalf of users — treat your content as credible and accessible enough to include in their outputs.
A website that loads slowly, shifts its layout unexpectedly, or takes too long to respond to interaction is not just frustrating to human visitors. It signals to Google's quality evaluation systems that the experience your site provides is below the threshold Google wants to vouch for when it cites content in an AI-generated answer. Understanding the specific metrics, what the passing thresholds are, and how they connect to AI visibility is now a core part of maintaining organic search presence in 2026.
What Core Web Vitals Actually Measure
Core Web Vitals are three standardized metrics that Google uses to measure the real-world experience of loading and using a web page. They are distinct from older performance metrics like page load time or Time to First Byte, which measured technical server behavior rather than the user experience of interacting with a rendered page.
Largest Contentful Paint (LCP)
LCP measures how long it takes for the largest visible element on the page — typically the hero image, a large headline, or a video thumbnail — to finish loading and render to the user's screen. It is Google's proxy for "when does the page feel usable?" because the largest visible element is usually what users are waiting to see before they can engage with the content.
LCP is measured from the moment the page starts loading to the moment the largest element paints to the screen. A slow LCP means users are staring at a partial or blank page while they wait, which Google treats as a poor experience signal.
Interaction to Next Paint (INP)
INP replaced the older First Input Delay (FID) metric in 2024. Where FID measured the delay before the browser could respond to a user's very first click or tap, INP measures the responsiveness of all interactions throughout the entire session — every click, tap, or keyboard input the user performs while on the page.
INP is a more comprehensive responsiveness metric because it captures whether a page feels sluggish throughout a visit, not just at the first moment of interaction. A page with a fast initial load but sluggish JavaScript that makes buttons feel unresponsive after the user scrolls down will fail INP even if it passes LCP.
Cumulative Layout Shift (CLS)
CLS measures visual stability — specifically, how much the page layout moves around unexpectedly while loading or during use. When images load without reserved space, when fonts render and change the text layout, when late-loading ads push content down the page, or when consent banners appear and shift the entire page — all of these create CLS. High CLS means users are trying to interact with elements that move before they can click on them, which Google registers as a poor experience.
CLS is measured as a score (not a time value). It accumulates across the session, which means pages that shift content repeatedly — due to infinite scroll, lazy-loaded images without size attributes, or dynamic content injection — can accumulate a high CLS score even if each individual shift seems small.
The Exact Passing Thresholds
Google defines three tiers for each metric: Good, Needs Improvement, and Poor. The "Good" threshold is what you should target across the 75th percentile of real user sessions measured from Chrome's field data. The 75th percentile standard means 75% of your users need to experience Good performance — not just the average or median user.
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2.5 seconds | 2.5s – 4.0s | > 4.0 seconds |
| INP (Interaction to Next Paint) | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS (Cumulative Layout Shift) | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
To pass Core Web Vitals and achieve a "Good" page experience classification, all three metrics must be in the Good range at the 75th percentile for real user data. Passing two out of three is not sufficient — Google evaluates the worst-performing metric, and a single Poor or Needs Improvement metric drags the entire page experience assessment down.
The 75th percentile standard: Your Core Web Vitals aren't measured by the average user — they're measured by your 75th-percentile user. This means if your slowest 25% of visitors have a poor experience, you fail, even if most visitors are fine. Mobile visitors on slower connections are often the ones dragging this number down.
How Page Speed Connects to AI Search Visibility
The connection between page performance and AI search visibility operates through several channels that are distinct from traditional ranking signals.
AI Overviews and Content Trustworthiness
Google's AI Overviews pull from a curated subset of web content that Google has evaluated as reliable, well-structured, and representative of a good user experience. Performance signals — including Core Web Vitals — are part of how Google assesses overall page quality. A page with chronic performance failures signals to Google's quality systems that the site is not well-maintained, which affects the probability that its content is included in AI-generated summaries.
This is not a binary exclusion — there is no documented rule that says "fail Core Web Vitals, never appear in AI Overviews." But the correlation between page quality signals (including performance) and AI search citation frequency is real. Google's internal quality evaluation guidelines (the Search Quality Rater Guidelines) emphasize that low-quality pages — including poorly maintained or slow-loading pages — should not be recommended or amplified. AI Overviews are an extension of Google's recommendation systems.
Agentic Browsing and Performance Timeouts
AI agents that browse websites on behalf of users — like Google's Project Mariner and similar tools — operate within time constraints. When an agent navigates to a page to evaluate it or complete a task, a slow-loading page creates a practical barrier: the agent may time out, fail to load interactive elements before attempting to use them, or simply deprioritize the site in favor of faster alternatives that render completely before the agent's session window closes.
This is a more immediate and direct consequence of slow performance than the correlation-based AI Overview effect. An agent that cannot successfully load and interact with your booking page cannot complete a booking. A site with a 6-second LCP may simply fail to serve the agent before the session ends.
Mobile Performance as an AI Signal
Google's primary indexing is mobile-first, which means Core Web Vitals are measured primarily on mobile. Mobile performance is typically worse than desktop for most sites — mobile devices have less processing power, mobile connections have higher latency, and mobile screens require responsive layout calculations that add rendering overhead. A site that passes Core Web Vitals on desktop but fails on mobile is, in Google's measurement system, failing Core Web Vitals.
AI search systems inherit this mobile-first assessment. When Google's crawlers and quality evaluation systems assess a page, they're doing so from a mobile perspective by default. Optimizing only for desktop speed and ignoring mobile performance leaves a substantial gap in your AI search readiness.
Where Sites Most Commonly Fail
Most small and mid-size business websites fail Core Web Vitals for a small number of predictable reasons. Understanding these failure patterns tells you where to direct optimization effort.
LCP Failures: Unoptimized Hero Images and Render-Blocking Resources
The most common cause of LCP failures is the page's primary hero image — the large background or banner image at the top — being delivered at full size without compression or modern format encoding. A 3MB JPEG hero image on a mobile connection will produce an LCP well above 4 seconds regardless of server speed.
The second most common LCP failure cause is render-blocking resources: JavaScript and CSS files in the document head that block the browser from painting anything to the screen until they finish downloading and parsing. Every render-blocking script in the head delays LCP by at least the time it takes to load and execute that file.
INP Failures: Bloated JavaScript Execution
INP failures almost always come from excessive JavaScript execution on the main thread. When the browser's main thread is busy parsing, compiling, and executing large JavaScript bundles, it cannot respond to user interactions. The result is clicks and taps that feel delayed or unresponsive — the user taps a button and nothing happens for 300–600ms before the page responds.
Third-party scripts — analytics platforms, chat widgets, ad networks, tag managers, tracking pixels — are common culprits. Each script executes on the main thread and competes with the page's own code for processing time. Sites with five or more third-party scripts active on every page load typically fail INP on mobile.
CLS Failures: Images Without Dimensions and Late-Loading Content
CLS failures usually come from images and media without explicitly set width and height dimensions in their HTML. When a browser encounters an image without dimensions, it reserves no space for it initially, then shifts the layout when the image loads and its dimensions become known. The same problem occurs with lazy-loaded images that don't have placeholder dimensions, fonts that shift text layout when they finish loading, and any content injected into the page after initial render (banners, cookie consent notices, chat widget overlays).
How to Measure Your Current Performance
Before fixing anything, you need accurate measurements. There are two distinct types of performance data: lab data from controlled tests and field data from real users.
Field Data: Google Search Console and CrUX
The most authoritative source for your Core Web Vitals performance is Google Search Console's Core Web Vitals report, which uses real Chrome user data (CrUX — Chrome User Experience Report) collected from actual visitors to your site. This is the data Google uses when evaluating your page experience signal. If this data shows failures, Google sees failures — regardless of what any synthetic test tool shows.
The CrUX report in Search Console separates mobile and desktop data, shows URL-level detail for large sites, and indicates whether pages are in the "Good," "Needs Improvement," or "Poor" category at the 75th percentile. Start here before using any other tool.
Lab Data: PageSpeed Insights
Google's PageSpeed Insights tool runs a synthetic test of your URL and reports both field data (CrUX, if available) and lab data from a simulated load. The lab score (the 0–100 number) is useful for identifying specific issues and measuring the impact of fixes — but it is not the same as the field data Google uses for ranking. A page can score 95 in PageSpeed Insights and still fail Core Web Vitals in Search Console if real users on slower devices or connections have poor experiences.
Use PageSpeed Insights as a diagnostic tool to identify what to fix, not as a pass/fail indicator. The "Opportunities" and "Diagnostics" sections show specific issues with estimated impact.
Priority Optimization Actions
Addressing Core Web Vitals failures follows a predictable priority order. The actions with the largest impact on the largest number of sites are:
1. Convert and Compress Images
Serve all images in WebP or AVIF format instead of JPEG or PNG. Both modern formats typically reduce file size by 30–50% at equivalent visual quality. Compress all images to the smallest file size that looks acceptable on screen. Set explicit width and height attributes on all <img> elements. Add loading="lazy" to all images below the fold, and add fetchpriority="high" to your hero/LCP image to tell the browser to prioritize it.
2. Preload the LCP Image
The LCP image — whichever image is the largest visible element on the page — should be preloaded in the document head using a <link rel="preload"> tag. This tells the browser to start downloading that image as early as possible, before the browser has parsed the CSS or JavaScript that would normally trigger the image load. This single change can reduce LCP by 0.5–1.5 seconds on many sites.
3. Defer Non-Critical JavaScript
Add defer or async attributes to all script tags that do not need to execute before the page renders. Defer all third-party scripts that do not affect the initial render — analytics, chat widgets, social sharing buttons, and tracking pixels can all be deferred to after the main content loads without affecting user experience. Reducing the JavaScript that blocks the main thread directly improves both LCP and INP.
4. Audit and Reduce Third-Party Scripts
Conduct a third-party script audit. List every script your site loads, what it does, and whether it is actively used. Remove anything that is not actively providing business value. Consolidate where possible — using Google Tag Manager to load multiple tracking scripts through a single container reduces the number of network requests and reduces main-thread competition. Each third-party script you remove improves INP and LCP.
5. Reserve Space for All Dynamic Content
Set explicit dimensions on all images and video elements. Use CSS min-height or aspect-ratio on containers that load dynamic content (ads, embeds, comments). If you use a cookie consent banner or any overlay that appears after page load, ensure it does not push existing content down — use a fixed-position overlay rather than injecting it into the page flow.
6. Enable Caching and Compression at the Server Level
Ensure your web server or CDN is serving compressed responses (gzip or Brotli) for all HTML, CSS, and JavaScript files. Enable long-term caching for static assets (images, fonts, CSS, JS) with appropriate Cache-Control headers. For sites on Cloudflare, ensure minification and Brotli compression are enabled in the Speed settings.
Key Takeaways
- Core Web Vitals — LCP, INP, and CLS — are the three metrics Google uses to measure real-world page experience; all three must be in the Good range to pass
- Passing thresholds are LCP ≤ 2.5s, INP ≤ 200ms, and CLS ≤ 0.1 — measured at the 75th percentile of real user data, not the average
- AI search systems, including AI Overviews and agentic browsing tools, use page quality signals (including performance) to determine which content to include or interact with
- Slow sites face practical barriers in agentic browsing scenarios — AI agents on a time constraint may fail to load or interact with slow pages, causing missed bookings and contacts
- Google's Core Web Vitals are measured mobile-first; desktop-only optimization misses the primary signal Google uses
- The most common LCP failure is unoptimized hero images; INP failures usually come from third-party JavaScript; CLS failures come from images without reserved dimensions
- Google Search Console's Core Web Vitals report shows the real field data Google uses — this is your ground truth, not synthetic tool scores
Further Reading
- What Is AI Search Adaptation? — the broader shift in how AI systems discover and cite web content
- What Is Agentic Browsing (Beta)? — how AI agents navigate websites autonomously and what your site needs to support them
- What Is E-E-A-T? — the trust and authority signals Google evaluates alongside performance
- Core Web Vitals Optimization Service — our LCP, INP, and CLS remediation process