Core Web Vitals get treated like a solved problem by a lot of site owners: pass the three checks in PageSpeed Insights once, screenshot the green scores, move on. That was never quite right even for classic search ranking, and it's even less complete now that AI crawlers are fetching the same pages on their own schedules, with their own limits on how much of a site they'll bother to read in one pass. Speed isn't just a user-experience metric anymore — it's also, functionally, a crawl-budget metric, and the two audiences don't always reward the same fixes the same way.
By the iSuggest.ai Team · Updated for 2026
The metric that actually changed
First Input Delay was retired and replaced by Interaction to Next Paint back in March 2024, and plenty of sites still haven't re-checked their numbers against it. INP measures the full round trip of an interaction — from click or tap to the next frame the browser actually paints — across the whole page visit, not just the first click. A page can pass the old FID threshold easily and still show a mediocre INP score if a heavy script keeps the main thread busy every time someone opens a menu or filters a table further down the page. Alongside Largest Contentful Paint (target: 2.5 seconds or under) and Cumulative Layout Shift (target: 0.1 or under), INP (target: 200 milliseconds or under) is the current field-data trio Google actually reports in Search Console and the Chrome UX Report. If your last speed audit predates that switch, the numbers you're looking at aren't measuring what you think they are.
Still a ranking factor, still not the biggest one
It's worth saying plainly: Core Web Vitals are one signal among many, and a fast page with thin, unhelpful content will not outrank a slower page that actually answers the query well. Google has said this consistently, and nothing about the AI-search shift changes it. What has changed is the cost of ignoring speed entirely. As we covered in why page speed still matters for AI search, a slow page doesn't just rank slightly lower — in enough cases it fails to render in time for a crawler to see the content at all, which is a much bigger problem than a ranking penalty.
The part most speed advice skips: crawl budget
Every crawler — Googlebot, Bingbot, and the AI crawlers like GPTBot, ClaudeBot and Google-Extended that we cover in our look at how AI crawlers actually work — operates with a finite amount of time and server load it's willing to spend on any given site in a given window. Google has documented this directly for its own crawler: slow response times and large page weights reduce how many URLs get crawled per visit, because the crawler is politely throttling itself against your server's ability to keep up. There's no public equivalent dashboard showing exactly how GPTBot or ClaudeBot allocate their own crawl budgets, and it would be overstating the evidence to claim identical numeric thresholds apply to each of them. But the underlying constraint is the same kind of problem: a bot with a fixed time window to spend on your domain will get through fewer of your pages if every fetch is slow, regardless of whose bot it is.
Why this compounds for larger sites
A single slow page is an annoyance. A site where every template is slow is a site where a crawler — human-facing or AI — systematically sees less of what you've published per visit. That matters more as a site grows past a handful of pages, because crawl time gets spread thinner across more URLs. It's part of why our own audit looks at real page-load behavior rather than just checking that a page returns a 200 status: a page that's technically reachable but slow to fully render is still a worse crawl target than one that responds fast, even if a human visitor barely notices the difference on a good connection.
What's actually worth fixing first
In practice, the highest-leverage fixes are rarely exotic: compress and correctly size images (even though the post carrying them shouldn't — we don't ship images in our own blog for exactly this kind of overhead reason), defer non-critical JavaScript instead of blocking the main thread on page load, reserve space for elements that load late so they don't shift content around after paint, and check server response time (TTFB) before anything else, since no amount of front-end optimization fixes a slow origin server. None of this requires a rebuild — it requires knowing which of the three metrics is actually failing on your real pages, which is different from assuming based on how the site feels in your own browser on a fast connection.
Check it on your own pages
Lab data and field data disagree often enough that guessing is a bad strategy. Run a free audit at iSuggest.ai to see where your actual pages stand, or check the reports already sitting in your account if you've audited before. Core Web Vitals were never just a Google Search checkbox — they're now also a rough proxy for how much of your site any crawler, human or AI, is actually willing to sit through in one visit.