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 are the floor, not the ceiling. 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 do not 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. But they were worth paying attention to before Google made them official, because each one is a direct reading of visitor frustration.
The wait at the door
Largest Contentful Paint, or LCP, measures how long it takes for the biggest meaningful element on the screen, usually a banner image or the opening block of text, to appear. It is 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 are 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 formats like JPG when WebP does the same job at a fraction of the weight. Behind that comes the server itself, because a host that takes two seconds to send the first byte has already spent your budget before your page loads a single pixel. And behind that come render-blocking resources, the CSS and JavaScript files a browser must download and process before it will paint anything at all. Themes stitched together from frameworks nobody audits are reliable factories for this last category.
The ignored question
Interaction to Next Paint, or INP, measures the gap between the moment a visitor taps a menu, clicks a button, or types in a form and the moment the page visibly responds. It replaced an older metric called First Input Delay, and it is the stricter of the two, because 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 have 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 is the closest a website comes to being yelled at.
The moving shelf
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 have 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 is an annoyance. On a checkout page it is a mis-clicked button with consequences.
The causes are almost embarrassingly fixable. Images and embeds published without height and width attributes, so the browser cannot 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 is 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 cannot tell you how real visitors experienced the site, but it can name the specific 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. And GTmetrix is the microscope: its waterfall chart displays every file the page loads, in sequence, with timings, so 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, because if the host takes more than about 600 milliseconds to respond, no on-page fix will rescue you, and the answer is caching, a CDN, or better hosting. After that, defer the CSS and JavaScript that block rendering.
A failing INP is 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 earning its delay? Remove what is 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.
A failing CLS is the most mechanical fix of the three. 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 does not 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 is where the real damage lives. A slow LCP sends visitors bouncing back to the search results within seconds, and Google reads that pattern as a page that failed to satisfy the query, then demotes it over time. Your content earned the click. The vitals decide whether the click survives long enough to count.
There is 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 do not execute JavaScript at all. They fetch the raw HTML, take what is 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, and a page that only exists after JavaScript runs may as well be blank. 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 is the exact thing answer engines need to ingest you. Fix the vitals for your visitors and you get AEO readiness as a side effect.
Speed is a practice, not a project
The tune-up framing gets one thing wrong. A site audited to green today will drift back toward red on its own, because 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 not the ones that got fixed once. They are the ones where somebody asks, before each addition, what it will cost, and checks the numbers after, the same way security holds up as a posture, not a product. 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 are usually the cheapest win, then interrogate every script that is not earning its delay. The rest of the guides in this cluster live 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.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.