Reduserer en langsom Time-to-First-Byte (TTFB) sjansene for å bli sitert?

Median ttfb: mest siterte vs. minst siterte domener . 804 vs 910 ms.

De mest siterte domenene svarer raskere fra serveren: en median time-to-first-byte på 804 ms for de som siteres 10+ ganger, mot 910 ms for sider som siteres én eller to ganger. Langsom serverrespons er forbundet med færre siteringer, selv om forskjellen er beskjeden.

Serverresponstid (TTFB) vs. siteringsfrekvens

Serverresponstid (TTFB) vs. siteringsfrekvens

Ved å gruppere hvert siterte domene etter hvor mange av AmICiteds sporespørringer som siterte det, og sammenstille med Googles Core Web Vitals -data fra virkelige brukere, fremkommer et konsistent mønster på tvers av nivåene. Sitert 10+ ganger (659 domener med data) ligger i den ene enden, og sitert 1–2 ganger (4 313 domener) i den andre. Retningen er den samme for alle helsemålinger vi kan måle — beståttprosent, serverresponstid og ytelsesscore — noe som gjør det (beskjedne) signalet troverdig snarere enn støy.

De underliggende tallene

SiteringsfrekvensDomener med CrUX-dataBestår Core Web VitalsMedian TTFBGj.sn. ytelsesscore
Sitert 10+ ganger65960 %804 ms76,5
Sitert 3–9 ganger1 58458 %893 ms74,9
Sitert 1–2 ganger4 31357 %910 ms74,9
Logo

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Hva dette betyr for AI-søkesynlighet

Teknisk sunne sider siteres noe oftere, men effekten her er liten — nettstedshelse ser ut til å være en medvirkende faktor, ikke en primær drivkraft for om AI-motorer siterer deg. Innholdsrelevans er nesten helt sikkert viktigere (se rapportene på kilde- og emnenivå). Den praktiske tolkningen: å fikse Core Web Vitals og serverresponstid er verdt å gjøre — det fjerner en mild motvind og hjelper brukere uansett — men det vil ikke i seg selv flytte deg inn i en motors siterte kilder. Behandle det som en selvfølge, og konkurrer deretter på relevans.

Hvorfor TTFB er den viktigste hastighetsmålingen for AI-siteringer

Blant alle ytelsesmålingene vi analyserte, viser Time to First Byte det største absolutte gapet mellom de mest og minst siterte domenene: 106 millisekunder (804 ms vs. 910 ms). Dette er ingen tilfeldighet. TTFB er målingen som er mest direkte knyttet til ytelse på serversiden — akkurat det AI-søkeroboter samhandler med når de henter sidene dine.

Når en AI-søkerobot som GPTBot ber om en side, bryr den seg ikke om heltebildet ditt, CSS-animasjonene dine eller JavaScript-pakken din. Den bryr seg om én ting: hvor raskt kan den få HTML-innholdet den trenger for å hente ut tekst og vurdere relevans. En langsom TTFB betyr at søkeroboten venter — og hvis den venter for lenge, kan den tidsavbryte, hente kun et delvis svar, eller nedprioritere domenet ditt for fremtidige gjennomsøk.

Gapet på 106 ms er beskjedent i absolutte termer — det er omtrent tiden det tar å blunke — men det er konsistent på tvers av tusenvis av domener og følger forventet retning. Den mest sannsynlige mekanismen er en søkeeffektivitetseffekt: raskere servere gjennomsøkes mer fullstendig og oftere, noe som betyr at innholdet deres er mer fullt representert i gjenfinningsindeksene som AI-motorer spør mot. Dette er ikke bevist kausalitet, men det er den mest sammenhengende forklaringen på hvorfor TTFB viser det sterkeste ytelsessignalet.

Hvordan TTFB sammenlignes med andre ytelsesmålinger

I motsetning til frontend-målinger som LCP , FCP og CLS , er TTFB nesten fullstendig under nettstedseierens kontroll. Det avhenger av:

  • Serverinfrastruktur: Kvaliteten og plasseringen av din hosting
  • CDN-konfigurasjon: Om du bruker et CDN og hvordan det er konfigurert
  • Bufringsstrategi: Om sidene dine serveres fra bufrer eller genereres dynamisk
  • Backend-effektivitet: Hvor raskt CMS-et eller applikasjonsserveren din genererer HTML

