TTFB: Co ovlivňuje dobu odezvy serveru a jak ji zlepšit

Když návštěvník otevře web, prohlížeč nejprve čeká na odpověď serveru. Čím déle trvá, než dorazí její první bajt, tím později může začít načítání stránky. TTFB pomáhá hledat zdržení v této úvodní fázi. Ať už vzniká na serveru, v síti nebo při přesměrování.

Co znamená TTFB

Zkratka TTFB pochází z anglického Time to First Byte, tedy „čas do prvního bajtu“. Měří dobu od začátku požadavku na stránku do chvíle, kdy prohlížeč obdrží první část odpovědi. Zahrnuje přitom více než samotné zpracování požadavku serverem. Může se do něj promítnout vyhledání DNS, navázání spojení, TLS handshake i přesměrování.

TTFB je důležitý proto, že předchází dalším krokům vykreslování. Pokud server pošle první část HTML pozdě, prohlížeč může později začít zpracovávat obsah a načítat prostředky potřebné k vykreslení stránky. Samotná hodnota TTFB ale neříká, kdy se stránka zobrazí nebo kdy s ní bude možné pracovat.

Google doporučuje jako orientační cíl TTFB do 0,8 sekundy. Hodnoty nad 1,8 sekundy označuje za špatné; pásmo mezi nimi je prostor pro zlepšení. Jde o vodítko, nikoli o samostatnou metriku Core Web Vitals. Výsledek je proto potřeba posuzovat spolu s dalšími ukazateli, například FCP a LCP, které lépe popisují, kdy návštěvník uvidí obsah stránky.

Co dobu odezvy ovlivňuje

TTFB se skládá z několika částí. Zahrnuje cestu požadavku od prohlížeče k serveru i čas, který server potřebuje k přípravě odpovědi. Na výsledku se proto mohou podílet různé příčiny:

•   Síť a vzdálenost serveru – požadavek musí mezi návštěvníkem a serverem urazit určitou vzdálenost. Vyšší latence nebo ztrátovost spojení se projeví zejména u uživatelů, kteří jsou daleko od serveru.
•   DNS, připojení a TLS – prohlížeč musí zjistit adresu webu a navázat zabezpečené spojení. U prvního požadavku mohou tyto kroky zabrat větší část času než u dalších požadavků na již otevřeném spojení.
•   Přesměrování – každé přesměrování znamená další požadavek a čekání na odpověď. Prodlevu může přidat například přesměrování z HTTP na HTTPS nebo řetězec několika starých adres.
•   Zpracování na serveru – aplikace může načítat data z databáze, spouštět výpočty, vykreslovat stránku nebo čekat na externí službu. Pomalé dotazy a přetížený server prodlužují dobu, než je odpověď připravena.
•   Cache – pokud lze stránku nebo její části obsloužit z mezipaměti, server nemusí při každém požadavku vše znovu zpracovávat. Naopak požadavek, který cache mine, může být pomalejší.
•   Výkon a nastavení hostingu – nedostatek paměti nebo kapacity může zpomalit aplikaci zejména při vyšší návštěvnosti. Roli hraje také aktuálnost serverového prostředí a konfigurace.

Pokud server nestíhá zpracovávat příchozí požadavky, musí na svou odpověď čekat i další návštěvníci. Pomalý TTFB se pak může objevovat hlavně ve špičce, zatímco při nízkém provozu web působí rychle.

Jak měřit rychlost odpovědi serveru

Začněte daty od skutečných návštěvníků. Laboratorní testy jsou užitečné pro porovnávání a hledání problémů, ale nemusí zachytit rozdíly v síti, umístění uživatelů nebo přesměrování, se kterými se setkávají při běžné návštěvě. Pro veřejné weby nabízí PageSpeed Insights laboratorní výsledky i dostupná data z reálného používání.

Pak porovnejte konkrétní adresy a situace – hlavní stránku, články, produktové stránky i části webu, které se generují dynamicky. Testujte z více míst a sledujte, zda je výsledek podobný při opakovaných měřeních. Je také dobré rozlišit požadavek obsloužený z cache od požadavku, který putoval až k původnímu serveru. Rychlá odpověď z cache může zakrýt pomalé generování stránky při cache missu.

Pokud potřebujete určit, která část aplikace server brzdí, může pomoci hlavička Server-Timing. Umožňuje zaznamenat například dobu databázového dotazu, serverového vykreslování nebo práce s cache. Tyto údaje se pak zobrazí ve vývojářských nástrojích prohlížeče. Alternativou je monitoring aplikace (APM).

