Prečo je váš Time to First Byte pomalý a čo s tým robiť

Začnite tým, čo TTFB naozaj meria

Time to First Byte, zvyčajne skracované ako TTFB, je čas medzi tým, keď prehliadač požiada o zdroj, a tým, keď prijme prvý bajt odpovede.

Znie to ako serverová metrika, ale nie je to iba serverová metrika. TTFB zahŕňa viacero krokov:

• DNS lookup, ak hostname ešte nie je vyriešený
• nadviazanie TCP spojenia
• TLS vyjednávanie pre HTTPS
• čas cesty požiadavky na server alebo CDN edge
• čakanie vo fronte a spracovanie na serveri
• čas cesty odpovede späť do prehliadača

Vysoké TTFB teda môže znamenať, že váš backend je pomalý. Môže tiež znamenať, že používateľ je ďaleko od vášho origin servera, vaša CDN je nesprávne nakonfigurovaná, cache neustále míňa zásahy alebo serveru trvá príliš dlho rozhodnúť, čo má odoslať.

Je to dôležité, pretože TTFB stojí blízko začiatku načítavacieho reťazca. Ak HTML dokument dorazí neskoro, prehliadač neskoro objaví aj CSS, JavaScript, fonty a obrázky. Môžete mať výbornú optimalizáciu front-endu, a predsa stránka pôsobí pomaly, ak prvá odpoveď s dokumentom trvá 1,5 sekundy.

Čo sa považuje za pomalé TTFB?

Neexistuje univerzálne číslo, ktoré by sedelo každej stránke, regiónu a architektúre. Praktické prahy však pomáhajú.

Odporúčania Google web.dev klasifikujú dobré TTFB ako hodnotu pod 800 ms, pričom 800–1800 ms vyžaduje zlepšenie a viac než 1800 ms sa považuje za slabé. Pri dobre cachovanej marketingovej stránke obsluhovanej blízko používateľa sa často dá dosiahnuť výrazne lepší výsledok. Pri komplexnom autentifikovanom dashboarde, ktorý vykonáva dynamickú prácu, môže byť prijateľné číslo vyššie, ale stále by malo byť vysvetliteľné.

Dôležitý návyk je číslo segmentovať. Globálny priemer TTFB 900 ms môže skrývať odpoveď 150 ms pre používateľov blízko vášho CDN edge a odpoveď 2200 ms pre používateľov v inom regióne. Rovnako môže byť vaša domovská stránka v poriadku, zatiaľ čo vyhľadávanie, kategórie alebo stránky pre prihlásených používateľov sú potichu bolestivé.

Merajte ho na viac než jednom mieste

Nediagnostikujte TTFB z jedného spustenia Lighthouse. Lighthouse je užitočný, ale je to jeden test z jedného prostredia. Ak sa ešte len učíte interpretovať jeho výsledky, začnite pokojne tým, ako čítať report Lighthouse bez paniky — hlavné ponaučenie je oddeliť laboratórne signály od reality v teréne.

Pri TTFB chcete aspoň tri pohľady:

1. Nástroje pre vývojárov v prehliadači

Otvorte panel Network, znovu načítajte stránku s vypnutou cache a skontrolujte hlavnú požiadavku na dokument. Rozpis časovania ukazuje fázy DNS, spojenia, TLS, čakania a sťahovania. Fáza „waiting“ je často to, čo ľudia myslia backendovým časom, hoci môže zahŕňať aj upstream latenciu.

2. Syntetické testy z viacerých regiónov

Spúšťajte testy z lokalít blízko aj ďaleko od vašich používateľov. Ak je TTFB nízke v jednom regióne a vysoké v inom, skôr než začnete prepisovať aplikačný kód, podozrievajte geografiu, smerovanie CDN, umiestnenie origin servera alebo pokrytie cache.

3. Real user monitoring alebo serverové logy

Dáta z terénu hovoria, čo skutoční používatelia zažívajú naprieč zariadeniami, sieťami a reláciami. Serverové logy vám môžu povedať, či origin server vygeneroval odpoveď rýchlo. Rozdiel medzi TTFB pozorovaným klientom a časom spracovania na origin serveri je často miestom, kde sa objavia problémy s CDN a sieťou.

