Median ttfb: most-cited vs least-cited domains . 804 vs 910 ms.
The most-cited domains answer the server faster: a median time-to-first-byte of 804 ms for cited 10+ times, versus 910 ms for pages cited once or twice. Slow server response is associated with fewer citations, though the difference is modest.
Server response time (TTFB) vs citation frequency
Grouping every cited domain by how many of AmICited’s tracked-prompt responses cited it, and joining Google’s real-user Core Web Vitals data, a consistent pattern appears across the tiers. Cited 10+ times (659 domains with data) sit at one end and cited 1–2 times (4,313 domains) at the other. The direction is the same for every health metric we can measure — pass rate, server response time , and performance score — which is why the (modest) signal is credible rather than noise.
The underlying numbers
| Citation frequency | Domains w/ CrUX data | Pass Core Web Vitals | Median TTFB | Avg perf score |
|---|---|---|---|---|
| Cited 10+ times | 659 | 60% | 804 ms | 76.5 |
| Cited 3–9 times | 1,584 | 58% | 893 ms | 74.9 |
| Cited 1–2 times | 4,313 | 57% | 910 ms | 74.9 |
What this means for AI search visibility
Technically healthy pages are cited somewhat more often, but the effect here is small — site health looks like a supporting factor, not a primary driver of whether AI engines cite you. Content relevance almost certainly matters more (see the source- and topic-level reports). The practical read: fixing Core Web Vitals and server response time is worth doing — it removes a mild headwind and helps users regardless — but it will not, on its own, move you into an engine’s cited sources. Treat it as table stakes, then compete on relevance.
Why TTFB is the most important speed metric for AI citations
Among all the performance metrics we analyzed, Time to First Byte shows the largest absolute gap between the most- and least-cited domains: 106 milliseconds (804 ms vs. 910 ms). This is not a coincidence. TTFB is the metric most directly tied to server-side performance — the very thing that AI crawlers interact with when they fetch your pages.
When an AI crawler like GPTBot requests a page, it does not care about your hero image, your CSS animations, or your JavaScript bundle. It cares about one thing: how quickly can it get the HTML content it needs to extract text and determine relevance. A slow TTFB means the crawler is waiting — and if it waits too long, it may time out, fetch only a partial response, or deprioritize your domain for future crawls.
The 106 ms gap is modest in absolute terms — it is about the time it takes to blink — but it is consistent across thousands of domains and tracks in the expected direction. The most plausible mechanism is a crawl-efficiency effect: faster servers get crawled more completely and more often, which means their content is more fully represented in the retrieval indices that AI engines query. This is not proven causation, but it is the most coherent explanation for why TTFB shows the strongest performance signal.
How TTFB compares to other performance metrics
Unlike front-end metrics like LCP , FCP, and CLS , TTFB is almost entirely under the site owner’s control. It depends on:
- Server infrastructure: The quality and location of your hosting
- CDN configuration: Whether you use a CDN and how it is configured
- Caching strategy: Whether your pages are served from cache or generated dynamically
- Backend efficiency: How quickly your CMS or application server generates HTML
This makes TTFB the most actionable metric for AI-visibility performance work. Improving LCP might require redesigning your page layout; improving TTFB can often be done with configuration changes alone. The gap between 910 ms and 804 ms is achievable for most sites with a CDN and basic server-side caching — and our data suggests that closing that gap is the single most impactful performance optimization you can make for AI visibility .
What a “good” TTFB looks like for AI visibility
Google considers a TTFB under 800 ms to be “good.” The most-cited domains in our dataset sit right at that threshold (804 ms median). This suggests that the practical target for AI visibility is not some elite sub-200 ms TTFB, but simply being in the “good” range — under 800 ms.
If your TTFB is currently above 1,000 ms, you are likely experiencing some degree of crawl friction. AI crawlers operate under time budgets, and a server that takes over a second to respond will lose some fraction of crawl attempts to timeouts. Getting under 1,000 ms should be your first milestone; getting under 800 ms puts you in the company of the most-cited domains.
Practical recommendations
Measure your TTFB from multiple geographic locations. Your TTFB will vary depending on where the request originates. AI crawlers may fetch from data centers in different regions than your human visitors. Use a tool like KeyCDN’s Performance Test or WebPageTest to measure from multiple locations.
Enable full-page caching. If your pages are dynamically generated on every request, your TTFB will be high. A caching layer (Redis, Varnish, or your CMS’s built-in cache) can reduce TTFB from 500+ ms to under 50 ms for cached pages.
Use a CDN with edge caching. A CDN serves your content from locations close to the requester, cutting network latency. Even a basic CDN configuration (Cloudflare, Fastly, CloudFront) can reduce TTFB by 100–300 ms.
Upgrade your hosting if necessary. Shared hosting plans often have TTFB in the 1,000–2,000 ms range. Moving to a VPS or dedicated server, or a managed hosting platform, can be a step-change improvement.
Methodology
This is an association among the pages AI already cites, not proof of cause: it is computed by joining Google CrUX / PageSpeed field data to how often each domain was cited across AmICited’s 1,905 tracked prompts. CrUX data was available for 6,556 of 8,845 cited domains (74%). Domains are grouped into how many responses cited them; within each group we average the site-health metric. A domain “passes Core Web Vitals” when the majority of its audited URLs pass Google’s LCP/INP /CLS thresholds in real-user (CrUX) data; TTFB and performance score are averaged likewise. Pages without sufficient CrUX data are excluded. Because AmICited’s prompts skew toward SaaS , e-commerce and support topics, these figures describe the sites cited for that kind of query. The relationship is real but modest, and correlational — we are not claiming faster pages cause more citations.
