Walk into any well-run store and three things happen without you noticing them.
The door opens and the shelves are right there, stocked and visible. When you ask a question, someone answers. And when you reach for a product, the shelf holds still. Nobody praises a store for these things, because they’re the bare minimum. You only notice when they fail.
Websites fail at all three constantly, and in 2021 Google decided to start measuring the failures. The measurements are called Core Web Vitals: three numbers that quantify how a page feels to the person using it. The vitals don’t measure how a page scores on an abstract checklist. They measure how long a visitor stares at a blank screen, how long the page ignores their tap, and how often the content lurches out from under their finger.
The numbers feed into search rankings, so the industry pays attention to them now. I wish it had paid attention sooner.
Site owners spend months polishing their content and then bury it under a page that makes people wait, and I think that’s among the most wasteful mistakes on the web. Each of these three numbers is a reading of how annoyed a real visitor got, and they were worth watching long before Google made them official.
What does Largest Contentful Paint measure?
Largest Contentful Paint, or LCP, measures how long the biggest meaningful element on the screen takes to appear. Usually that’s a banner image or the opening block of text. It’s the digital equivalent of the time between walking in and seeing the shelves. Google considers anything under two and a half seconds good. Beyond four, you’re losing people.
The causes are rarely mysterious. Oversized images top the list. Photographs uploaded straight from a camera, at dimensions no screen will ever display, in JPG when WebP does the same job at a fraction of the weight. Behind that comes the server itself. A host that takes two seconds to send the first byte has spent your budget before the page loads a single pixel.
The oversized photograph is the worst offender. Nobody needs a camera-sized image to show a headshot, and the cost lands on the visitor with the slowest phone and the weakest signal, the person you most need to win over. The site owner never sees it because the site owner tests the page on a fast laptop sitting next to the router.
And behind that come render-blocking resources, the CSS and JavaScript files a browser must download and process before it’ll paint anything at all. Themes stitched together from frameworks nobody audits are reliable factories for this last category.
What does Interaction to Next Paint measure?
Interaction to Next Paint, or INP, measures one gap.
The visitor taps a menu, clicks a button, or types in a form, and INP counts until the page visibly responds. It replaced an older metric called First Input Delay, and it’s the stricter of the two. It watches every interaction on the page instead of only the first. Under 200 milliseconds feels instant. Above half a second feels broken.
A poor INP has one root cause wearing many costumes: JavaScript doing too much work on the browser’s main thread.
Sometimes the script belongs to the site, a bloated theme or a page builder dragging its entire toolbox to every page. More often it belongs to someone else: analytics trackers, social media widgets, chat bubbles, heat maps, each one added in an optimistic afternoon and none ever removed. Every third-party script is a stranger you’ve invited to stand between your visitor and your page.
Trimming them is the same discipline as trimming plugins, and it pays the same dividend.
The visible symptom of bad INP is the rage click: a visitor taps, nothing happens, so they tap again, and again, harder. Watch a session recording of one sometime. It’s the closest a website comes to being yelled at.
I blame the people who keep bolting scripts onto a site for this, and I don’t blame the visitor who gives up. Every marketing tool promises a little more insight, and nobody adding one asks what it does to the person trying to tap a menu. That person decides your business doesn’t work and goes somewhere else.
What does Cumulative Layout Shift measure?
Cumulative Layout Shift, or CLS, measures visual stability, how much the page jumps around while it loads.
This is the shelf that drops six inches just as the customer’s hand arrives. You’ve felt it: you go to tap a link, a late-loading ad shoves everything down, and you tap something else entirely. On a news site it’s an annoyance. On a checkout page it’s a mis-clicked button with consequences.
The causes are almost embarrassingly fixable. Images and embeds published without height and width attributes, so the browser can’t reserve space for them and reflows the page when they finally arrive. Ads and banners injected above existing content. Cookie notices that arrive late and push everything else out of position.
Fonts that swap after the text has rendered. None of this requires genius to repair. It requires someone to look.
How do you check your Core Web Vitals?
Diagnosis starts with knowing that there are two kinds of data, and that they answer different questions. Field data is what happened to your real visitors. Google collects it from Chrome users over a rolling 28-day window, and it’s the accumulated testimony of every person who visited on a mid-range phone over hotel wi-fi. Lab data comes from controlled tests run against your page in a consistent simulated environment.
It can’t tell you how real visitors experienced the site, but it can name the files, scripts, and images consuming the time. Field data is the patient’s symptoms. Lab data is the blood work.
Three free tools cover the whole investigation, and they work best in a fixed order.
Google Search Console is the verdict. Its Core Web Vitals report shows your field data grouped by URL, so you can see which pages fail, on which metric, on which device. Start there, because it tells you whether you have a problem at all. PageSpeed Insights is the bridge: it shows the same field data next to a fresh lab test of the page, along with Google’s own list of suspected causes.
GTmetrix is the microscope. Its waterfall chart shows every file the page loads, in sequence, with timings. You can see the exact image, script, or server delay eating your budget. Search Console tells you that something is wrong. PageSpeed Insights tells you why. GTmetrix tells you which file.
How do you fix a failing Core Web Vital?
A failing LCP almost always yields to the same sequence.
Compress your images and convert them to WebP. Preload the hero image so the browser fetches it first. Then check your server’s time to first byte. If the host takes more than about 600 milliseconds to respond, no on-page fix will rescue you. The answer is caching, a CDN, or better hosting. After that, defer the CSS and JavaScript that block rendering.
When INP fails, it’s a JavaScript problem wearing different labels. Pull up the waterfall, find the scripts that occupy the main thread longest, and interrogate each one: is this chat widget, heat map, or social embed worth its delay? Remove what’s not. Defer what remains. Then look at the plugin stack, because every plugin that loads a script on every page adds to the tab whether the page uses it or not.
Of the three, a failing CLS is the most mechanical fix. Give every image and embed explicit width and height attributes so the browser reserves the space before the file arrives. Reserve fixed space for ads and banners. Never inject cookie notices or promotions above existing content. And configure font loading so text doesn’t reflow when the real typeface replaces the fallback.
Why SEO cares
Google has confirmed the vitals are a ranking signal, but keep the direct effect in proportion: it works as a tie-breaker. When two pages answer a query about equally well, the faster and more stable one takes the better position, and a fast site will never outrank a better answer. The indirect effect does more damage.
A slow LCP sends visitors bouncing back to the search results within seconds. Google reads that pattern as a page that failed to satisfy the query, and demotes it over time. Your content won the click. The vitals decide whether the click survives long enough to count.
I get frustrated watching people argue over whether the vitals are a big ranking factor, because the argument misses the damage. A page that bleeds visitors in the first few seconds never gets the chance to prove its content was good, and the writer who worked hard on that content loses the reader before the first sentence.
There’s a quieter cost too. A slow server shrinks your crawl budget, meaning Googlebot fetches fewer of your pages per visit. On a site with hundreds of posts, that translates to new content indexing later and updates taking longer to register, an invisible tax, collected at the same crawl gate robots.txt guards, paid on everything else you do to earn visibility.
Why do Core Web Vitals matter for AEO?
Search engines are no longer the only readers that matter. AI answer engines send their own crawlers, GPTBot, ClaudeBot, PerplexityBot and their kin, and those crawlers are less patient and less capable than Googlebot. Most of them don’t execute JavaScript at all. They fetch the raw HTML, take what’s there, and move on.
Follow that to its conclusion. The same root causes behind bad vitals, slow server response, render-blocking scripts, content assembled in the browser by JavaScript, do worse than slow the page for these crawlers. They can make your content invisible to them. A server that takes six seconds to respond can hit a fetch timeout and never enter the retrieval corpus. A page that only exists after JavaScript runs may as well be blank.
This part worries me more than the rankings. A small business can do everything right with its content and still never show up in an AI answer because its server was too slow for a crawler that won’t wait. The owner gets no error message and no warning. The business is simply missing from the answer, and nobody tells them why.
Either way, you never get cited in an AI answer, and being the source the answer engines quote is where a growing share of visibility now comes from. CLS means nothing to a bot, but fixing LCP and INP means shipping fast, complete, server-rendered HTML, and that’s the exact thing answer engines need to ingest you. Fix the vitals for your visitors and you get AEO readiness as a side effect.
Why do fast websites drift back to slow?
The tune-up framing gets one thing wrong. A site audited to green today drifts back toward red on its own.
Every new plugin, tracking script, and full-resolution photograph is a small withdrawal from the performance budget, and nobody ever files the paperwork. The sites that stay fast are the ones where somebody asks, before each addition, what it’ll cost, and checks the numbers after, the same way security holds up as a posture you keep practicing.
The habits even rhyme: fewer components, chosen deliberately, watched continuously.
So run the diagnosis on your own site this week. Open Search Console, read the field data, and let the lab tools name the culprits. Fix the images first, they’re usually the cheapest win, then interrogate every script that’s not worth its delay. The rest of the guides in this cluster are in the Technology of Writing Hub. Or hand the practice to someone who does it every day.
Either way, remember what the numbers are standing in for: a person on a phone deciding in the first three seconds whether you run the kind of store that makes them wait at the door. I think a slow site is a quiet insult to that person, and I’d rather see an owner cut half the plugins on the site than keep making customers pay for decorations nobody asked for.
