Miért lassú a Time to First Byte értéked, és mit tehetsz ellene

Kezdd azzal, hogy mit mér valójában a TTFB

A Time to First Byte, röviden TTFB, az az idő, amely a böngésző erőforrás-kérése és a válasz első bájtjának megérkezése között telik el.

Ez szervermetrikának hangzik, de nem csak szervermetrika. A TTFB több lépést is magában foglal:

• DNS-keresés, ha a hosztnév még nincs feloldva
• TCP-kapcsolat felépítése
• TLS-egyeztetés HTTPS esetén
• A kérés eljutási ideje a szerverhez vagy a CDN peremponthoz
• Sorban állás és feldolgozás a szerveren
• A válasz visszaérkezési ideje a böngészőhöz

A magas TTFB tehát jelentheti azt, hogy a backended lassú. De jelentheti azt is, hogy a felhasználó messze van az origin szervertől, a CDN rosszul van konfigurálva, a gyorsítótár folyamatosan mellé talál, vagy a szerver túl sok időt tölt azzal, hogy eldöntse, mit küldjön.

Ez azért fontos, mert a TTFB a betöltési lánc elején helyezkedik el. Ha a HTML-dokumentum későn érkezik meg, a böngésző a CSS-t, a JavaScriptet, a betűkészleteket és a képeket is későn fedezi fel. Lehet kiváló front-end optimalizációd, a webhely mégis lassúnak érződhet, ha az első dokumentumválasz 1,5 másodpercig tart.

Mi számít lassú TTFB-nek?

Nincs univerzális szám, amely minden webhelyre, régióra és architektúrára illene. A gyakorlati küszöbök mégis hasznosak.

A Google web.dev útmutatása szerint a jó TTFB 800 ms alatt van, a 800–1800 ms közötti érték javításra szorul, az 1800 ms feletti pedig gyengének számít. Egy jól gyorsítótárazott, a felhasználóhoz közel kiszolgált marketingoldalnál ennél gyakran sokkal jobb eredmény is elérhető. Egy dinamikus munkát végző, összetett, hitelesített irányítópultnál az elfogadható érték magasabb lehet, de ennek akkor is megmagyarázhatónak kell lennie.

A fontos szokás az érték szegmentálása. Egy 900 ms-os globális átlagos TTFB elfedhet egy 150 ms-os választ a CDN perempontodhoz közeli felhasználóknál, és egy 2200 ms-os választ egy másik régióban. Ugyanígy lehet, hogy a kezdőlap rendben van, miközben a keresési, kategória- vagy bejelentkezett oldalak csendben fájdalmasak.

Mérd több helyről is

Ne egyetlen Lighthouse futtatás alapján diagnosztizáld a TTFB-t. A Lighthouse hasznos, de egyetlen teszt egyetlen környezetből. Ha még új számodra az értelmezése, kezdd egy nyugodt áttekintéssel arról, hogyan olvass Lighthouse-jelentést pánik nélkül — a fő tanulság az, hogy különítsd el a laborjeleket a terepi valóságtól.

TTFB esetén legalább három nézetre van szükséged:

1. Böngésző fejlesztői eszközei

Nyisd meg a Network panelt, töltsd újra az oldalt letiltott gyorsítótárral, és vizsgáld meg a fő dokumentumkérést. Az időzítési bontás megmutatja a DNS, a kapcsolat, a TLS, a várakozás és a letöltés fázisait. A „waiting” fázis az, amit az emberek gyakran backend-időnek neveznek, bár upstream késleltetést is tartalmazhat.

2. Szintetikus tesztek több régióból

Futtass teszteket a felhasználóidhoz közeli és tőlük távoli helyszínekről is. Ha a TTFB az egyik régióban alacsony, egy másikban pedig magas, előbb gyanakodj földrajzi tényezőkre, CDN-útvonalválasztásra, origin elhelyezésre vagy cache-lefedettségre, mielőtt alkalmazáskódot írnál át.

3. Valós felhasználói monitorozás vagy szervernaplók

A terepi adatok megmutatják, mit tapasztalnak a valódi felhasználók különböző eszközökön, hálózatokon és munkamenetekben. A szervernaplók meg tudják mondani, hogy az origin gyorsan generált-e választ. A kliens által megfigyelt TTFB és az origin feldolgozási ideje közötti különbség gyakran ott mutatja meg a CDN- és hálózati problémákat.

A lassú TTFB szokásos okai

A HTML nincs gyorsítótárazva