Bežné príčiny pomalého TTFB

Vaše HTML sa necachuje

Toto je najčastejší problém na obsahových a e-commerce stránkach. Statické assety sa cachujú agresívne, ale HTML dokument — teda vec, ktorú prehliadač potrebuje ako prvú — sa generuje pri každej požiadavke.

Niekedy je to nevyhnutné. Často však nie.

Ak sa verejná stránka mení niekoľkokrát denne, pravdepodobne by nemala vyžadovať čerstvé renderovanie z databázy pre každého anonymného návštevníka. Tam, kde je to vhodné, použite full-page caching, edge caching, statické generovanie alebo vzory stale-while-revalidate.

Skontrolujte hlavičky odpovede a hľadajte signály ako Cache-Control, CDN-Cache-Status, Age, Vary a Set-Cookie. Stránka, ktorá posiela každému návštevníkovi unikátnu cookie, sa môže omylom spraviť necachovateľnou. Ak potrebujete praktický spôsob, ako o tejto vrstve uvažovať, rovnaké debugovacie návyky z nášho sprievodcu presmerovaniami a HTTP hlavičkami v produkcii sa priamo vzťahujú aj na prácu s TTFB.

Vaša CDN cachuje iba assety

Mnohé tímy pridajú CDN a predpokladajú, že výkon je vyriešený. Ak však CDN obsluhuje iba obrázky, CSS a JavaScript, prvá požiadavka na HTML môže stále putovať až na jediný origin server.

Pri lokálnej firemnej stránke s lokálnymi používateľmi to môže byť v poriadku. Pre medzinárodné publikum to v poriadku nie je. Čím ďalej je používateľ od origin servera, tým viac latencie platíte ešte predtým, než sa vôbec začne backendová práca.

Dobrá konfigurácia CDN pre TTFB zvyčajne znamená:

• Cachovať verejné HTML tam, kde je to bezpečné
• Rešpektovať zámerné pravidlá obchádzania cache pre autentifikované alebo personalizované stránky
• Vyhýbať sa zbytočným hlavičkám Vary, ktoré delia cache príliš jemne
• Používať cache purging alebo revalidation namiesto úplného vypnutia cache
• Overiť, že edge lokality skutočne obsluhujú cache hity a neposielajú ďalej každú požiadavku

CDN nie je mágia. Je to vrstva cache a smerovania. Tak s ňou aj zaobchádzajte.

Server robí pred odpoveďou príliš veľa práce

Pomalá backendová cesta môže vzniknúť z mnohých malých oneskorení: databázové dotazy, API volania, renderovanie šablón, kontroly feature flagov, autentifikácia, personalizácia, logovanie a cold starty.

Najhorší vzor je sériová práca so závislosťami. Napríklad:

1. Načítať dáta stránky
2. Potom načítať súvisiace produkty
3. Potom načítať ceny
4. Potom zavolať službu odporúčaní
5. Potom vyrenderovať HTML

Ak každý krok čaká na predchádzajúci, TTFB rýchlo rastie. Paralelizujte nezávislú prácu, odstráňte nekritické volania z prvej odpovede a cachujte drahé výsledky.

Užitočné pravidlo: ak používateľ výsledok nemôže okamžite vidieť alebo použiť, pravdepodobne by nemal blokovať prvý bajt.

Databázové dotazy sú pomalé alebo nepredvídateľné

Databázy často spôsobujú problémy s TTFB, pretože vo vývoji sa správajú dobre a pri skutočnej prevádzke zle. Chýbajúce indexy, veľké joiny, N+1 dotazy, lock contention a príliš veľké result sety sa všetky prejavia ako „server je pomalý“.

Tu nehádajte. Zaznamenávajte časovania dotazov pre pomalé požiadavky. Pozerajte sa na p95 a p99, nielen na priemery. Stránka, ktorá zvyčajne odpovie za 120 ms, ale občas sa zablokuje na 4 sekundy, stále vytvorí zlú používateľskú skúsenosť.

