Proč je váš Time to First Byte pomalý a co s tím dělat

Začněte tím, co TTFB skutečně měří

Time to First Byte, obvykle zkracované jako TTFB, je čas mezi okamžikem, kdy prohlížeč požádá o zdroj, a okamžikem, kdy obdrží první bajt odpovědi.

Zní to jako metrika serveru, ale není to pouze serverová metrika. TTFB zahrnuje několik kroků:

• DNS lookup, pokud hostname ještě není přeložený
• navázání TCP spojení
• TLS vyjednávání pro HTTPS
• dobu cesty požadavku k serveru nebo CDN edge
• čekání ve frontě a zpracování na serveru
• dobu cesty odpovědi zpět do prohlížeče

Vysoké TTFB tedy může znamenat, že je váš backend pomalý. Může to ale také znamenat, že uživatel je daleko od vašeho originu, CDN je špatně nakonfigurovaná, cache neustále míjí, nebo server tráví příliš mnoho času rozhodováním, co má odeslat.

Je to důležité, protože TTFB leží blízko začátku načítacího řetězce. Pokud HTML dokument dorazí pozdě, prohlížeč pozdě objeví také CSS, JavaScript, fonty a obrázky. Můžete mít výbornou optimalizaci front-endu, a přesto web působí pomalu, pokud první odpověď s dokumentem trvá 1,5 sekundy.

Co se počítá jako pomalé TTFB?

Neexistuje univerzální číslo, které by platilo pro každý web, region a architekturu. Praktické prahy ale pomáhají.

Doporučení Google web.dev klasifikuje dobré TTFB jako hodnotu pod 800 ms, 800–1800 ms jako oblast vyžadující zlepšení a více než 1800 ms jako špatný výsledek. U dobře cachované marketingové stránky obsluhované blízko uživatele můžete často dosáhnout mnohem lepších hodnot. U složitého autentizovaného dashboardu, který provádí dynamickou práci, může být přijatelná hodnota vyšší, ale stále by měla být vysvětlitelná.

Důležitým návykem je číslo segmentovat. Globální průměrné TTFB 900 ms může skrývat odpověď 150 ms pro uživatele poblíž vašeho CDN edge a odpověď 2200 ms pro uživatele v jiném regionu. Stejně tak může být vaše domovská stránka v pořádku, zatímco vyhledávání, kategorie nebo stránky pro přihlášené uživatele tiše bolí.

Měřte na více než jednom místě

Nediagnostikujte TTFB z jediného běhu Lighthouse. Lighthouse je užitečný, ale je to jeden test z jednoho prostředí. Pokud s jeho interpretací začínáte, začněte klidným čtením toho, jak číst report Lighthouse bez paniky — hlavní lekce je oddělit laboratorní signály od reality v terénu.

U TTFB chcete alespoň tři pohledy:

1. Vývojářské nástroje prohlížeče

Otevřete panel Network, znovu načtěte stránku s vypnutou cache a prohlédněte si požadavek na hlavní dokument. Rozpad časování ukazuje fáze DNS, spojení, TLS, čekání a stahování. Fáze „waiting“ je často to, co lidé myslí časem backendu, i když může zahrnovat i latenci upstreamu.

2. Syntetické testy z více regionů

Spusťte testy z lokalit blízko i daleko od vašich uživatelů. Pokud je TTFB v jednom regionu nízké a v jiném vysoké, dříve než začnete přepisovat aplikační kód, podezírejte geografii, směrování CDN, umístění originu nebo pokrytí cache.

3. Real user monitoring nebo serverové logy

Terénní data vám řeknou, co skuteční uživatelé zažívají napříč zařízeními, sítěmi a relacemi. Serverové logy vám mohou říct, zda origin vygeneroval odpověď rychle. Rozdíl mezi TTFB pozorovaným klientem a dobou zpracování na originu je často místo, kde se projeví problémy s CDN a sítí.

Obvyklé příčiny pomalého TTFB

Vaše HTML se necachuje

Toto je nejběžnější problém u obsahových webů a ecommerce webů. Statické assety se cachují agresivně, ale HTML dokument — tedy věc, kterou prohlížeč potřebuje jako první — se generuje při každém požadavku.

Někdy je to nezbytné. Často ale není.

Pokud se veřejná stránka mění několikrát denně, pravděpodobně by neměla vyžadovat nové vykreslení z databáze pro každého anonymního návštěvníka. Kde je to vhodné, použijte full-page caching, edge caching, statické generování nebo vzory stale-while-revalidate.

Zkontrolujte hlavičky odpovědi a hledejte signály jako Cache-Control, CDN-Cache-Status, Age, Vary a Set-Cookie. Stránka, která každému návštěvníkovi posílá unikátní cookie, se může omylem učinit necachovatelnou. Pokud potřebujete praktický způsob, jak o této vrstvě uvažovat, stejné ladicí návyky z našeho průvodce přesměrováními a HTTP hlavičkami v produkci se přímo hodí i pro práci na TTFB.

Vaše CDN cachuje jen assety