Jak TTFB zlepšit

1)  Nejprve zjistěte, kde vzniká prodleva – porovnejte TTFB z reálných návštěv s výsledky laboratorních testů a měřte více stránek i z různých míst. Sledujte také, zda požadavek obsloužila cache, nebo musel až k původnímu serveru. Pokud aplikace nabízí podrobné měření, pomůže hlavička Server-Timing. Může ukázat například dobu databázových dotazů nebo vykreslování stránky.

2)  Odstraňte zbytečná přesměrování – upravte interní odkazy tak, aby vedly rovnou na cílovou adresu. Zkontrolujte také přesměrování mezi variantami domény, HTTP a HTTPS nebo adresami s lomítkem na konci. Jednotlivé kroky se mohou sčítat, proto odstraňte především řetězce přesměrování, které máte pod kontrolou.

3)  Nastavte vhodné cáchování – obsah, který se často nemění, lze ukládat do cache, aby se při každé návštěvě nemusel znovu generovat. Prověřte, které stránky a soubory se cachují, jak dlouho v cache zůstávají a proč některé požadavky cache obcházejí. U osobních nebo jinak proměnlivých údajů nastavte pravidla opatrně, aby návštěvník nedostal zastaralý či cizí obsah.

4) Využijte CDN pro návštěvníky ve větší vzdálenosti – CDN může uložit vhodný obsah na servery blíže návštěvníkům. Prohlížeč pak nemusí kvůli každému souboru komunikovat až s původním serverem. Největší přínos mívá u obsahu, který lze bezpečně cachovat. Dynamické požadavky se mohou stále vracet na původní server.

5)  Zrychlete práci aplikace a databáze – prověřte pomalé databázové dotazy, opakované načítání stejných dat, zbytečné výpočty a volání externích služeb. Pokud stránka čeká na odpověď jiné služby, hledejte, zda lze volání zkrátit, ukládat jeho výsledek do cache nebo ho provést až po odeslání hlavní odpovědi. Konkrétní příčinu pomohou určit logy, APM nebo měření jednotlivých částí požadavku.

6)  Zkontrolujte kapacitu hostingu – sledujte vytížení serveru, dostupnou paměť a chování webu ve chvílích vyšší návštěvnosti. Pokud se TTFB zhoršuje hlavně ve špičce, může aplikaci chybět kapacita pro současné požadavky. Vyšší výkon hostingu může pomoci, ale vyplatí se nejdříve ověřit, zda problém opravdu způsobuje nedostatek prostředků, a ne například pomalý dotaz nebo nevyužitá cache.

7)  Připravujte dopředu stránky, které se mění jen zřídka – u některých částí webu lze HTML vytvořit předem a návštěvníkům posílat hotový soubor. Server pak nemusí při každém požadavku znovu načítat data a skládat celou stránku. Tento přístup se hodí například pro často čtené články nebo informační stránky, které neobsahují individuální obsah pro každého uživatele.

8)  U dynamických stránek zvažte postupné odesílání obsahu – některé aplikace mohou posílat HTML po částech, jakmile jsou jednotlivé části připravené. Prohlížeč tak může začít dokument zpracovávat dříve, aniž by čekal na dokončení celé stránky. Přínos závisí na použité technologii a na tom, jak je aplikace navržená.

Po každé změně měřte znovu ve stejných podmínkách. Tak zjistíte, zda se zlepšil TTFB skutečných návštěvníků, a zároveň ověříte, že úprava neovlivnila správné zobrazování nebo aktuálnost obsahu.

TTFB jako vodítko při výběru řešení

Vysoký TTFB může způsobovat pomalý server, ale také síťová latence, přesměrování nebo nevyužitá cache. Než začnete měnit hosting či upravovat aplikaci, změřte dobu odezvy u skutečných návštěvníků a zjistěte, ve které části vzniká prodleva. Teprve podle výsledků se rozhodněte, zda pomůže úprava databáze, lepší cachování, odstranění přesměrování nebo výkonnější server.

Pro menší weby a WordPress může být jednou z možností webhosting CZECHIA.COM s LiteSpeed. U náročnějších webů, které vyžadují vlastní prostředí a možnost přizpůsobit výkon, lze zvážit Cloud Server VPS od ZonerCloudu. Samotný hosting ani server však nízký TTFB nezaručí. Záleží také na kódu aplikace, databázi, nastavení cache a vzdálenosti návštěvníků. Výsledek proto vždy ověřte měřením po nasazení změn.