Core Web Vitals in Plain English

"Core Web Vitals" sounds like something only a developer should have an opinion on, which is exactly why most small business owners skip past it, nod along in an SEO report, and never find out what it actually means for their site. It is three numbers. Each one maps to something a visitor actually feels: does the page load fast, does it respond when I tap something, and does it hold still while I'm reading it. Once you see it that way, the jargon mostly falls away.

The three metrics, in the order a visitor experiences them

Largest Contentful Paint (LCP) measures loading speed, specifically how long it takes for the biggest visible piece of content, usually a hero image or a headline, to finish rendering. Google's own documentation states it directly: "To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading." Anything past 4 seconds is classified as poor; the zone in between is "needs improvement."

Interaction to Next Paint (INP) measures responsiveness: the delay between a visitor clicking, tapping, or typing and the page actually responding on screen. Google's threshold for a good result is direct too: "pages should have an INP of 200 milliseconds or less." This is the metric people notice without naming it, it's the half-second of nothing after you tap a mobile menu that makes you tap it again, unsure if it registered.

Cumulative Layout Shift (CLS) measures visual stability, how much content shifts position unexpectedly while a page is loading. Google again states the bar plainly: "pages should maintain a CLS of 0.1 or less." This is the metric behind the specific, common frustration of trying to tap a button and having an ad or image load in above it at the last second, so you tap the wrong thing instead.

All three are measured at the 75th percentile of real visits, across both mobile and desktop, which matters more than it sounds like it should. It means a site doesn't need every single visit to be fast. It needs three out of every four to meet the bar. A site that's fast for most visitors but occasionally slow for someone on an old phone and a weak connection can still pass.

The metric that quietly changed in 2024

If you learned about Core Web Vitals a few years ago and the name "First Input Delay" (FID) sounds more familiar than INP, that's not outdated information by accident. INP officially replaced FID as the responsiveness metric on March 12, 2024. The reason, per Google's own announcement, is that "over time, it became clear that a new metric was needed to capture aspects of interactivity on the web that FID did not." FID only clocked the delay before an interaction started; INP tracks the entire interaction, from the tap to the moment the screen actually updates, which is a more complete measure of whether a page feels responsive rather than just whether it started responding. If a site audit or an old blog post still talks about FID as one of the three, it's describing the pre-2024 version of this.

Does this actually affect rankings?

Not in the way most people assume. Google's Search documentation is specific that page experience signals, Core Web Vitals included, "align with what our core ranking systems seek to reward," which is a deliberately soft statement, not a promise that fixing your LCP score will out-rank a competitor's better content. The honest read: Core Web Vitals function more as a floor and a tiebreaker. A page with excellent content and a poor CLS score will usually still beat a thin page with a perfect score. But between two similarly strong pages, the faster, more stable one has a real edge, and a genuinely broken experience, pages that visibly jump around or ignore taps for half a second, will cost you conversions and return visits regardless of what Google does with the ranking.

How most of the web is actually doing

This is the part worth being honest about, because "Core Web Vitals" gets talked about as a pass/fail gate when the real picture is messier. According to an analysis of May 2026 Chrome User Experience Report (CrUX) data across more than 18 million measured origins, 55.9% of all tracked sites passed all three Core Web Vitals, a figure that had actually dipped slightly from the month before (digitalapplied.com). Broken down by individual metric, the same data put LCP at 68.6% good, INP at 86.6% good, and CLS at 81.3% good, which confirms what most site audits find in practice: loading speed is the hardest of the three to get right, and the other two tend to follow once that's solved.

The same source points to a persistent mobile gap: based on the 2025 Web Almanac's HTTP Archive data, desktop sites passed all three metrics 56% of the time against 48% on mobile, an 8-point gap driven mostly by slower network conditions and weaker processors on phones, not by anything structurally different about mobile pages. If your site passes on desktop and fails on mobile, that gap is normal, not a sign of a separate bug.

How to check where your own site stands

Two tools, and they're not interchangeable:

• The Core Web Vitals report in Google Search Console shows real visitor data grouped by URL, pulled from the same Chrome User Experience Report data Google itself measures against. This is the one that reflects what's actually being evaluated, and Google's own documentation points to it directly as the place to check.
• PageSpeed Insights tests a single URL on demand and shows both a lab score (a simulated test run right then) and field data (real visitor data, when the page has enough traffic for Google to report it). It's the faster way to check one page right now, but the lab score alone can diverge from what real visitors experience on real connections.

If a site gets meaningful traffic, Search Console is the more honest number. PageSpeed Insights is the better tool for diagnosing why a specific page is slow, since it lists the specific resources and scripts responsible.

Fixing each metric, specifically

For LCP: compress and properly size the hero image or largest element (a 4MB photo displayed at 600px wide is the single most common cause), use a modern image format, and make sure nothing (a render-blocking stylesheet, a font file, a third-party script) loads ahead of the main content in the page's request order. Server response time matters here too: a slow first byte from the server delays everything downstream of it, no matter how optimized the rest of the page is.

For INP: the usual culprit is JavaScript. Long-running scripts that block the browser's main thread mean a tap has to wait in line behind whatever the page is already doing. Breaking large scripts into smaller tasks, deferring anything not needed for the first interaction, and removing third-party scripts (chat widgets, ad tags, analytics snippets) that aren't earning their place are the practical fixes, roughly in that order of impact.

For CLS: set explicit width and height attributes on every image, video, and embed so the browser reserves the space before the file loads, instead of resizing the layout once it arrives. Never insert new content (a cookie banner, an ad, a promotional bar) above content that's already visible; insert it below, or reserve the space for it from the start. Web fonts are a quieter cause of the same problem: if a custom font swaps in after a fallback font has already rendered the text, headlines and paragraphs can reflow and shift everything below them, which preloading the font file or setting font-display: optional both prevent.

A rough check before you open any tool

Before running a single report, three questions catch most of what's wrong without any software. Does the page feel like it loads instantly on a phone with a weak signal, not just on office wifi? Does tapping a menu, a filter, or an "add to cart" button respond the instant you touch it, or is there a beat where nothing happens? And does anything on the page move after you've already started reading it, a banner, an image, a cookie notice sliding in late? A page that fails any of those three, felt rather than measured, will almost always fail the matching metric once you do open Search Console or PageSpeed Insights. The tools exist to quantify and prioritize the fix, not to discover that a problem exists in the first place. That's also the right order to work in: fix what's obviously broken by feel first, then use the report to confirm it moved the number and to catch the smaller issues that aren't obvious from just using the site.

Where this connects to AI search

AI crawlers hit the same technical reality a slow or unstable page creates for a human visitor: content that loads late, behind heavy client-side JavaScript, or that shifts around during rendering is harder to parse reliably, whether the reader is a person or a model. It's the same reason a GEO audit checks whether a site is server-rendered rather than delivered as a client-side JavaScript shell, alongside the Core Web Vitals work covered here. Fixing page speed and stability is good SEO and good GEO for the same underlying reason: a page that loads clean and holds still is easier for anything, human or machine, to read correctly.

Core Web Vitals sit alongside the rest of a site's technical foundation. For the other half of that foundation, see how internal linking tells Google which pages matter and how to write a meta description that survives truncation. If you're working through this as part of a broader small business SEO pass rather than one metric at a time, the full checklist is the place to start.