Zašto je vaš Time to First Byte spor i što učiniti u vezi s tim

Počnite od toga što TTFB zapravo mjeri

Time to First Byte, obično skraćeno TTFB, vrijeme je između trenutka kada preglednik zatraži resurs i trenutka kada primi prvi bajt odgovora.

To zvuči kao metrika poslužitelja, ali nije samo metrika poslužitelja. TTFB uključuje nekoliko koraka:

• DNS lookup, ako naziv hosta još nije razriješen
• Uspostavu TCP veze
• TLS pregovaranje za HTTPS
• Vrijeme putovanja zahtjeva do poslužitelja ili CDN edgea
• Čekanje u redu i obradu na poslužitelju
• Vrijeme putovanja odgovora natrag do preglednika

Dakle, visok TTFB može značiti da je vaš backend spor. Može značiti i da je korisnik daleko od vašeg origina, da je CDN pogrešno konfiguriran, da vaša predmemorija stalno promašuje ili da poslužitelj predugo odlučuje što poslati.

To je važno jer se TTFB nalazi blizu početka lanca učitavanja. Ako HTML dokument stigne kasno, preglednik kasno otkriva i CSS, JavaScript, fontove i slike. Možete imati izvrsnu front-end optimizaciju, a stranica će se i dalje činiti sporom ako prvi odgovor dokumenta traje 1,5 sekundi.

Što se smatra sporim TTFB-om?

Ne postoji univerzalan broj koji odgovara svakoj web-lokaciji, regiji i arhitekturi. Ipak, praktični pragovi pomažu.

Googleove smjernice na web.dev klasificiraju dobar TTFB kao onaj ispod 800 ms, dok 800–1800 ms zahtijeva poboljšanje, a iznad 1800 ms smatra se lošim. Za dobro predmemoriranu marketinšku stranicu posluženu blizu korisnika često možete postići znatno bolje rezultate. Za složenu autentificiranu nadzornu ploču koja obavlja dinamički rad prihvatljiv broj može biti viši, ali i dalje bi trebao biti objašnjiv.

Važna navika jest segmentirati broj. Globalni prosječni TTFB od 900 ms može skrivati odgovor od 150 ms za korisnike blizu vašeg CDN edgea i odgovor od 2200 ms za korisnike u drugoj regiji. Isto tako, vaša početna stranica može biti u redu, dok su pretraživanje, kategorije ili stranice za prijavljene korisnike potiho bolne.

Mjerite ga na više mjesta

Nemojte dijagnosticirati TTFB na temelju jednog Lighthouse pokretanja. Lighthouse je koristan, ali to je jedan test iz jednog okruženja. Ako tek učite kako ga tumačiti, počnite smirenim čitanjem o tome kako čitati Lighthouse izvješće bez panike — glavna je lekcija odvojiti laboratorijske signale od stvarnosti na terenu.

Za TTFB želite barem tri pogleda:

1. Alati za razvojne programere u pregledniku

Otvorite Network panel, ponovno učitajte stranicu s onemogućenom predmemorijom i pregledajte zahtjev za glavni dokument. Vremenska raščlamba prikazuje DNS, vezu, TLS, čekanje i faze preuzimanja. Faza “waiting” često je ono što ljudi podrazumijevaju pod vremenom backenda, iako može uključivati i upstream latenciju.

2. Sintetički testovi iz više regija

Pokrenite testove s lokacija blizu i daleko od svojih korisnika. Ako je TTFB nizak u jednoj regiji, a visok u drugoj, prije prepisivanja aplikacijskog koda posumnjajte na geografiju, CDN usmjeravanje, smještaj origina ili pokrivenost predmemorijom.

3. Praćenje stvarnih korisnika ili poslužiteljski zapisi

Podaci s terena govore vam što stvarni korisnici doživljavaju na različitim uređajima, mrežama i sesijama. Poslužiteljski zapisi mogu vam reći je li origin brzo generirao odgovor. Razlika između TTFB-a koji vidi klijent i vremena obrade na originu često je mjesto gdje se pojavljuju CDN i mrežni problemi.

