TTFB vs doba odezvy vs latence: co každá měří

Co jednotlivé pojmy znamenají

Síťová latence, často udávaná jako doba zpáteční cesty (round-trip time), je čas, který paket stráví cestou na server a zpět, bez jakékoli práce aplikace mezitím. Určuje ji fyzická vzdálenost, počet skoků na trase a kvalita spojení. Nic, co uděláte ve svém kódu, ji nezmění.

Time to first byte (TTFB) se měří od okamžiku, kdy klient odešle požadavek, do chvíle, kdy k němu dorazí první bajt odpovědi. Do tohoto úseku spadá DNS vyhledávání, navázání TCP spojení, TLS handshake, čas, který požadavek stráví na cestě, cokoli server udělá, aby vytvořil odpověď, a cesta zpět. TTFB je proto vždy delší než jedna zpáteční cesta, obvykle o pořádný kus.

Doba odezvy je ze všech tří pojmů nejvolnější. Většina monitorovacích nástrojů ji používá pro celkový čas dokončení požadavku, od prvního paketu až po poslední bajt těla odpovědi. Některé nástroje ji ale používají jako synonymum pro TTFB. Než porovnáte dvě čísla nazvaná "response time", ověřte si, na čem každý nástroj zastavil stopky.

Jak se každá hodnota měří

Latence pochází z ICMP echo, což je to, co posílá ping, nebo z měření TCP handshake, pokud je ICMP blokované. TTFB a celkový čas pocházejí přímo z HTTP klienta. Jedno volání curl vypíše všechny hranice najednou:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/

Každá hodnota je kumulativní od začátku požadavku, takže je čtete jako hranice, ne jako trvání. Délku jedné fáze získáte odečtením té předchozí.

Které číslo vám váš nástroj vlastně ukazuje

Každý nástroj hlásí jiný výřez téhož požadavku, a to je obvyklý důvod, proč se dvě měření stejného webu neshodují:

• ping hlásí jen latenci zpáteční cesty, bez jakékoli práce serveru
• curl -w hlásí všechny hranice uvedené výše, což z něj dělá referenci, když se čísla neshodují
• Vývojářské nástroje v prohlížeči zobrazují TTFB jako čekací fázi požadavku, oddělenou od fáze stahování pod ní
• Lighthouse a PageSpeed hlásí dobu odezvy serveru, což je TTFB pro požadavek na dokument
• Monitory dostupnosti hlásí dobu odezvy, jejíž definice se liší produkt od produktu a která zahrnuje navázání spojení odkudkoli, odkud kontrola proběhla
• Monitoring skutečných uživatelů hlásí terénní TTFB, agregované napříč reálnými návštěvníky na reálných sítích

Jak vypadá dobré číslo

Latenci určuje geografie. Do 30 ms je normální v rámci jedné metropolitní oblasti, 50 až 100 ms napříč kontinentem a 150 až 250 ms mezi kontinenty. Trasa, která naměří výrazně víc, než odpovídá vzdálenosti, spíš ukazuje na špatnou trasu než na pomalý server.

U TTFB považuje web.dev 800 ms nebo méně za dobré a cokoli nad 1,8 sekundy za špatné, zatímco audit doby odezvy serveru v Lighthouse začíná hlásit selhání nad 600 ms. Cílit byste měli pod 600 ms pro požadavek na dokument a 200 ms berte jako cíl pro cokoli cachovaného nebo statického.

Celková doba odezvy závisí na velikosti toho, co posíláte, takže univerzální číslo neexistuje. Změřte si vlastní výchozí hodnotu za běžný den a jako signál sledujte změnu vůči ní, ne absolutní číslo.

Co prozradí mezery mezi hodnotami

Na jednotlivých číslech nezáleží tolik jako na rozdílu mezi nimi, protože každá mezera ukazuje na jiný podsystém:

• TTFB minus latence zpáteční cesty je zhruba doba, kterou server strávil "přemýšlením". Pokud je to většina času, problém je v kódu aplikace, pomalém dotazu nebo studené cache
• Connect minus DNS lookup je jedna zpáteční cesta pro TCP handshake. Pokud je výrazně vyšší než naměřená latence, síťová trasa je přetížená nebo špatně směrovaná
• TLS minus connect je cena handshake, obvykle jedna nebo dvě zpáteční cesty navíc, a vysoká hodnota ukazuje na problém s řetězem certifikátů nebo obnovením relace
• Total minus TTFB je čas přenosu. Pokud dominuje, odpověď je příliš velká nebo je spojení příliš pomalé, a žádné ladění serveru tady nepomůže
• Samotné DNS vyhledávání by po zacachování mělo trvat pár milisekund. Trvale pomalé vyhledávání je problém resolveru nebo autoritativního jmenného serveru, ne webového serveru

Stejné čtení funguje i obráceně, když je pomalá jen jedna lokalita. Stejný čas "přemýšlení" serveru všude, s rozdílem výhradně v latenci a přenosu, znamená, že server je v pořádku a problém je v trase. Než sáhnete do aplikace, spusťte kontrolu z více míst.

Jak to změřit na jednom místě

Chcete-li tato čísla pro stránku zjistit, aniž byste je skládali ručně, spusťte test rychlosti stránky, který stránku načte z externí lokality a rozdělí načítání na jednotlivé fáze. Návod na dobu odezvy serveru popisuje totéž měření z příkazové řádky. Jedno spuštění vypovídá jen o daném okamžiku, takže pokud na čísle záleží, nastavte si na něj pravidelnou kontrolu: HostTracker měří dobu odezvy při každé kontrole z více než 300 kontrolních bodů ve 158 městech, a právě to mění jedno naměření na výchozí hodnotu, vůči které jde poznat regresi. Další definice najdete v sekci o pojmech z monitoringu.