Does your server answer fast enough for a crawler?
Response time is within limits. A crawler that waits two seconds for the first byte may read half the page or give up.
What the check looks at
The check measures time to first byte on each priority page. Fetchers run with budgets; a slow first byte pushes a fetch toward a timeout and a truncated read.
Why it matters
A crawler that waits two seconds for the first byte may read half the page or give up. Partial fetches mean partial understanding — the opening gets read, the facts further down do not.
How to see it on your own site
curl -o /dev/null -w "%{time_starttransfer}" your page from a few locations. Under half a second is comfortable; over a second and a half is where fetchers start truncating.
How to fix it
- Cache HTML at the edge: a CDN serving a cached page answers in tens of milliseconds regardless of the origin.
- Fix the origin: slow database queries, uncached template rendering, a plugin that calls an API on every request.
- Measure after the fix from outside your network.
What the agent does: speed lives in your hosting; the agent reports the number per page and what it points at.
Related checks
Part of the 23 checks · group: Page content — text without JavaScript, response time, internal links, answer-first structure, self-contained sections, headings/dates/authorship.
Questions people ask
Is this the same as Core Web Vitals?
It is the first of them. Core Web Vitals measure the experience in a browser; a crawler only waits for bytes, so time to first byte is the one that matters here.
Start with the free check. Then tell the agent what you need.
The free check runs the 23 checks on your public pages. Nothing is installed, nothing changes until you press it.
Free check from outside in minutes · the report by email · nothing installed yet