Ez a leggyakoribb probléma tartalmi és e-kereskedelmi webhelyeken. A statikus assetek agresszíven gyorsítótárazva vannak, de a HTML-dokumentum — amelyre a böngészőnek először szüksége van — minden kérésnél újragenerálódik.

Néha ez szükséges. Gyakran nem az.

Ha egy nyilvános oldal naponta csak néhányszor változik, valószínűleg nem kellene minden anonim látogatóhoz friss adatbázis-renderelést igényelnie. Használj teljes oldalas gyorsítótárazást, edge cachinget, statikus generálást vagy stale-while-revalidate mintákat ott, ahol ez megfelelő.

Ellenőrizd a válaszfejléceket olyan jelekért, mint a Cache-Control, CDN-Cache-Status, Age, Vary és Set-Cookie. Egy oldal, amely minden látogatónak egyedi cookie-t küld, véletlenül gyorsítótárazhatatlanná teheti magát. Ha gyakorlati módszerre van szükséged ennek a rétegnek az átgondolásához, az éles környezetben használt átirányítások és HTTP-fejlécek hibakereséséről szóló útmutatónkban leírt hibakeresési szokások közvetlenül alkalmazhatók a TTFB-munkára.

A CDN csak asseteket gyorsítótáraz

Sok csapat hozzáad egy CDN-t, és úgy gondolja, a teljesítményfeladat kész. De ha a CDN csak képeket, CSS-t és JavaScriptet szolgál ki, az első HTML-kérés továbbra is egészen egyetlen origin szerverig utazhat.

Ez rendben lehet egy helyi vállalkozás helyi felhasználókat kiszolgáló webhelyénél. Nem rendben egy nemzetközi közönségnél. Minél messzebb van a felhasználó az origintől, annál több késleltetést fizetsz meg, még mielőtt a backend-munka egyáltalán elkezdődne.

A jó CDN-konfiguráció TTFB szempontból általában ezt jelenti:

• Gyorsítótárazd a nyilvános HTML-t, ahol biztonságos
• Tartsd tiszteletben a hitelesített vagy személyre szabott oldalak szándékos megkerülési szabályait
• Kerüld a felesleges Vary fejléceket, amelyek túl apróra darabolják a gyorsítótárat
• Használj cache-törlést vagy újraérvényesítést a gyorsítótár teljes letiltása helyett
• Ellenőrizd, hogy az edge helyszínek valóban találatokat szolgálnak-e ki, nem pedig minden kérést továbbítanak

A CDN nem varázslat. Gyorsítótár- és útvonalválasztási réteg. Kezeld is így.

A szerver túl sok mindent csinál válaszadás előtt

Egy lassú backend útvonal sok apró késleltetésből állhat össze: adatbázis-lekérdezések, API-hívások, sablonrenderelés, feature flag ellenőrzések, hitelesítés, személyre szabás, naplózás és cold startok.

A legrosszabb minta a soros függőségi munka. Például:

1. Oldaladatok lekérése
2. Majd kapcsolódó termékek lekérése
3. Majd árak lekérése
4. Majd ajánlórendszer meghívása
5. Majd HTML renderelése

Ha minden lépés az előzőre vár, a TTFB gyorsan nő. Párhuzamosítsd a független munkát, távolítsd el a nem kritikus hívásokat az első válaszból, és gyorsítótárazd a költséges eredményeket.

Hasznos szabály: ha a felhasználó nem látja vagy nem használja az eredményt azonnal, valószínűleg nem kellene blokkolnia az első bájtot.

Az adatbázis-lekérdezések lassúak vagy kiszámíthatatlanok

Az adatbázisok gyakran okoznak TTFB-problémákat, mert fejlesztői környezetben jól viselkednek, valós forgalom alatt viszont rosszul. Hiányzó indexek, nagy joinok, N+1 lekérdezések, zárolási versengés és túlméretezett eredményhalmazok mind úgy jelennek meg, hogy „lassú a szerver”.

Itt ne találgass. Rögzíts lekérdezési időket a lassú kérésekhez. Nézd a p95 és p99 értékeket, ne csak az átlagokat. Egy oldal, amely általában 120 ms alatt válaszol, de időnként 4 másodpercre blokkol, továbbra is rossz felhasználói élményt teremt.

Gyakori javítások:

• Indexek hozzáadása vagy javítása
• N+1 lekérdezési minták eltávolítása
• Olvasásintenzív adatok gyorsítótárazása
• Nagy lekérdezések lapozása
• Jelentési vagy analitikai lekérdezések eltávolítása a kérés idejéből
• Ésszerű timeoutok beállítása downstream hívásokhoz

Az alkalmazásodnál cold startok vannak

A serverless és konténerizált platformok kiválóak lehetnek, de a cold startok ronthatják a TTFB-t, ha a forgalom lökésszerű, vagy a régiók alul vannak méretezve.

Ha az első kérés tétlen idő után sokkal lassabb, mint a későbbi kérések, vizsgáld meg a cold startokat. Szükséged lehet provisioned concurrencyre, kisebb bundle-ökre, kevesebb indulási függőségre, melegen tartott függvényekre vagy más telepítési formára a késleltetésre érzékeny útvonalaknál.

Ez nem érv a serverless ellen. Ez érv az ellen, hogy úgy tegyünk, mintha a futtatási modell láthatatlan lenne.

Az átirányítások elpazarolják az első kérést

Egy átirányítás újabb kérés-válasz ciklust ad hozzá, mielőtt a böngésző megkapná a végső dokumentumot. Egy http:// → https:// átirányítás elkerülhetetlen lehet régi linkeknél, de a láncok pazarlóak.

Gyakori láncok:

• http://example.com → https://example.com → https://www.example.com
• záró perjel normalizálása a protokoll normalizálása után
• földrajzi vagy nyelvi átirányítások a cache-lookup előtt
• régi kampánylinkek, amelyek több URL-en keresztül ugrálnak

Javítsd a forráslinkeket, ahol lehet, vond össze az átirányítási szabályokat, és tedd közvetlenné a kanonikus URL-eket. Az átirányítási időt nem mindig jelentik TTFB-ként a végső kérésnél, de a felhasználó akkor is megfizeti.

Gyakorlati hibakeresési sorrend

Amikor a TTFB lassúnak tűnik, ezt a sorrendet kövesd. Elkerüli azt a gyakori hibát, hogy az alkalmazáskódot optimalizáljuk, mielőtt megerősítenénk a gyorsítótárazási és útvonalválasztási viselkedést.

Step 1: Teszteld a fő dokumentumot, ne csak az egész oldalt

Keresd meg a HTML-dokumentum kérését. Jegyezd fel a teljes TTFB-t és az időzítési bontást. Ismételd meg böngészőcache-sel és anélkül. Tesztelj nyilvános oldalt, dinamikus oldalt és bejelentkezett oldalt, ha releváns.

Step 2: Hasonlítsd össze a régiókat

Futtasd ugyanazt az URL-t több földrajzi helyről. Ha a lassú régiók az origintől mért távolsággal korrelálnak, a CDN-t és az edge cachinget részesítsd előnyben. Ha minden régió lassú, nézd meg a backend-feldolgozást és az origin kapacitását.

Step 3: Vizsgáld meg a válaszfejléceket

Keresd a cache-fejléceket, cookie-kat, Age értéket, CDN-státuszt és Vary fejlécet. A hiányzó Age fejléc vagy az ismétlődő cache miss-ek nyomok. Egy széles Vary: Cookie fejléc nyilvános HTML-en gyakran cache-gyilkos.

Step 4: Ellenőrizd az origin időzítését

Adj hozzá szerveridőzítési műszerezést. A Server-Timing fejléc láthatóvá teheti a backend fázisait, például az adatbázisidőt, a renderelési időt és az upstream API-időt. Még az egyszerű címkék is hasznosak:

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

Így a böngészőidőzítések megmutathatják, hogy a szerver 300 ms-ot valódi munkával töltött-e, vagy a késleltetés azelőtt történt, hogy a kérés elérte volna az alkalmazásodat.

Step 5: Javítsd a legnagyobb megerősített késleltetést

Ez magától értetődőnek hangzik, de a csapatok gyakran azt javítják, ami ismerős, nem pedig azt, amit mértek. Ha a cache miss-ek dominálnak, javítsd a gyorsítótárazást. Ha az adatbázis dominál, javítsd a lekérdezéseket. Ha a TLS és a kapcsolatfelépítés dominál globális felhasználóknál, javítsd az útvonalválasztást, a CDN-lefedettséget vagy az origin földrajzi elhelyezését.