Mnoho týmů přidá CDN a předpokládá, že práce na výkonu je hotová. Pokud ale CDN obsluhuje jen obrázky, CSS a JavaScript, první požadavek na HTML může stále cestovat až k jedinému origin serveru.

U lokálního firemního webu s lokálními uživateli to může být v pořádku. Pro mezinárodní publikum to v pořádku není. Čím dál je uživatel od originu, tím větší latenci zaplatíte ještě předtím, než vůbec začne práce backendu.

Dobrá konfigurace CDN pro TTFB obvykle znamená:

• Cachovat veřejné HTML tam, kde je to bezpečné
• Respektovat záměrná pravidla pro bypass u autentizovaných nebo personalizovaných stránek
• Vyhnout se zbytečným hlavičkám Vary, které cache dělí příliš jemně
• Používat purge cache nebo revalidaci místo úplného vypnutí cache
• Ověřit, že edge lokace skutečně obsluhují zásahy, a neposílají dál každý požadavek

CDN není magie. Je to cache a směrovací vrstva. Zacházejte s ní tak.

Server před odpovědí dělá příliš mnoho práce

Pomalá backendová cesta může vzniknout z mnoha malých zpoždění: databázových dotazů, API volání, vykreslování šablon, kontrol feature flagů, autentizace, personalizace, logování a cold starts.

Nejhorší vzor je sériová práce se závislostmi. Například:

1. Načíst data stránky
2. Poté načíst související produkty
3. Poté načíst ceny
4. Poté zavolat službu doporučení
5. Poté vykreslit HTML

Pokud každý krok čeká na ten předchozí, TTFB rychle roste. Paralelizujte nezávislou práci, odstraňte nekritická volání z první odpovědi a cachujte drahé výsledky.

Užitečné pravidlo: pokud uživatel výsledek nemůže okamžitě vidět nebo použít, pravděpodobně by neměl blokovat první bajt.

Databázové dotazy jsou pomalé nebo nepředvídatelné

Databáze často způsobují problémy s TTFB, protože ve vývoji se chovají dobře a pod skutečným provozem špatně. Chybějící indexy, velké joiny, N+1 dotazy, soupeření o zámky a příliš velké sady výsledků se všechny projeví jako „server je pomalý“.

Tady nehádejte. Zachytávejte časování dotazů u pomalých požadavků. Dívejte se na p95 a p99, nejen na průměry. Stránka, která obvykle odpovídá za 120 ms, ale občas se zasekne na 4 sekundy, bude stále vytvářet špatnou uživatelskou zkušenost.

Mezi běžné opravy patří:

• Přidání nebo oprava indexů
• Odstranění vzorů N+1 dotazů
• Cachování často čtených dat
• Stránkování velkých dotazů
• Přesunutí reportingových nebo analytických dotazů mimo čas požadavku
• Nastavení rozumných timeoutů pro downstream volání

Vaše aplikace má cold starts

Serverless a kontejnerizované platformy mohou být výborné, ale cold starts mohou TTFB poškodit, když je provoz nárazový nebo regiony nejsou dostatečně dimenzované.

Pokud je první požadavek po nečinnosti výrazně pomalejší než pozdější požadavky, prozkoumejte cold starts. Možná budete potřebovat provisioned concurrency, menší bundly, méně startovacích závislostí, zahřívané funkce nebo jiný způsob nasazení pro trasy citlivé na latenci.

Toto není argument proti serverless. Je to argument proti předstírání, že model běhového prostředí je neviditelný.

Přesměrování plýtvají prvním požadavkem

Přesměrování přidává další cyklus požadavek–odpověď předtím, než prohlížeč obdrží finální dokument. Jedno přesměrování z http:// na https:// může být u starých odkazů nevyhnutelné, ale řetězce jsou plýtvání.

Běžné řetězce zahrnují:

• http://example.com → https://example.com → https://www.example.com
• normalizaci trailing slash po normalizaci protokolu
• geografická nebo jazyková přesměrování před lookupem cache
• staré kampaně, které skáčou přes několik URL

Kde je to možné, opravte zdrojové odkazy, slučte pravidla přesměrování a udělejte kanonické URL přímé. Čas přesměrování se ne vždy reportuje jako TTFB finálního požadavku, ale uživatel za něj stále platí.

Praktický postup ladění

Když TTFB vypadá pomalu, postupujte v tomto pořadí. Vyhnete se tak běžné chybě, kdy se optimalizuje aplikační kód dříve, než se potvrdí chování cache a směrování.

Krok 1: Testujte hlavní dokument, ne jen celou stránku

Najděte požadavek na HTML dokument. Zaznamenejte celkové TTFB a rozpad časování. Opakujte s cache prohlížeče i bez ní. Pokud je to relevantní, otestujte veřejnou stránku, dynamickou stránku a stránku pro přihlášené uživatele.

Krok 2: Porovnejte regiony

Spusťte stejnou URL z několika geografických lokalit. Pokud pomalé regiony korelují se vzdáleností od originu, upřednostněte CDN a edge caching. Pokud jsou pomalé všechny regiony, podívejte se na zpracování backendu a kapacitu originu.

