TTFB: vad en bra tid att första byte ser ut, och hur man kommer dit
Tiden till första bytet är väntan innan din server säger något alls, och det sätter taket för allt efter det. Vad ser bra ut och hur man hittar vilken del av din som är långsam.
TTFB är tiden mellan att webbläsaren skickar en begäran och mottar den första byten av svaret. Under 200ms är bra, 200 600ms är genomförbart, över 600ms är ett problem. Den är gjord av fyra separata delar - DNS, anslutningskonfiguration, nätverksresa och serverbehandling - och förbättrar det börjar med att räkna ut vilken av de fyra som äter din budget.
Tid till första byte är det tystaste mått på prestanda och en av de mest följdriktiga, eftersom inget annat kan börja förrän det är klart. Webbläsaren kan inte tolka HTML som den inte har, kan inte upptäcka stilmallen som refereras i den, kan inte börja hämta hjältebilden. En långsam TTFB gör hela sidan sen oavsett hur väl allt nedströms är optimerat.
Det är också ofta feldiagnostiserat, eftersom "TTFB är 900ms" är ett symptom med minst fyra olika sjukdomar.
De fyra sakerna som gömmer sig inuti ett nummer
Klicka på vilken begäran som helst på fliken Nätverk i webbläsaren och öppna panelen Tidpunkt. Du kommer att se uppdelningen som det enskilda TTFB-numret döljer:
- DNS-sökning – förvandlar ditt värdnamn till en IP-adress. Vanligtvis 0 till 50ms, och noll på upprepade besök. Om det är konsekvent högt är din DNS-leverantör långsam eller din TTL är för kort.
- Inledande anslutning och TLS handslag. Två till tre turer över TCP, en över QUIC. Skalas direkt med avstånd, och detta är den del som avslutar TLS vid en närliggande kant.
- Begär resa – få din förfrågan till den server som svarar på den.
- Väntar (TTFB) – servern gör faktiskt jobbet. Det här är Chrome-etiketterna "Väntar på serversvar", och på en långsam dynamisk webbplats är det hela historien.
Diagnostisering handlar om att titta på vilken bar som är längst. Om "Väntar" är 700ms och allt annat är 40ms, kommer ingen CDN-konfiguration att spara dig - din applikation är långsam och det är där arbetet är. Om "Väntande" är 40 ms och anslutningsfaserna är 600 ms, är din ansökan bra och du har ett geografiproblem.
Vad som räknas som bra
En viktig varning om dessa trösklar: de är bara meningsfulla vid sidan av den plats de mättes från. En 150ms TTFB från ditt kontor i samma stad som din server kan vara 800ms för en kund i Sao Paulo, och Sao Paulo-numret är det som påverkar dina intäkter. Testa alltid från minst tre regioner där du faktiskt har besökare.
TTFB är inte en viktig del av webben
Det är värt att säga det tydligt, för det skapar förvirring. Google rankas inte direkt på TTFB – den rankas på den största innehållsrika färgen och TTFB är en del av den. Det gör inte TTFB oviktigt; det gör det till en ledande indikator. Varje millisekund av TTFB är en millisekund LCP kan inte återställa, så en webbplats med en 900ms TTFB har spenderat mer än en tredjedel av sin 2,5-sekund LCP-budget innan webbläsaren har sett en enda tagg.
Fixa varje orsak
| Symptom i tidspanelen | Orsak | Fix |
|---|---|---|
| Lång väntan, kort allt annat | Långsam återgivning på serversidan | Cachelagra den färdiga sidan; profilera den långsamma frågan |
| Lång anslutning/TLS, kort "Väntande" | Ursprung långt ifrån besökare | Avsluta TLS och servera från en närliggande kant |
| Snabbt lokalt, långsamt från utlandet | Ursprung för en region | Cache vid kanter nära din faktiska publik |
| Snabb på andra lasten, långsam på första | Cache-missar | Höj cache- träffförhållandet; förvarm efter utrensningar |
| Konsekvent hög DNS | Långsam resolver eller kort TTL | Anycast DNS; höja TTL på stabila poster |
| Felaktiga, spikar under belastning | Ursprungskapacitet | Avlasta för att cachelagra så att ursprunget ser mindre |
Lägg märke till mönstret över de flesta av dessa rader: korrigeringen är "sluta göra den långsamma saken på varje begäran". En cachad sida som serveras från en närliggande kant hoppar över långdistanshandskakningen, programmet renderar och databasen helt - vilket är anledningen till att cachning gör mer för TTFB än något annat tillgängligt för dig.
En fälla värd att namnge: ett CDN framför en sida som inte kan sparas gör TTFB något värreInte bättre, för du har lagt till ett hopp. Om en sida innehåller Cache-Control: no-store kanten måste vidarebefordra varje begäran till ditt ursprung och vidarebefordra svaret. När någon rapporterar att en CDN gjorde sin webbplats långsammare, är det nästan alltid vad som hände - och fixen är att göra sidan cachelagras, inte att ta bort CDN.
Fem minuters diagnostik
Åtgärder från tre regioner
Din egen plats plus två platser där du har riktiga besökare. Notera spridningen, inte bara det bästa numret.
Öppna tidspanelen på HTML-begäran
Inte på en tillgång – på själva dokumentet. Identifiera den längsta baren.
Ladda samma sida två gånger
Om den andra belastningen är dramatiskt snabbare, mätte du en cachefel och ditt problem är träffförhållandet, inte råhastigheten.
Jämför kant och ursprung direkt
Begär sidan via CDN och sedan direkt från ditt ursprungliga värdnamn. Skillnaden berättar hur mycket kanten bidrar - och om det bidrar alls.
Vanliga frågor
Vad är en bra TTFB?
Under 200 millisekunder är bra och känns omedelbart, 200 till 600 millisekunder är acceptabelt med utrymme att förbättra, och över 600 millisekunder är långsam nog att besökarna märker. Dessa siffror betyder bara något i kombination med var mätningen togs - en bra TTFB från din egen stad kan vara dålig för besökare på en annan kontinent, så testa från de regioner din publik faktiskt är i.
Vad orsakar en långsam TTFB?
Fyra saker, och webbläsarens tidspanel kommer att berätta vilka. Långsam server-side-behandling visar som en lång "väntar" -fas; fysiskt avstånd till ursprunget visar som lång anslutning och TLS-faser; cache missar visar som en långsam första belastning och en snabb andra; och DNS-problem visar som en genomgående hög söktid. Var och en har en annan lösning, så att identifiera vilken som dominerar kommer före någon förändring.
Är TTFB en viktig del av webben?
Nej. Googles grundläggande webbfunktioner är största innehållsrika färg, interaktion med nästa färg och kumulativa layoutskift. TTFB är inte rankad direkt, men det är en komponent i LCP - varje millisekund som väntar på den första byten är en millisekund LCP kan inte komma tillbaka, så en hög TTFB caps hur bra din LCP kan vara.
Förbättrar en CDN TTFB?
Avsevärt, för cachebart innehåll. En cachad sida serveras från en kant nära besökaren, vilket tar bort långväga handskakning, programmet render och databasen arbete på en gång. För sidor som inte kan sparas ökar ett CDN något genom att lägga till ett hopp, så om en sida inte kan sparas är korrigeringen att göra den cachebar snarare än att ta bort CDN.
Hur mäter jag TTFB?
I Chrome DevTools öppnar du fliken Nätverk, klickar på dokumentförfrågan och läser panelen Timing, som separerar DNS, anslutning, TLS, begäran och väntetid. För en snabb kontroll av kommandoraden använd curl med utskriftstid_starttransfer i skrivformat. För att se vad verkliga besökare upplever snarare än vad du upplever, använd en syntetisk testtjänst som mäter från flera regioner eller övervakning av verkliga användare.
TTFB kapslar hela sidans hastighet, så sikta på under 200ms - men mät den från där dina besökare är och dela upp den i dess delar innan du ändrar något. Om "Väntande" dominerar, fixa ditt program eller cacha sidan. Om anslutningstiden dominerar flyttar du svaret närmare. Att fixa fel är det vanligaste sättet att spendera en vecka utan att få någonting.
Se hur NordicCDN gör detta för din webbplats:
Mads har arbetat inom IT – mestadels som värd – sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till förvärvet av Visma, har byggt och drivit datacenternätverk och fungerat som CTO för ett danskt datacenter. Han startade NordicCDN för att göra snabb och säker infrastruktur enkel att använda.
