Is this the same as Core Web Vitals?

No, and the difference matters. This measures server response time (also called TTFB, time to first byte): purely how long the server takes to start sending a reply, with no browser involved at all. Core Web Vitals measure what happens after that, in a real or simulated browser, including rendering and script execution. A page can be flagged here and still pass Core Web Vitals, or the reverse, because they measure different stages of the same page load. See Core Web Vitals Explained for that separate set of metrics.

It is a generous ceiling deliberately set well above Google's own healthy-TTFB guidance (under 0.8 seconds), so a flagged page is unambiguously slow rather than borderline. A page can still be worth optimising below 3 seconds; this check exists to catch the pages that are clearly a problem, not to enforce a tight budget.

Does this measure my whole page load?

No. It measures only the time to receive the very first byte of the server's response, before the browser has downloaded a single image, script or stylesheet, let alone rendered anything. A page can pass this check and still load slowly overall if the images or scripts after it are heavy; response time is a floor on load time, not the whole of it.

Does this run on every crawl?

Yes, on any page the crawler fetches. Response time is measured as part of the crawler's own request, so it costs nothing extra and needs no separate field-data connection, unlike Core Web Vitals.

Slow Server Response Time On a Crawled Page

Before a browser can render anything, download an image, or run a script, it has to wait for the server to start sending a response at all. That wait, server response time, is a hard floor under everything a visitor experiences next.

What this finding means

Crawl Cove's slow-response check reads the response time already recorded on every fetched HTML page, no extra request needed, and flags any page whose server took longer than 3 seconds to start responding.

A real finding looks like this:

server response took 4820ms (threshold 3000ms)

This is measured as the crawler's own fetch: no JavaScript execution, no subresources, no rendering. It is server latency, sometimes called time to first byte (TTFB), which is a floor on how fast a page can possibly appear, not a measurement of the full page load.

Why it matters

A slow server response delays everything that follows it: the browser cannot start rendering, downloading images, or running scripts until the first byte arrives. Google measures this directly as part of how a page's real-world performance is judged, and a visitor who has waited several seconds for anything to appear at all has often already left before your content ever gets the chance to render.

How to fix it

Confirm the finding on the actual page, since server response time can vary with load; a repeat check under normal traffic conditions rules out a one-off spike.
Look for the usual causes: an uncached database query running on every request, a slow or overloaded origin server, or server-side rendering work that could be cached or precomputed.
Add or improve caching at the application, page, or CDN/edge level so repeat requests do not repeat the slow work.
Consider upgrading hosting if the origin itself is under-resourced for the traffic it serves.
Re-crawl the page to confirm the response time has dropped under the threshold.

False positives and edge cases

Only HTML pages are measured. A non-HTML resource such as a sitemap or a feed is not "a page" a visitor waits on in this sense, and is out of scope.
This is server latency only, not full page load. A page can clear this check and still load slowly overall if what comes after the first byte, such as large images or render-blocking scripts, is heavy. It can also fail this check while otherwise being lightweight, if the server itself is the bottleneck.
A single slow crawl under unusual load is possible. Response time reflects conditions at crawl time; a page flagged once is worth confirming with a second crawl before assuming it is a permanent problem.

Frequently asked questions

Is this the same as Core Web Vitals?: No, and the difference matters. This measures server response time (also called TTFB, time to first byte): purely how long the server takes to start sending a reply, with no browser involved at all. Core Web Vitals measure what happens after that, in a real or simulated browser, including rendering and script execution. A page can be flagged here and still pass Core Web Vitals, or the reverse, because they measure different stages of the same page load. See Core Web Vitals Explained for that separate set of metrics.
Why 3 seconds?: It is a generous ceiling deliberately set well above Google's own healthy-TTFB guidance (under 0.8 seconds), so a flagged page is unambiguously slow rather than borderline. A page can still be worth optimising below 3 seconds; this check exists to catch the pages that are clearly a problem, not to enforce a tight budget.
Does this measure my whole page load?: No. It measures only the time to receive the very first byte of the server's response, before the browser has downloaded a single image, script or stylesheet, let alone rendered anything. A page can pass this check and still load slowly overall if the images or scripts after it are heavy; response time is a floor on load time, not the whole of it.
Does this run on every crawl?: Yes, on any page the crawler fetches. Response time is measured as part of the crawler's own request, so it costs nothing extra and needs no separate field-data connection, unlike Core Web Vitals.