TTFB: hvad en god tid til første byte ser ud, og hvordan man kommer dertil
Tiden til første byte er ventetiden, før din server siger noget overhovedet, og det sætter loftet for alt efter det. Hvad godt ser ud, og hvordan man finder ud af, hvilken del af din er langsom.
TTFB er tiden mellem browseren sender en anmodning og modtager den første byte af svaret. Under 200ms er godt, 200-600ms er brugbart, over 600ms er et problem. Det er lavet af fire separerbare dele - DNS, forbindelsesopsætning, netværksrejse og serverbehandling - og forbedring af det starter med at finde ud af, hvilken af de fire der spiser dit budget.
Time to First Byte er den mest støjsvage måling af ydeevne og en af de mest konsekvente målinger, fordi intet andet kan starte, før den er færdig. Browseren kan ikke fortolke HTML, den har ikke, kan ikke finde stilarket der refereres til i den, kan ikke begynde at hente heltebilledet. En langsom TTFB gør hele siden forsinket, uanset hvor godt alt nedstrøms er optimeret.
Det er også ofte fejldiagnosticeret, fordi "TTFB er 900ms" er et symptom med mindst fire forskellige sygdomme.
De fire ting, der gemmer sig i ét nummer
Klik på en anmodning på fanen Netværk i din browser, og åbn panelet Timing. Du vil se den opdeling, som det enkelte TTFB-nummer skjuler:
- DNS- opslag – gør dit værtsnavn til en IP-adresse. Normalt 0 til 50 ms, og nul på gentagne besøg. Hvis den konstant er høj, er din DNS-udbyder langsom, eller din TTL er for kort.
- IndledendFørste forbindelse og TLS håndtryk. To til tre runder over TCP, én over QUIC. Skaleres direkte med afstanden, og det er den del, der afslutter TLS ved en nærliggende kant, der eliminerer.
- Anmod om rRejseanmodning sendt til den server, der besvarer den.
- Venter (korrekt TTFB) - serveren rent faktisk gør arbejdet. Dette er den del, Chrome-etiketter "Venter på serverrespons", og på et langsomt dynamisk websted er det hele historien.
Diagnosticering er et spørgsmål om at se på, hvilken bar der er længst. Hvis "Venter" er 700ms og alt andet er 40ms, vil ingen CDN-konfiguration redde dig - din applikation er langsom, og det er der, arbejdet er. Hvis "Vent" er 40 ms, og tilslutningsfaserne er 600 ms, er din ansøgning i orden, og du har et geografisk problem.
Hvad der tæller som godt
En vigtig advarsel om disse tærskler: de er kun meningsfulde sammen med den placering, de blev målt fra. En 150ms TTFB fra dit kontor i samme by som din server kan være 800ms for en kunde i Sao Paulo, og Sao Paulo-nummeret er det, der påvirker din omsætning. Test altid fra mindst tre områder, hvor du rent faktisk har besøgende.
TTFB er ikke en vigtig kerne på internettet
Værd at sige klart, fordi det skaber forvirring. Google rangerer ikke direkte på TTFB – det rangerer på den største indholdsrige maling, og TTFB er en del af den. Det betyder ikke, at TTFB er ligegyldigt; det gør det til en førende indikator. Hvert millisekund af TTFB er et millisekund LCP kan ikke gendanne, så et websted med en 900ms TTFB har brugt mere end en tredjedel af sin 2,5-sekund LCP budget, før browseren har set et enkelt tag.
Fastsættelse af hver årsag
| Symptomer i panelet Timing | Årsag | Fix |
|---|---|---|
| Lang "venter", kort alt andet | Langsom gengivelse på serversiden | Cacheér den færdige side; profilér den langsomme forespørgsel |
| Lang tilslutning/TLS, kort "Venter" | Oprindelse langt fra besøgende | Afslut TLS, og server fra en nærliggende kant |
| Hurtigt lokalt, langsomt fra udlandet | Oprindelse i ét område | Cache ved kanter tæt på dit faktiske publikum |
| Hurtig på anden belastning, langsom på første | Cache-fejl | Hæv cache-hitforholdet; før opvarmning efter udrensninger |
| Konsekvent høj DNS | Langsom resolver eller kort TTL | Anycast DNS; løft TTL på stabile poster |
| Fejlagtige, pigge under belastning | Oprindelseskapacitet | Aflad til cache, så oprindelsen ser mindre ud |
Bemærk mønsteret på tværs af de fleste af disse rækker: Rettelsen er "stoppe med at gøre den langsomme ting på hver anmodning". En cachelagret side serveret fra en nærliggende kant springer langdistance håndtryk, programmet render og databasen helt - hvilket er grunden til caching gør mere for TTFB end noget andet tilgængeligt for dig.
Én fælde, der er værd at nævne: Et CDN foran en side, der ikke kan cachelagres, gør TTFB lidt lettere værreIkke bedre, fordi du har tilføjet et hop. Hvis en side indeholder Cache-Control: no-store kanten skal videresende hver anmodning til din oprindelse og videresende svaret. Når nogen rapporterer, at en CDN gjorde deres websted langsommere, er det næsten altid, hvad der skete - og rettelse er at gøre siden cacheable, ikke at fjerne CDN.
Fem minutters diagnose
Måling fra tre regioner
Din egen placering plus to steder, du har rigtige besøgende. Bemærk spredningen, ikke kun det bedste tal.
Åbn panelet Timing på HTML-anmodningen
Ikke på et aktiv på selve dokumentet. Identificer den længste bar.
Indlæs den samme side to gange
Hvis den anden belastning er dramatisk hurtigere, målte du en cachefejl, og dit problem er ramt forhold, ikke rå hastighed.
Sammenlign kant og oprindelse direkte
Anmod om siden via CDN og derefter direkte fra dit oprindelige værtsnavn. Forskellen fortæller dig, hvor meget kanten bidrager - og om det overhovedet bidrager.
Ofte stillede spørgsmål
Hvad er en god TTFB?
Under 200 millisekunder er godt og føles øjeblikkelig, 200 til 600 millisekunder er acceptabelt med plads til at forbedre, og over 600 millisekunder er langsom nok til, at besøgende bemærker. Disse tal betyder kun noget i kombination med, hvor målingen blev taget - en god TTFB fra din egen by kan være dårlig for besøgende på et andet kontinent, så test fra de regioner, dit publikum faktisk er i.
Hvad forårsager en langsom TTFB?
Fire ting, og browserens timingpanel vil fortælle dig, hvilke. Langsom server-side behandling viser som en lang "Venter" fase; fysisk afstand til oprindelsen viser som lang forbindelse og TLS faser; cache misses viser som en langsom første belastning og en hurtig anden; og DNS problemer viser som En konsekvent høj søgningstid. Hver har en anden løsning, så at identificere, hvilken der dominerer, kommer før enhver ændring.
Er TTFB en vigtig del af internettet?
Nej. Googles kerneværdier for webindhold er den største indholdsrige maling, interaktion med næste maling og kumulative layoutskift. TTFB er ikke rangeret direkte, men det er en del af LCP - hver millisekund brugt på at vente på den første byte er en millisekund LCP kan ikke komme tilbage, så en høj TTFB caps hvor god din LCP kan være.
Forbedrer en CDN TTFB?
Væsentligt, for cacheable indhold. En cachelagret side serveres fra en kant nær den besøgende, hvilket fjerner langdistance håndtryk, programmet render og databasen arbejde på én gang. For ikke-cacheable sider en CDN lidt øger TTFB ved at tilføje en hop, så hvis en side sender no-store rettelse er at gøre det cacheable snarere end at fjerne CDN.
Hvordan måler jeg TTFB?
I Chrome DevTools skal du åbne fanen Netværk, klikke på dokumentanmodningen og læse panelet Timing, som adskiller DNS, forbindelse, TLS, anmodning og ventetid. Brug curl med en udskrivningsformatering af time_starttransfer for en hurtig kommandolinjekontrol. For at se, hvad rigtige besøgende oplever i stedet for hvad du oplever, skal du bruge en syntetisk testtjeneste, der måler fra flere regioner eller overvågning af virkelige brugere.
TTFB caps hele din sides hastighed, så sigt efter under 200ms - men mål det fra hvor dine besøgende er, og opdel det i dets dele, før du ændrer noget. Hvis "Venter" dominerer, skal du rette din ansøgning eller cachelagre siden. Hvis tilslutningstiden dominerer, skal du flytte svaret tættere på. At rette den forkerte er den mest almindelige måde at tilbringe en uge på og ikke få noget.
Se, hvordan NordicCDN gør dette for dit websted:
Mads har arbejdet med IT – mest som vært – siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig og sikker infrastruktur enkel at bruge.
