Median-TTFB: mest citerade vs minst citerade domäner . 804 vs 910 ms.
De mest citerade domänerna svarar snabbare från servern: en median time-to-first-byte på 804 ms för de som citerats 10+ gånger, jämfört med 910 ms för sidor som citerats en eller två gånger. Långsam serversvar är kopplat till färre citeringar, även om skillnaden är måttlig.
Svarstid från server (TTFB) jämfört med citeringsfrekvens
Genom att gruppera varje citerad domän efter hur många av AmICiteds spårade prompt-svar som citerade den, och sammanfoga Googles verkliga användardata för Core Web Vitals , framträder ett konsekvent mönster över nivåerna. De som citerats 10+ gånger (659 domäner med data) ligger i ena änden och de som citerats 1–2 gånger (4 313 domäner) i den andra. Riktningen är densamma för varje hälsomått vi kan mäta — godkännandegrad, server-svarstid och prestandapoäng — vilket är anledningen till att den (måttliga) signalen är trovärdig snarare än brus.
De underliggande siffrorna
| Citeringsfrekvens | Domäner med CrUX-data | Godkända Core Web Vitals | Median TTFB | Genomsnittligt prestandapoäng |
|---|---|---|---|---|
| Citerade 10+ gånger | 659 | 60 % | 804 ms | 76,5 |
| Citerade 3–9 gånger | 1 584 | 58 % | 893 ms | 74,9 |
| Citerade 1–2 gånger | 4 313 | 57 % | 910 ms | 74,9 |
Vad detta betyder för AI-söksynlighet
Tekniskt välmående sidor citeras något oftare, men effekten här är liten — webbhälsa ser ut att vara en stödjande faktor, inte en primär drivkraft för om AI-motorer citerar dig. Innehållsrelevans är nästan säkert viktigare (se rapporterna på käll- och ämnesnivå). Den praktiska slutsatsen: att fixa Core Web Vitals och server-svarstid är värt att göra — det tar bort en mild motvind och hjälper användare oavsett — men det kommer inte på egen hand att flytta in dig i en motors citerade källor. Behandla det som en grundförutsättning och tävla sedan på relevans.
Varför TTFB är det viktigaste hastighetsmåttet för AI-citeringar
Bland alla prestandamått vi analyserat visar Time to First Byte det största absoluta gapet mellan de mest och minst citerade domänerna: 106 millisekunder (804 ms jämfört med 910 ms). Detta är ingen slump. TTFB är det mått som är mest direkt kopplat till serverprestanda — precis det som AI-genomsökare interagerar med när de hämtar dina sidor.
När en AI-genomsökare som GPTBot begär en sida bryr den sig inte om din hero-bild, dina CSS-animationer eller ditt JavaScript-paket. Den bryr sig om en sak: hur snabbt kan den få det HTML -innehåll den behöver för att extrahera text och avgöra relevans. En långsam TTFB innebär att genomsökaren väntar — och om den väntar för länge kan den timeouta, hämta endast ett partiellt svar, eller nedprioritera din domän för framtida genomsökningar.
Gapet på 106 ms är måttligt i absoluta termer — det är ungefär den tid det tar att blinka — men det är konsekvent över tusentals domäner och följer den förväntade riktningen. Den mest troliga mekanismen är en genomsökningseffektivitetseffekt: snabbare servrar genomsöks mer fullständigt och oftare, vilket innebär att deras innehåll är mer fullt representerat i de index som AI-motorer använder för hämtning. Detta är inte bevisat orsakssamband, men det är den mest sammanhängande förklaringen till varför TTFB uppvisar den starkaste prestandasignalen.
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
Hur TTFB jämförs med andra prestandamått
Till skillnad från frontend-mått som LCP , FCP och CLS ligger TTFB nästan helt under webbplatsägarens kontroll. Det beror på:
- Serverinfrastruktur: Kvaliteten och placeringen av din hosting
- CDN-konfiguration: Om du använder ett CDN och hur det är konfigurerat
- Caching-strategi: Om dina sidor serveras från cache eller genereras dynamiskt
- Backend-effektivitet: Hur snabbt ditt CMS eller din applikationsserver genererar HTML
Detta gör TTFB till det mest handlingsbara måttet för AI-synlighetsprestanda. Att förbättra LCP kan kräva omdesign av din sidlayout; att förbättra TTFB kan ofta göras med enbart konfigurationsändringar. Gapet mellan 910 ms och 804 ms är uppnåeligt för de flesta webbplatser med ett CDN och grundläggande server-side caching — och våra data tyder på att att överbrygga det gapet är den enskilt mest effektfulla prestandaoptimeringen du kan göra för AI-synlighet .
Vad en “bra” TTFB innebär för AI-synlighet
Google anser att en TTFB under 800 ms är “bra”. De mest citerade domänerna i vårt dataset ligger precis vid den tröskeln (804 ms median). Detta tyder på att det praktiska målet för AI-synlighet inte är någon elitmässig sub-200 ms TTFB, utan helt enkelt att ligga inom det “bra” intervallet — under 800 ms.
Om din TTFB för närvarande är över 1 000 ms upplever du sannolikt en viss grad av genomsökningsfriktion. AI-genomsökare arbetar under tidsbudgetar, och en server som tar över en sekund att svara kommer att förlora en del av genomsökningsförsöken till timeouter. Att komma under 1 000 ms bör vara din första milstolpe; att komma under 800 ms placerar dig i samma sällskap som de mest citerade domänerna.
Praktiska rekommendationer
Mät din TTFB från flera geografiska platser. Din TTFB varierar beroende på var förfrågan kommer ifrån. AI-genomsökare kan hämta data från datacenter i andra regioner än dina mänskliga besökare. Använd ett verktyg som KeyCDN:s Performance Test eller WebPageTest för att mäta från flera platser.
Aktivera fullsidscaching. Om dina sidor genereras dynamiskt vid varje förfrågan kommer din TTFB att vara hög. Ett cachelager (Redis, Varnish, eller ditt CMS inbyggda cache) kan minska TTFB från 500+ ms till under 50 ms för cachade sidor.
Använd ett CDN med edge-caching. Ett CDN serverar ditt innehåll från platser nära den som begär det, vilket minskar nätverkslatens. Även en grundläggande CDN-konfiguration (Cloudflare, Fastly, CloudFront) kan minska TTFB med 100–300 ms.
Uppgradera din hosting om nödvändigt. Delade hostingplaner har ofta TTFB i intervallet 1 000–2 000 ms. Att flytta till en VPS eller dedikerad server, eller en hanterad hostingplattform, kan vara en stegförbättring.
Metodik
Detta är ett samband bland de sidor som AI redan citerar, inte bevis på orsakssamband: det beräknas genom att sammanfoga Googles CrUX/PageSpeed-fältdata med hur ofta varje domän citerades i AmICiteds 1 905 spårade promptar. CrUX-data fanns tillgänglig för 6 556 av 8 845 citerade domäner (74 %) . Domäner grupperas efter hur många svar som citerade dem; inom varje grupp beräknas medelvärdet för webbhälso-måttet. En domän “godkänner Core Web Vitals” när majoriteten av dess granskade webbadresser passerar Googles LCP/INP /CLS-trösklar i verklig användardata (CrUX); TTFB och prestandapoäng beräknas på samma sätt. Sidor utan tillräcklig CrUX-data exkluderas. Eftersom AmICiteds promptar lutar mot SaaS , e-handel och supportämnen beskriver dessa siffror de webbplatser som citeras för den typen av frågor. Sambandet är verkligt men måttligt och korrelationellt — vi påstår inte att snabbare sidor orsakar fler citeringar.