Krok 3: Prohlédněte hlavičky odpovědi

Hledejte cache hlavičky, cookies, Age, stav CDN a Vary. Chybějící hlavička Age nebo opakované cache misses jsou vodítka. Široká hlavička Vary: Cookie na veřejném HTML je často zabiják cache.

Krok 4: Zkontrolujte časování originu

Přidejte instrumentaci serverového časování. Hlavička Server-Timing může odhalit backendové fáze, jako je čas databáze, čas renderování a čas upstream API. I jednoduché štítky jsou užitečné:

Server-Timing: db;dur=82, render;dur=41, api;dur=210

Nyní mohou časování v prohlížeči ukázat, zda server strávil 300 ms skutečnou prací, nebo zda ke zpoždění došlo ještě předtím, než požadavek dorazil do vaší aplikace.

Krok 5: Opravte největší potvrzené zpoždění

Zní to samozřejmě, ale týmy často opravují to, co znají, místo toho, co naměřily. Pokud dominují cache misses, opravte cachování. Pokud dominuje databáze, opravte dotazy. Pokud u globálních uživatelů dominují TLS a navazování spojení, opravte směrování, pokrytí CDN nebo geografii originu.

Práce na front-endu je stále důležitá. Fonty, obrázky a JavaScript ovlivňují to, co se děje po doručení HTML. Nejsou ale náhradou za rychlou první odpověď. Pokud zároveň řešíte výkon vykreslování, webové fonty zůstávají na mnoha webech jedním z nejsnazších vítězství, protože ovlivňují, jak rychle se text stane použitelným po doručení dokumentu.

Opravy, které obvykle fungují

Cachujte veřejné HTML na edge

U marketingových stránek, dokumentace, blogů, landing pages a kategorií bývá edge caching často největším zlepšením TTFB. Použijte krátké TTL, pokud se obsah často mění. Použijte stale-while-revalidate, pokud je mírně zastaralý obsah přijatelný, zatímco se cache obnovuje na pozadí.

Buďte opatrní s personalizací. Pokud se stránka liší podle měny, jazyka, stavu přihlášení nebo experimentální skupiny, definujte tyto varianty explicitně. Náhodná variace po jednotlivých uživatelích ničí efektivitu cache.

Přesuňte nekritickou práci mimo cestu požadavku

Odesílání e-mailů, obohacování analytiky, generování doporučení, webhook volání a těžké logování by měly první bajt blokovat jen zřídka. Dejte je do front nebo je spusťte po zahájení odpovědi.

Omezte řetězce backendových závislostí

Paralelizujte nezávislá volání. Cachujte odpovědi z pomalých API. Nastavte timeouty. Navrhněte fallback obsah pro služby, které jsou užitečné, ale ne nezbytné.

Pomalý widget doporučení by neměl zdržet celou produktovou stránku.

Přesuňte výpočet blíž k uživatelům

Pokud jsou vaši uživatelé globální a origin je v jednom regionu, latence je strukturální. CDN caching může velkou část toho u veřejného obsahu skrýt. U dynamického obsahu zvažte regionální nasazení, edge rendering pro vhodné trasy nebo přesunutí API blíž k publiku.

Udržujte přesměrování nudná

Kanonikalizujte URL jedním skokem. Aktualizujte interní odkazy tak, aby uživatelé a crawlery šli přímo do finální destinace. Auditujte staré kampaně a migrace platforem. Přesměrování se snadno ignorují, protože když fungují, jsou neviditelná, ale stále stojí čas.

Co nedělat

Nehonit dokonalé TTFB pro každou trasu. Autentizovaný report, který provádí skutečný výpočet, se nebude chovat jako cachovaný blogový příspěvek.

Nepoužívejte průměrné TTFB jako jedinou metriku. Na percentilech záleží. Na geografii záleží. Na typu stránky záleží.

Nepředpokládejte, že CDN znamená, že je vaše HTML cachované. Ověřte to.

A neberte TTFB jako něco odděleného od produktových rozhodnutí. Personalizace, experimentování, inventář v reálném čase a služby třetích stran mají všechny latenci jako náklad. Některé za to stojí. Některé jsou jen zvyk.

<!-- tool-cta:start -->

💡 Vyzkoušejte toto: Při diagnostice TTFB odhalí Get Headers stav cache, časování serveru a přesměrování, které často vysvětlují, odkud zpoždění pochází.

<!-- tool-cta:end -->

Klidná verze plánu

Pomalé TTFB je obvykle opravitelné, jakmile s ním přestanete zacházet jako s vágním „problémem serveru“. Změřte požadavek na dokument. Segmentujte podle regionu a typu stránky. Prohlédněte hlavičky. Porovnejte časování klienta s časováním originu. Poté opravte největší potvrzené úzké hrdlo.

Většina webů nepotřebuje exotickou architekturu. Potřebuje méně zbytečných cache misses, méně blokující backendové práce, čistší přesměrování a jasnější představu o tom, co se musí stát před odesláním prvního bajtu.