Google calls a TTFB under 800ms good. For a crawler working to a timeout, 800ms is already marginal. We check TTFB, CLS and INP against thresholds set for machine retrieval, using real-user data from the Chrome UX Report.
Assistants fetch several sources in parallel and work to a deadline. Whatever has not arrived by then is not in the answer — there is no second pass, and no ranking penalty to appeal.
Your page was fine. Your content was relevant. It just arrived after the answer was already written — and nothing in your analytics will ever show you that this happened.
Time to First Byte is how long your server takes to start answering. It is the single strongest signal we measure, because everything else only matters once the fetch succeeds.
Most tools present these as a row of three tiles. They do not carry the same weight, so we do not show them that way.
How long your server takes to begin responding. This is the one that determines whether an AI system gets your content at all — systems fetching several sources under a time budget process the fast ones first, and drop what is still pending. Every other metric on this page assumes the fetch already succeeded.
CLS < 0.1Pages whose layout jumps around while loading tend to be brittle to parse. Anything reading the page structure can capture the wrong thing, or miss content that moved after it looked.
INP < 200msMatters when an AI agent is operating your site rather than reading it — filling a form, clicking through a flow. Largely irrelevant for read-only crawlers, and we say so rather than inflating it.
days of real-visitor data behind every reading, not a single lab run
metrics graded per page, on desktop and mobile separately
the line where being skipped for a faster source starts to matter
Run the check on any URL. You get your TTFB grade on desktop and mobile, the layout and interaction readings alongside it, and what to fix first.
Because it is. A system assembling an answer is fetching several candidate sources against a time budget and using whatever arrives in time. A slow server does not get an error — it gets left out of an answer that was already written without it.
TTFB, by a distance. It is the one that decides whether you are fetched at all. CLS and INP describe how stable and responsive the page is once it loads; they matter, but they are not why pages get skipped.
Real Chrome visitors, via the Chrome UX Report, whenever your page has enough of them. That is aggregated over weeks of actual visits on actual connections, which is why it disagrees with your own experience of the site.
Your browser has your site cached and you are probably near the server. Field data has neither advantage. If page-level data is thin we also show the origin average across your whole domain, and a slow origin usually points at hosting rather than at any one page.
It can. An uncached origin request is far slower than a warm edge response, so the first audit after a quiet period can land worse than the page deserves. If a grade looks out of character, run it again once the cache is warm — and if it does not move, the cache was not the reason.
CrUX needs a minimum number of real visits, so new and low-traffic pages have none. TTFB falls back to a live lab measurement taken during the audit, and the report says so. CLS and INP have no lab fallback — they only exist as field data, so on a quiet page they are simply absent.
No. TTFB stops the clock when the first byte arrives. Everything after that — images, scripts, fonts — is load time, and a crawler taking the raw HTML has already got what it came for.
Almost certainly an empty shell. A client-rendered app returns its HTML immediately, which is a great TTFB, and that HTML contains no content. Fast and empty is worse than slow and complete, because a crawler that fetched successfully has no reason to come back.
Caching, in most cases. Full-page caching at the edge, a CDN so responses come from somewhere near the visitor, and a look at whatever your server recomputes on every request. On shared hosting the fix is often just the hosting tier.
Yes. TTFB, CLS and INP are the same measurements Google uses, so this is the rare area where the work counts twice and nothing has to be re-done for AI specifically.