Bežné opravy zahŕňajú:

• Pridanie alebo opravu indexov
• Odstránenie vzorov N+1 dotazov
• Cachovanie dát s vysokým podielom čítania
• Stránkovanie veľkých dotazov
• Presunutie reportovacích alebo analytických dotazov mimo času požiadavky
• Nastavenie rozumných timeoutov pre downstream volania

Vaša aplikácia má cold starty

Serverless a kontajnerizované platformy môžu byť výborné, ale cold starty môžu poškodiť TTFB, keď je prevádzka nárazová alebo regióny nemajú dostatočne provisionovanú kapacitu.

Ak je vaša prvá požiadavka po nečinnosti výrazne pomalšia než neskoršie požiadavky, preskúmajte cold starty. Možno budete potrebovať provisioned concurrency, menšie bundle, menej startup závislostí, udržiavané „teplé“ funkcie alebo iný tvar nasadenia pre trasy citlivé na latenciu.

Toto nie je argument proti serverless. Je to argument proti predstieraniu, že runtime model je neviditeľný.

Presmerovania plytvajú prvou požiadavkou

Presmerovanie pridáva ďalší cyklus požiadavka-odpoveď predtým, než prehliadač dostane finálny dokument. Jedno presmerovanie z http:// na https:// môže byť pre staré odkazy nevyhnutné, ale reťazce sú plytvanie.

Bežné reťazce zahŕňajú:

• http://example.com → https://example.com → https://www.example.com
• normalizáciu lomky na konci po normalizácii protokolu
• geografické alebo jazykové presmerovania pred vyhľadaním v cache
• staré kampanové odkazy, ktoré preskakujú cez viacero URL

Kde je to možné, opravte zdrojové odkazy, zlučte pravidlá presmerovaní a robte kanonické URL priame. Čas presmerovania sa nie vždy vykazuje ako TTFB finálnej požiadavky, ale používateľ ho stále zaplatí.

Praktická postupnosť debugovania

Keď TTFB vyzerá pomaly, postupujte v tomto poradí. Vyhnete sa tým bežnej chybe optimalizácie aplikačného kódu ešte pred potvrdením správania cache a smerovania.

Krok 1: Testujte hlavný dokument, nielen celú stránku

Nájdite požiadavku na HTML dokument. Zaznamenajte celkové TTFB a rozpis časovania. Zopakujte to s cache prehliadača aj bez nej. Ak je to relevantné, otestujte verejnú stránku, dynamickú stránku aj stránku pre prihláseného používateľa.

Krok 2: Porovnajte regióny

Spustite rovnakú URL z viacerých geografických lokalít. Ak pomalé regióny korelujú so vzdialenosťou od origin servera, uprednostnite CDN a edge caching. Ak je pomalý každý región, pozrite sa na backendové spracovanie a kapacitu origin servera.

Krok 3: Skontrolujte hlavičky odpovede

Hľadajte cache hlavičky, cookies, Age, stav CDN a Vary. Chýbajúca hlavička Age alebo opakované cache missy sú stopy. Široká hlavička Vary: Cookie na verejnom HTML je často zabijak cache.

Krok 4: Skontrolujte časovanie origin servera

Pridajte serverovú časovaciu inštrumentáciu. Hlavička Server-Timing môže odhaliť backendové fázy, ako čas databázy, čas renderovania a čas upstream API. Už aj jednoduché štítky sú užitočné:

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

Teraz môžu časovania v prehliadači ukázať, či server strávil 300 ms skutočnou prácou, alebo či oneskorenie nastalo predtým, než požiadavka dorazila do vašej aplikácie.

Krok 5: Opravte najväčšie potvrdené oneskorenie

Znie to samozrejme, ale tímy často opravujú to, čo poznajú, namiesto toho, čo zmerali. Ak dominujú cache missy, opravte cachovanie. Ak dominuje databáza, opravte dotazy. Ak pri globálnych používateľoch dominuje TLS a nadviazanie spojenia, opravte smerovanie, pokrytie CDN alebo geografiu origin servera.