Dette gjør TTFB til den mest handlingsrettede målingen for AI-synlighetsarbeid. Å forbedre LCP kan kreve omdesign av sidelayouten; å forbedre TTFB kan ofte gjøres med konfigurasjonsendringer alene. Gapet mellom 910 ms og 804 ms er oppnåelig for de fleste nettsteder med et CDN og grunnleggende serverbufring — og dataene våre tyder på å lukke det gapet er den enkeltstående mest virkningsfulle ytelsesoptimaliseringen du kan gjøre for AI-synlighet .

Hva en «god» TTFB er for AI-synlighet

Google anser en TTFB under 800 ms som «god». De mest siterte domenene i datasettet vårt ligger rett ved denne terskelen (804 ms median). Dette tyder på at det praktiske målet for AI-synlighet ikke er en elite-TTFB på under 200 ms, men rett og slett å være i «god»-området — under 800 ms.

Hvis TTFB-en din for øyeblikket er over 1 000 ms, opplever du sannsynligvis en viss grad av søkefriksjon. AI-søkeroboter opererer under tidsbudsjetter, og en server som bruker over ett sekund på å svare, vil miste en andel av gjennomsøkingsforsøkene til tidsavbrudd. Å komme under 1 000 ms bør være din første milepæl; å komme under 800 ms plasserer deg i selskap med de mest siterte domenene.

Praktiske anbefalinger

  1. Mål TTFB-en din fra flere geografiske lokasjoner. TTFB-en din vil variere avhengig av hvor forespørselen kommer fra. AI-søkeroboter kan hente data fra datasentre i andre regioner enn dine menneskelige besøkende. Bruk et verktøy som KeyCDNs Performance Test eller WebPageTest for å måle fra flere steder.

  2. Aktiver fullsidebufring. Hvis sidene dine genereres dynamisk ved hver forespørsel, vil TTFB-en være høy. Et bufringslag (Redis, Varnish eller CMS-ets innebygde bufrer) kan redusere TTFB fra 500+ ms til under 50 ms for bufrede sider.

  3. Bruk et CDN med edge-bufring. Et CDN serverer innholdet ditt fra lokasjoner nær den som forespør, noe som reduserer nettverksforsinkelse. Selv en grunnleggende CDN-konfigurasjon (Cloudflare, Fastly, CloudFront) kan redusere TTFB med 100–300 ms.

  4. Oppgrader hostingen din om nødvendig. Delte hostingplaner har ofte TTFB i området 1 000–2 000 ms. Å flytte til en VPS eller dedikert server, eller en administrert hostingplattform, kan være en betydelig forbedring.

Metodikk

Dette er en sammenheng blant sidene AI allerede siterer, ikke bevis på årsak: det beregnes ved å sammenstille Google CrUX / PageSpeed-feltdata med hvor ofte hvert domene ble sitert på tvers av AmICiteds 1 905 sporespørringer. CrUX-data var tilgjengelig for 6 556 av 8 845 siterte domener (74 %). Domener grupperes etter hvor mange svar som siterte dem; innenfor hver gruppe beregner vi gjennomsnittet av nettstedshelsemålet. Et domene «består Core Web Vitals» når majoriteten av de reviderte URL-ene består Googles LCP/INP /CLS-terskler i virkelige brukerdata (CrUX); TTFB og ytelsesscore beregnes tilsvarende. Sider uten tilstrekkelige CrUX-data ekskluderes. Fordi AmICiteds spørringer skjevfordeles mot SaaS , e-handel og støtteemner, beskriver disse tallene nettstedene som siteres for den typen spørringer. Forholdet er reelt, men beskjedent og korrelasjonsbasert — vi hevder ikke at raskere sider forårsaker flere siteringer.

Vanlige spørsmål

Arshia er AI Workflow Engineer hos FlowHunt. Med bakgrunn i informatikk og en lidenskap for AI spesialiserer han seg i å skape effektive arbeidsflyter som integrerer AI-verktøy i daglige oppgaver og øker produktivitet og kreativitet.

Arshia Kahani
Arshia Kahani
AI Workflow Engineer

Gjennomgå nettstedets AI-siteringshelse

Se hvilke AI-motorer som siterer nettstedet ditt — og hvordan din tekniske helse sammenlignes med sidene de siterer mest.