A front-end munka továbbra is fontos. A betűkészletek, képek és JavaScript befolyásolják, mi történik a HTML megérkezése után. De nem helyettesítik a gyors első választ. Ha a renderelési teljesítményen is dolgozol, a webes betűkészletek sok webhelyen továbbra is a legegyszerűbb nyereségek közé tartoznak, mert befolyásolják, milyen gyorsan válik használhatóvá a szöveg a dokumentum megérkezése után.

Javítások, amelyek általában működnek

Gyorsítótárazd a nyilvános HTML-t az edge-en

Marketingoldalaknál, dokumentációnál, blogoknál, landing page-eknél és kategóriaoldalaknál az edge caching gyakran a legnagyobb TTFB-javulást hozza. Használj rövid TTL-eket, ha a tartalom gyakran változik. Használj stale-while-revalidate megközelítést, ha az enyhén elavult tartalom elfogadható, amíg a gyorsítótár a háttérben frissül.

Légy óvatos a személyre szabással. Ha egy oldal pénznem, nyelv, bejelentkezési állapot vagy kísérleti csoport szerint változik, definiáld ezeket a variánsokat explicit módon. A véletlen, felhasználónkénti variáció tönkreteszi a gyorsítótár hatékonyságát.

Vidd ki a nem kritikus munkát a kérési útvonalból

Az e-mail-küldésnek, analitikai gazdagításnak, ajánlásgenerálásnak, webhook-hívásoknak és nehéz naplózásnak ritkán kell blokkolnia az első bájtot. Tedd őket sorokba, vagy futtasd őket azután, hogy a válasz elindult.

Csökkentsd a backend-függőségi láncokat

Párhuzamosítsd a független hívásokat. Gyorsítótárazd a lassú API-k válaszait. Állíts be timeoutokat. Tervezz fallback tartalmat azokhoz a szolgáltatásokhoz, amelyek hasznosak, de nem létfontosságúak.

Egy lassú ajánló widget ne késleltesse az egész termékoldalt.

Vidd közelebb a számítást a felhasználókhoz

Ha a felhasználóid globálisak, az origined pedig egyetlen régióban van, a késleltetés strukturális. A CDN-gyorsítótárazás ezt nyilvános tartalomnál nagyrészt el tudja rejteni. Dinamikus tartalomnál fontold meg a regionális telepítéseket, az edge renderelést megfelelő útvonalaknál, vagy az API-k közelebb helyezését a közönséghez.

Tartsd unalmassá az átirányításokat

Kanonizáld az URL-eket egyetlen ugrásban. Frissítsd a belső linkeket, hogy a felhasználók és a crawlerek közvetlenül a végső célhoz jussanak. Auditáld a régi kampány-URL-eket és platformmigrációkat. Az átirányításokat könnyű figyelmen kívül hagyni, mert láthatatlanok, amikor működnek, de akkor is időbe kerülnek.

Mit ne tegyél

Ne hajszolj tökéletes TTFB-értéket minden útvonalon. Egy valódi számítást végző, hitelesített riport nem fog úgy viselkedni, mint egy gyorsítótárazott blogbejegyzés.

Ne használd az átlagos TTFB-t egyetlen metrikaként. A percentilisek számítanak. A földrajz számít. Az oldaltípus számít.

Ne feltételezd, hogy a CDN azt jelenti, a HTML-ed gyorsítótárazva van. Ellenőrizd.

És ne kezeld a TTFB-t a termékdöntésektől elkülönítve. A személyre szabásnak, kísérletezésnek, valós idejű készletinformációnak és harmadik féltől származó szolgáltatásoknak mind van késleltetési költsége. Némelyik megéri. Némelyik csak megszokás.

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

💡 Próbálja ki ezt: A TTFB diagnosztizálásakor a Get Headers feltárja a gyorsítótár állapotát, a szerveridőzítéseket és az átirányításokat, amelyek gyakran megmagyarázzák, honnan ered a késés.

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

A terv nyugodt változata

A lassú TTFB általában javítható, amint nem homályos „szerverproblémaként” kezeled. Mérd a dokumentumkérést. Szegmentálj régió és oldaltípus szerint. Vizsgáld meg a fejléceket. Hasonlítsd össze a kliensidőzítést az origin időzítésével. Ezután javítsd a legnagyobb megerősített szűk keresztmetszetet.

A legtöbb webhelynek nincs szüksége egzotikus architektúrára. Kevesebb elkerülhető cache miss-re, kevesebb blokkoló backend-munkára, tisztább átirányításokra és világosabb elképzelésre van szüksége arról, minek kell megtörténnie az első bájt elküldése előtt.