Uobičajeni uzroci sporog TTFB-a

Vaš HTML nije predmemoriran

Ovo je najčešći problem na sadržajnim web-lokacijama i ecommerce web-lokacijama. Statički resursi agresivno se predmemoriraju, ali HTML dokument — ono što preglednik prvo treba — generira se pri svakom zahtjevu.

Ponekad je to nužno. Često nije.

Ako se javna stranica mijenja nekoliko puta dnevno, vjerojatno ne bi trebala zahtijevati svježe renderiranje iz baze podataka za svakog anonimnog posjetitelja. Koristite predmemoriranje cijele stranice, edge caching, statičko generiranje ili stale-while-revalidate obrasce gdje je prikladno.

Provjerite zaglavlja odgovora za signale kao što su Cache-Control, CDN-Cache-Status, Age, Vary i Set-Cookie. Stranica koja svakom posjetitelju šalje jedinstveni kolačić može se slučajno učiniti nepredmemorabilnom. Ako trebate praktičan način razmišljanja o ovom sloju, iste navike otklanjanja pogrešaka iz našeg vodiča za preusmjeravanja i HTTP zaglavlja u produkciji izravno se primjenjuju na rad s TTFB-om.

Vaš CDN predmemorira samo resurse

Mnogi timovi dodaju CDN i pretpostave da je posao oko performansi završen. Ali ako CDN poslužuje samo slike, CSS i JavaScript, prvi HTML zahtjev i dalje može putovati sve do jednog origin poslužitelja.

To može biti u redu za lokalnu poslovnu web-lokaciju s lokalnim korisnicima. Nije u redu za međunarodnu publiku. Što je korisnik dalje od origina, to više latencije plaćate prije nego što backend rad uopće počne.

Dobra CDN konfiguracija za TTFB obično znači:

• Predmemorirati javni HTML gdje je sigurno
• Poštovati namjerna pravila zaobilaženja za autentificirane ili personalizirane stranice
• Izbjegavati nepotrebna Vary zaglavlja koja previše usitnjavaju predmemoriju
• Koristiti čišćenje predmemorije ili revalidaciju umjesto potpunog onemogućavanja predmemorije
• Potvrditi da edge lokacije doista poslužuju pogotke, a ne prosljeđuju svaki zahtjev

CDN nije magija. To je sloj predmemorije i usmjeravanja. Tako ga i tretirajte.

Vaš poslužitelj radi previše prije odgovora

Spor backend put može nastati zbog mnogo malih kašnjenja: upita bazi podataka, API poziva, renderiranja predložaka, provjera feature flagova, autentifikacije, personalizacije, zapisivanja i cold startova.

Najgori obrazac je serijski rad ovisnosti. Na primjer:

1. Dohvati podatke stranice
2. Zatim dohvati povezane proizvode
3. Zatim dohvati cijene
4. Zatim pozovi servis za preporuke
5. Zatim renderiraj HTML

Ako svaki korak čeka prethodni, TTFB brzo raste. Paralelizirajte neovisni rad, uklonite nekritične pozive iz prvog odgovora i predmemorirajte skupe rezultate.

Korisno pravilo: ako korisnik ne može odmah vidjeti ili koristiti rezultat, vjerojatno ne bi trebao blokirati prvi bajt.

Upiti bazi podataka su spori ili nepredvidivi

Baze podataka često uzrokuju probleme s TTFB-om jer se dobro ponašaju u razvoju, a loše pod stvarnim prometom. Nedostajući indeksi, veliki joinovi, N+1 upiti, sukobi zaključavanja i preveliki skupovi rezultata svi se pojavljuju kao “poslužitelj je spor”.

Ovdje nemojte nagađati. Zabilježite trajanja upita za spore zahtjeve. Gledajte p95 i p99, ne samo prosjeke. Stranica koja obično odgovori za 120 ms, ali povremeno blokira 4 sekunde, i dalje će stvoriti loše korisničko iskustvo.

Uobičajeni popravci uključuju:

• Dodavanje ili ispravljanje indeksa
• Uklanjanje N+1 obrazaca upita
• Predmemoriranje podataka koji se često čitaju
• Paginaciju velikih upita
• Premještanje reporting ili analytics upita izvan vremena zahtjeva
• Postavljanje razumnih timeouta za downstream pozive

Vaša aplikacija ima cold startove

Serverless i kontejnerizirane platforme mogu biti izvrsne, ali cold startovi mogu naštetiti TTFB-u kada je promet naletni ili su regije premalo opskrbljene.

Ako je vaš prvi zahtjev nakon razdoblja mirovanja znatno sporiji od kasnijih zahtjeva, istražite cold startove. Možda će vam trebati provisioned concurrency, manji bundleovi, manje startup ovisnosti, zagrijanije funkcije ili drukčiji oblik deploya za rute osjetljive na latenciju.

Ovo nije argument protiv serverlessa. Ovo je argument protiv pretvaranja da je runtime model nevidljiv.

Preusmjeravanja troše prvi zahtjev

Preusmjeravanje dodaje još jedan ciklus zahtjev-odgovor prije nego što preglednik primi konačni dokument. Jedno preusmjeravanje s http:// na https:// može biti neizbježno za stare poveznice, ali lanci su rasipni.

Uobičajeni lanci uključuju:

• http://example.com → https://example.com → https://www.example.com
• normalizaciju završne kose crte nakon normalizacije protokola
• geo ili jezična preusmjeravanja prije pretraživanja predmemorije
• stare kampanjske poveznice koje skaču kroz nekoliko URL-ova

Popravite izvorne poveznice gdje je moguće, spojite pravila preusmjeravanja i učinite kanonske URL-ove izravnima. Vrijeme preusmjeravanja ne prijavljuje se uvijek kao TTFB za konačni zahtjev, ali korisnik ga i dalje plaća.

Praktičan redoslijed otklanjanja pogrešaka

Kada TTFB izgleda sporo, koristite ovaj redoslijed. Izbjegava uobičajenu pogrešku optimiziranja aplikacijskog koda prije potvrde ponašanja predmemorije i usmjeravanja.

Korak 1: Testirajte glavni dokument, ne samo cijelu stranicu

Pronađite zahtjev za HTML dokument. Zabilježite ukupni TTFB i vremensku raščlambu. Ponovite s predmemorijom preglednika i bez nje. Testirajte javnu stranicu, dinamičku stranicu i stranicu za prijavljene korisnike ako je relevantno.

Korak 2: Usporedite regije

Pokrenite isti URL s nekoliko geografskih lokacija. Ako spore regije koreliraju s udaljenošću od origina, prioritizirajte CDN i edge caching. Ako je svaka regija spora, pogledajte backend obradu i kapacitet origina.

Korak 3: Pregledajte zaglavlja odgovora

Potražite zaglavlja predmemorije, kolačiće, Age, CDN status i Vary. Nedostajuće Age zaglavlje ili ponovljeni promašaji predmemorije su tragovi. Široko Vary: Cookie zaglavlje na javnom HTML-u često ubija predmemoriju.

Korak 4: Provjerite vrijeme origina

Dodajte instrumentaciju vremena na poslužitelju. Zaglavlje Server-Timing može izložiti backend faze kao što su vrijeme baze podataka, vrijeme renderiranja i vrijeme upstream API-ja. Čak su i jednostavne oznake korisne:

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

Sada vremena u pregledniku mogu pokazati je li poslužitelj potrošio 300 ms na stvarni rad ili se kašnjenje dogodilo prije nego što je zahtjev stigao do vaše aplikacije.

Korak 5: Popravite najveće potvrđeno kašnjenje

Ovo zvuči očito, ali timovi često popravljaju ono što im je poznato umjesto onoga što je izmjereno. Ako dominiraju promašaji predmemorije, popravite predmemoriranje. Ako dominira baza podataka, popravite upite. Ako za globalne korisnike dominiraju TLS i uspostava veze, popravite usmjeravanje, CDN pokrivenost ili geografiju origina.