Front-end práca je stále dôležitá. Fonty, obrázky a JavaScript ovplyvňujú to, čo sa deje po doručení HTML. Nie sú však náhradou za rýchlu prvú odpoveď. Ak zároveň riešite výkon renderovania, webové fonty zostávajú na mnohých stránkach jedným z najjednoduchších víťazstiev, pretože ovplyvňujú, ako rýchlo sa text stane použiteľným po doručení dokumentu.

Opravy, ktoré zvyčajne fungujú

Cachujte verejné HTML na edge

Pri marketingových stránkach, dokumentácii, blogoch, landing pages a stránkach kategórií je edge caching často najväčším zlepšením TTFB. Ak sa obsah mení často, použite krátke TTL. Ak je mierne zastaraný obsah prijateľný počas toho, ako sa cache obnovuje na pozadí, použite stale-while-revalidate.

Buďte opatrní pri personalizácii. Ak sa stránka líši podľa meny, jazyka, stavu prihlásenia alebo experimentálnej skupiny, tieto varianty definujte explicitne. Náhodná variácia na úrovni jednotlivého používateľa ničí efektivitu cache.

Presuňte nekritickú prácu mimo cesty požiadavky

Odosielanie e-mailov, analytické obohacovanie, generovanie odporúčaní, webhook volania a ťažké logovanie by len zriedka mali blokovať prvý bajt. Dajte ich do frontov alebo ich spúšťajte po začatí odpovede.

Znížte reťazce backendových závislostí

Paralelizujte nezávislé volania. Cachujte odpovede pomalých API. Nastavte timeouty. Navrhnite fallback obsah pre služby, ktoré sú užitočné, ale nie nevyhnutné.

Pomalý widget odporúčaní by nemal zdržať celú produktovú stránku.

Umiestnite výpočty bližšie k používateľom

Ak sú vaši používatelia globálni a váš origin server je v jednom regióne, latencia je štrukturálna. CDN caching môže pri verejnom obsahu veľkú časť skryť. Pri dynamickom obsahu zvážte regionálne nasadenia, edge rendering pre vhodné trasy alebo presun API bližšie k publiku.

Udržujte presmerovania nudné

Kanonizujte URL jedným skokom. Aktualizujte interné odkazy tak, aby používatelia a crawlery išli priamo do finálneho cieľa. Auditujte staré kampanové URL a migrácie platforiem. Presmerovania sa ľahko ignorujú, pretože keď fungujú, sú neviditeľné, ale stále stoja čas.

Čo nerobiť

Nesnažte sa naháňať dokonalé TTFB číslo pre každú trasu. Autentifikovaný report, ktorý vykonáva skutočný výpočet, sa nebude správať ako cachovaný blogový článok.

Nepoužívajte priemerné TTFB ako jedinú metriku. Percentily sú dôležité. Geografia je dôležitá. Typ stránky je dôležitý.

Nepredpokladajte, že CDN znamená, že vaše HTML je cachované. Overte si to.

A nepovažujte TTFB za oddelené od produktových rozhodnutí. Personalizácia, experimentovanie, real-time skladové zásoby a služby tretích strán majú všetky náklady na latenciu. Niektoré za to stoja. Niektoré sú len zvyk.

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

💡 Vyskúšajte toto: Pri diagnostike TTFB odhalí Get Headers stav cache, časovania servera a presmerovania, ktoré často vysvetľujú, odkiaľ pochádza oneskorenie.

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

Pokojná verzia plánu

Pomalé TTFB sa zvyčajne dá opraviť, keď ho prestanete brať ako neurčitý „problém servera“. Zmerajte požiadavku na dokument. Segmentujte podľa regiónu a typu stránky. Skontrolujte hlavičky. Porovnajte časovanie klienta s časovaním origin servera. Potom opravte najväčšie potvrdené úzke hrdlo.

Väčšina stránok nepotrebuje exotickú architektúru. Potrebuje menej zbytočných cache missov, menej blokujúcej backendovej práce, čistejšie presmerovania a jasnejšiu predstavu o tom, čo sa musí stať pred odoslaním prvého bajtu.