Median ttfb: mest citerede vs. mindst citerede domæner . 804 vs. 910 ms.
De mest citerede domæner svarer hurtigere fra serveren: en median time-to-first-byte på 804 ms for dem, der er citeret 10+ gange, mod 910 ms for sider, der er citeret én eller to gange. Langsom serverrespons hænger sammen med færre citationer, omend forskellen er beskeden.
Serverrespons tid (TTFB) vs. citationsfrekvens
Ved at gruppere alle citerede domæner efter, hvor mange af AmICiteds overvågede prompt-svar der citerede dem, og sammenkoble Googles data om reelle brugeres Core Web Vitals , fremkommer et konsekvent mønster på tværs af trinene. Citeret 10+ gange (659 domæner med data) ligger i den ene ende, og citeret 1–2 gange (4.313 domæner) i den anden. Retningen er den samme for alle sundhedsmetrikker, vi kan måle — beståelsesrate, server respons tid og præstationsscore — hvilket er grunden til, at det (beskedne) signal er troværdigt frem for støj.
De underliggende tal
| Citationsfrekvens | Domæner m. CrUX-data | Består Core Web Vitals | Median TTFB | Gennemsn. perf. score |
|---|---|---|---|---|
| Citeret 10+ gange | 659 | 60 % | 804 ms | 76,5 |
| Citeret 3–9 gange | 1.584 | 58 % | 893 ms | 74,9 |
| Citeret 1–2 gange | 4.313 | 57 % | 910 ms | 74,9 |
Ready to Monitor Your AI Visibility?
Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.
Hvad dette betyder for AI-søgningssynlighed
Teknisk sunde sider bliver citeret noget oftere, men effekten her er lille — site-sundhed ligner en understøttende faktor, ikke en primær drivkraft for, om AI-motorer citerer dig. Indholdsrelevans er næsten helt sikkert vigtigere (se rapporterne på kilde- og emneniveau). Den praktiske pointe: at rette op på Core Web Vitals og serverrespons tid er værd at gøre — det fjerner en mild modvind og hjælper brugere uanset hvad — men det vil ikke i sig selv flytte dig ind i en motors citerede kilder. Betragt det som adgangsbilletten, og konkurrér så på relevans.
Hvorfor TTFB er den vigtigste hastighedsmetrik for AI-citationer
Blandt alle de præstationsmetrikker, vi analyserede, viser Time to First Byte det største absolutte gab mellem de mest og mindst citerede domæner: 106 millisekunder (804 ms vs. 910 ms). Dette er ikke en tilfældighed. TTFB er den metrik, der er mest direkte forbundet med server-side ydeevne — præcis det, AI-crawlere interagerer med, når de henter dine sider.
Når en AI-crawler som GPTBot anmoder om en side, er den ligeglad med dit hero-billede, dine CSS-animationer eller din JavaScript-bundle. Den bekymrer sig om én ting: hvor hurtigt kan den få det HTML indhold, den har brug for, for at udtrække tekst og vurdere relevans. En langsom TTFB betyder, at crawleren venter — og hvis den venter for længe, kan den time ud, kun hente et delvist svar eller nedprioritere dit domæne til fremtidige crawl.
Forskellen på 106 ms er beskeden i absolutte termer — det er omtrent den tid, det tager at blinke — men den er konsekvent på tværs af tusindvis af domæner og følger den forventede retning. Den mest sandsynlige mekanisme er en crawl-effektivitetseffekt: hurtigere servere bliver crawlet mere fuldstændigt og oftere, hvilket betyder, at deres indhold er bedre repræsenteret i de retrieval-indekser, AI-motorer forespørger på. Dette er ikke bevist årsagssammenhæng, men det er den mest sammenhængende forklaring på, hvorfor TTFB viser det stærkeste præstationssignal.
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
Hvordan TTFB sammenlignes med andre præstationsmetrikker
I modsætning til frontend-metrikker som LCP , FCP og CLS , er TTFB næsten udelukkende under site-ejerens kontrol. Det afhænger af:
- Serverinfrastruktur: Kvaliteten og placeringen af din hosting
- CDN-konfiguration: Om du bruger et CDN, og hvordan det er konfigureret
- Cachingstrategi: Om dine sider serveres fra cache eller genereres dynamisk
- Backend-effektivitet: Hvor hurtigt dit CMS eller din applikationsserver genererer HTML
Dette gør TTFB til den mest handlingsorienterede metrik for AI-synlighedsarbejde. Forbedring af LCP kan kræve redesign af dit sidelayout; forbedring af TTFB kan ofte gøres med konfigurationsændringer alene. Forskellen mellem 910 ms og 804 ms er opnåelig for de fleste sites med et CDN og grundlæggende server-side caching — og vores data tyder på, at at lukke det gab er den enkeltstående mest effektfulde præstationsoptimering, du kan foretage for AI-synlighed .
Hvordan en “god” TTFB ser ud for AI-synlighed
Google anser en TTFB under 800 ms for at være “god.” De mest citerede domæner i vores datasæt ligger lige ved den grænse (804 ms median). Dette tyder på, at det praktiske mål for AI-synlighed ikke er en elite TTFB på under 200 ms, men blot at være i det “gode” område — under 800 ms.
Hvis din TTFB i øjeblikket er over 1.000 ms, oplever du sandsynligvis en vis grad af crawl-friktion. AI-crawlere arbejder under tidsbudgetter, og en server, der tager over et sekund at svare, vil miste en vis andel af crawl-forsøg til timeouts. At komme under 1.000 ms bør være din første milepæl; at komme under 800 ms placerer dig i selskab med de mest citerede domæner.
Praktiske anbefalinger
Mål din TTFB fra flere geografiske placeringer. Din TTFB vil variere afhængigt af, hvor forespørgslen kommer fra. AI-crawlere kan hente fra datacentre i andre regioner end dine menneskelige besøgende. Brug et værktøj som KeyCDN’s Performance Test eller WebPageTest til at måle fra flere placeringer.
Aktivér fuldside-caching. Hvis dine sider genereres dynamisk ved hver forespørgsel, vil din TTFB være høj. Et caching-lag (Redis, Varnish eller dit CMS’ indbyggede cache) kan reducere TTFB fra 500+ ms til under 50 ms for cachelagrede sider.
Brug et CDN med edge-caching. Et CDN leverer dit indhold fra placeringer tæt på anmoderen, hvilket reducerer netværkslatens. Selv en grundlæggende CDN-konfiguration (Cloudflare, Fastly, CloudFront) kan reducere TTFB med 100–300 ms.
Opgrader din hosting om nødvendigt. Delte hostingplaner har ofte TTFB i området 1.000–2.000 ms. At skifte til en VPS eller dedikeret server, eller en administreret hostingplatform, kan være en markant forbedring.
Metode
Dette er en sammenhæng blandt de sider, AI allerede citerer, ikke et bevis på årsag: det beregnes ved at sammenkoble Google CrUX / PageSpeed feltdata med, hvor ofte hvert domæne blev citeret på tværs af AmICiteds 1.905 overvågede prompts. CrUX-data var tilgængelige for 6.556 af 8.845 citerede domæner (74 %). Domæner grupperes efter, hvor mange svar der citerede dem; inden for hver gruppe beregner vi gennemsnittet af sundhedsmetrikken. Et domæne “består Core Web Vitals”, når flertallet af dets reviderede URL’er består Googles LCP/INP /CLS-tærskler i data fra reelle brugere (CrUX); TTFB og præstationsscore beregnes tilsvarende. Sider uden tilstrækkelige CrUX-data udelades. Fordi AmICiteds prompts hælder mod SaaS , e-handel og supportemner, beskriver disse tal de sites, der citeres til den type forespørgsler. Sammenhængen er reel, men beskeden og korrelationel — vi påstår ikke, at hurtigere sider forårsager flere citationer.