Front-end rad je i dalje važan. Fontovi, slike i JavaScript utječu na ono što se događa nakon što HTML stigne. Ali oni nisu zamjena za brz prvi odgovor. Ako također radite na performansama renderiranja, web fontovi i dalje su jedna od najlakših pobjeda na mnogim web-lokacijama jer utječu na to koliko brzo tekst postaje upotrebljiv nakon što dokument stigne.

Popravci koji obično djeluju

Predmemorirajte javni HTML na edgeu

Za marketinške stranice, dokumentaciju, blogove, landing stranice i stranice kategorija edge caching često je najveće poboljšanje TTFB-a. Koristite kratke TTL-ove ako se sadržaj često mijenja. Koristite stale-while-revalidate ako je blago zastarjeli sadržaj prihvatljiv dok se predmemorija osvježava u pozadini.

Budite oprezni s personalizacijom. Ako se stranica razlikuje po valuti, jeziku, stanju prijave ili eksperimentalnoj grupi, izričito definirajte te varijante. Slučajna varijacija po korisniku uništava učinkovitost predmemorije.

Premjestite nekritični rad izvan puta zahtjeva

Slanje e-pošte, obogaćivanje analitike, generiranje preporuka, webhook pozivi i teško zapisivanje rijetko bi trebali blokirati prvi bajt. Stavite ih u redove ili ih pokrenite nakon što je odgovor započet.

Smanjite lance backend ovisnosti

Paralelizirajte neovisne pozive. Predmemorirajte odgovore sporih API-ja. Postavite timeoute. Dizajnirajte zamjenski sadržaj za servise koji su korisni, ali nisu nužni.

Spor widget za preporuke ne bi trebao odgoditi cijelu stranicu proizvoda.

Premjestite compute bliže korisnicima

Ako su vaši korisnici globalni, a origin je u jednoj regiji, latencija je strukturna. CDN predmemoriranje može sakriti velik dio toga za javni sadržaj. Za dinamički sadržaj razmotrite regionalne deployeve, edge rendering za prikladne rute ili premještanje API-ja bliže publici.

Neka preusmjeravanja budu dosadna

Kanonikalizirajte URL-ove u jednom skoku. Ažurirajte interne poveznice tako da korisnici i crawleri idu izravno na konačno odredište. Revidirajte stare kampanjske URL-ove i migracije platformi. Preusmjeravanja je lako ignorirati jer su nevidljiva kada rade, ali i dalje koštaju vremena.

Što ne raditi

Nemojte juriti savršen TTFB broj za svaku rutu. Autentificirano izvješće koje obavlja stvarno računanje neće se ponašati kao predmemorirani blog post.

Nemojte koristiti prosječni TTFB kao jedinu metriku. Percentili su važni. Geografija je važna. Tip stranice je važan.

Nemojte pretpostaviti da CDN znači da je vaš HTML predmemoriran. Provjerite.

I nemojte tretirati TTFB odvojeno od produktnih odluka. Personalizacija, eksperimentiranje, zalihe u stvarnom vremenu i usluge trećih strana imaju cijenu latencije. Neke se isplate. Neke su samo navika.

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

💡 Isprobajte ovo: Pri dijagnosticiranju TTFB-a, Get Headers otkriva status predmemorije, vremena poslužitelja i preusmjeravanja koja često objašnjavaju odakle dolazi kašnjenje.

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

Smirena verzija plana

Spor TTFB obično je popravljiv kada ga prestanete tretirati kao nejasan “problem poslužitelja”. Izmjerite zahtjev za dokument. Segmentirajte po regiji i tipu stranice. Pregledajte zaglavlja. Usporedite vrijeme klijenta s vremenom origina. Zatim popravite najveće potvrđeno usko grlo.

Većini web-lokacija ne treba egzotična arhitektura. Treba im manje izbježnih promašaja predmemorije, manje blokirajućeg backend rada, čišća preusmjeravanja i jasnija ideja o tome što se mora dogoditi prije slanja prvog bajta.