Zašto je vaš Time to First Byte spor i šta da uradite povodom toga

Počnite od toga šta TTFB zapravo meri

Time to First Byte, obično skraćeno kao TTFB, jeste vreme između trenutka kada browser zatraži resurs i trenutka kada primi prvi bajt odgovora.

To zvuči kao serverska metrika, ali nije samo serverska metrika. TTFB obuhvata nekoliko koraka:

• DNS lookup, ako hostname nije već razrešen
• Uspostavljanje TCP veze
• TLS pregovaranje za HTTPS
• Putovanje zahteva do servera ili CDN edge-a
• Čekanje u redu i obrada na serveru
• Putovanje odgovora nazad do browsera

Zato visok TTFB može da znači da je vaš backend spor. Može da znači i da je korisnik daleko od vašeg origin servera, da je CDN pogrešno konfigurisan, da keš stalno promašuje ili da server predugo odlučuje šta da pošalje.

Ovo je važno zato što je TTFB blizu početka lanca učitavanja. Ako HTML dokument stigne kasno, browser kasno otkriva i CSS, JavaScript, fontove i slike. Možete imati odličnu front-end optimizaciju, a da sajt i dalje deluje sporo ako prvi odgovor dokumenta traje 1,5 sekundi.

Šta se smatra sporim TTFB-om?

Ne postoji univerzalan broj koji odgovara svakom sajtu, regionu i arhitekturi. Ipak, praktični pragovi pomažu.

Google-ove web.dev smernice klasifikuju dobar TTFB kao vrednost ispod 800 ms, dok 800–1800 ms zahteva poboljšanje, a iznad 1800 ms se smatra lošim. Za dobro keširanu marketinšku stranicu serviranu blizu korisnika često možete postići mnogo bolje od toga. Za složenu autentifikovanu kontrolnu tablu koja obavlja dinamički rad, prihvatljiv broj može biti viši, ali i dalje treba da bude objašnjiv.

Važna navika je da segmentirate broj. Globalni prosečni TTFB od 900 ms može da sakrije odgovor od 150 ms za korisnike blizu vašeg CDN edge-a i odgovor od 2200 ms za korisnike u drugom regionu. Isto tako, početna stranica može biti u redu, dok su pretraga, kategorije ili stranice za prijavljene korisnike tiho bolne.

Merite ga na više mesta

Nemojte dijagnostikovati TTFB na osnovu jednog Lighthouse pokretanja. Lighthouse je koristan, ali to je jedan test iz jednog okruženja. Ako tek učite da ga tumačite, počnite smirenim čitanjem o tome kako čitati Lighthouse izveštaj bez panike — glavna lekcija je da odvojite laboratorijske signale od stvarnosti na terenu.

Za TTFB želite najmanje tri pogleda:

1. Browser developer tools

Otvorite Network panel, ponovo učitajte stranicu sa onemogućenim kešom i pregledajte zahtev glavnog dokumenta. Vremenska razrada prikazuje DNS, vezu, TLS, čekanje i faze preuzimanja. Faza „waiting” je često ono na šta ljudi misle pod backend vremenom, mada može uključivati i upstream latenciju.

2. Sintetički testovi iz više regiona

Pokrenite testove sa lokacija koje su blizu i daleko od vaših korisnika. Ako je TTFB nizak u jednom regionu, a visok u drugom, posumnjajte na geografiju, CDN rutiranje, poziciju origin servera ili pokrivenost keša pre nego što krenete da prepisujete aplikacioni kod.

3. Real user monitoring ili serverski logovi

Podaci sa terena pokazuju šta stvarni korisnici doživljavaju na različitim uređajima, mrežama i sesijama. Serverski logovi mogu da pokažu da li je origin brzo generisao odgovor. Razlika između TTFB-a koji vidi klijent i vremena obrade na originu često je mesto gde se pojavljuju CDN i mrežni problemi.

Uobičajeni uzroci sporog TTFB-a

Vaš HTML se ne kešira

Ovo je najčešći problem na sadržajnim i ecommerce sajtovima. Statički resursi se agresivno keširaju, ali HTML dokument — ono što browseru treba prvo — generiše se pri svakom zahtevu.

Ponekad je to neophodno. Često nije.

Ako se javna stranica menja nekoliko puta dnevno, verovatno ne bi trebalo da zahteva sveže renderovanje iz baze podataka za svakog anonimnog posetioca. Koristite full-page caching, edge caching, static generation ili stale-while-revalidate obrasce tamo gde je prikladno.

Proverite response headers za signale kao što su Cache-Control, CDN-Cache-Status, Age, Vary i Set-Cookie. Stranica koja šalje jedinstveni cookie svakom posetiocu može slučajno da učini samu sebe nemogućom za keširanje. Ako vam treba praktičan način da razmišljate o ovom sloju, iste navike za otklanjanje grešaka iz našeg vodiča za redirects i HTTP headers u produkciji direktno se primenjuju na rad na TTFB-u.

Vaš CDN kešira samo assete

Mnogi timovi dodaju CDN i pretpostave da je posao oko performansi završen. Ali ako CDN servira samo slike, CSS i JavaScript, prvi HTML zahtev i dalje može da putuje sve do jednog origin servera.

To može biti u redu za lokalni poslovni sajt sa lokalnim korisnicima. Nije u redu za međunarodnu publiku. Što je korisnik dalje od origina, to više latencije plaćate pre nego što backend rad uopšte počne.

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

• Keširajte javni HTML tamo gde je bezbedno
• Poštujte namerna pravila za zaobilaženje keša za autentifikovane ili personalizovane stranice
• Izbegavajte nepotrebne Vary headers koji previše sitno dele keš
• Koristite cache purging ili revalidation umesto potpunog isključivanja keša
• Potvrdite da edge lokacije zaista serviraju hitove, a ne prosleđuju svaki zahtev

CDN nije magija. To je sloj za keširanje i rutiranje. Tako ga i tretirajte.

Vaš server radi previše pre odgovora

Spor backend put može nastati iz mnogo malih kašnjenja: upiti ka bazi, API pozivi, renderovanje šablona, provere feature flag-ova, autentifikacija, personalizacija, logovanje i cold starts.

Najgori obrazac je serijski rad zavisnosti. Na primer:

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

Ako svaki korak čeka prethodni, TTFB brzo raste. Paralelizujte nezavisan rad, uklonite nekritične pozive iz prvog odgovora i keširajte skupe rezultate.

Korisno pravilo: ako korisnik ne može odmah da vidi ili koristi rezultat, verovatno ne bi trebalo da blokira prvi bajt.

Upiti ka bazi podataka su spori ili nepredvidivi

Baze podataka često izazivaju TTFB probleme zato što se dobro ponašaju u razvoju, a loše pod stvarnim saobraćajem. Nedostajući indeksi, veliki join-ovi, N+1 upiti, lock contention i preveliki skupovi rezultata svi se pojavljuju kao „server je spor”.

Ovde nemojte nagađati. Zabeležite trajanja upita za spore zahteve. Gledajte p95 i p99, ne samo proseke. Jedna stranica koja obično odgovara za 120 ms, ali povremeno blokira 4 sekunde, i dalje će stvoriti loše korisničko iskustvo.

Uobičajene popravke uključuju:

• Dodavanje ili ispravljanje indeksa
• Uklanjanje N+1 obrazaca upita
• Keširanje podataka koji se mnogo čitaju
• Paginaciju velikih upita
• Premeštanje reporting ili analytics upita van vremena zahteva
• Postavljanje razumnih timeout-a za downstream pozive

Vaša aplikacija ima cold starts

Serverless i kontejnerizovane platforme mogu biti odlične, ali cold starts mogu da pogoršaju TTFB kada je saobraćaj skokovit ili su regioni nedovoljno provisioned.

Ako je prvi zahtev posle perioda neaktivnosti mnogo sporiji od kasnijih zahteva, istražite cold starts. Možda su vam potrebni provisioned concurrency, manji bundle-ovi, manje zavisnosti pri pokretanju, warmer functions ili drugačiji oblik deployment-a za rute osetljive na latenciju.

Ovo nije argument protiv serverless-a. To je argument protiv pretvaranja da je runtime model nevidljiv.

Redirects troše prvi zahtev

Redirect dodaje još jedan ciklus zahtev-odgovor pre nego što browser primi konačni dokument. Jedan redirect sa http:// na https:// može biti neizbežan za stare linkove, ali lanci su rasipanje.

Uobičajeni lanci uključuju:

• http://example.com → https://example.com → https://www.example.com
• normalizaciju trailing slash-a posle normalizacije protokola
• geo ili jezičke redirects pre provere keša
• stare campaign linkove koji preskaču kroz više URL-ova

Popravite izvorne linkove gde je moguće, spojite redirect pravila i učinite canonical URL-ove direktnim. Vreme redirect-a se ne prijavljuje uvek kao TTFB za konačni zahtev, ali korisnik ga i dalje plaća.

Praktičan redosled za debugging

Kada TTFB deluje sporo, koristite ovaj redosled. On izbegava čestu grešku optimizacije aplikacionog koda pre potvrde ponašanja keša i rutiranja.

Korak 1: Testirajte glavni dokument, ne samo celu stranicu

Pronađite zahtev za HTML dokument. Zabeležite ukupan TTFB i vremensku razradu. Ponovite sa browser kešom i bez njega. Testirajte javnu stranicu, dinamičku stranicu i stranicu za prijavljene korisnike ako je relevantno.

Korak 2: Uporedite regione

Pokrenite isti URL iz nekoliko geografskih lokacija. Ako se spori regioni poklapaju sa udaljenošću od origina, prioritizujte CDN i edge caching. Ako je svaki region spor, pogledajte backend obradu i kapacitet origina.

Korak 3: Pregledajte response headers

Tražite cache headers, cookies, Age, CDN status i Vary. Nedostajući Age header ili ponovljeni promašaji keša su tragovi. Širok Vary: Cookie header na javnom HTML-u često ubija keš.

Korak 4: Proverite origin timing

Dodajte server timing instrumentaciju. Server-Timing header može da izloži backend faze kao što su vreme baze podataka, vreme renderovanja i vreme upstream API-ja. Čak su i jednostavne oznake korisne:

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

Sada vaša browser merenja mogu da pokažu da li je server potrošio 300 ms na stvaran rad ili se kašnjenje dogodilo pre nego što je zahtev stigao do vaše aplikacije.

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

Ovo zvuči očigledno, ali timovi često popravljaju ono što im je poznato, a ne ono što je izmereno. Ako dominiraju promašaji keša, popravite keširanje. Ako dominira baza podataka, popravite upite. Ako TLS i uspostavljanje veze dominiraju za globalne korisnike, popravite rutiranje, CDN pokrivenost ili geografiju origina.

Front-end rad je i dalje važan. Fontovi, slike i JavaScript utiču na ono što se dešava nakon što HTML stigne. Ali oni nisu zamena za brz prvi odgovor. Ako istovremeno radite na performansama renderovanja, web fontovi ostaju jedna od najlakših pobeda na mnogim sajtovima zato što utiču na to koliko brzo tekst postaje upotrebljiv nakon što dokument stigne.

Popravke koje obično rade

Keširajte javni HTML na edge-u

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

Budite pažljivi sa personalizacijom. Ako se stranica razlikuje po valuti, jeziku, stanju prijave ili eksperimentalnoj grupi, eksplicitno definišite te varijante. Slučajna varijacija po korisniku uništava efikasnost keša.

Premestite nekritičan rad van putanje zahteva

Slanje emailova, analytics enrichment, generisanje preporuka, webhook pozivi i teško logovanje retko bi trebalo da blokiraju prvi bajt. Stavite ih u redove ili ih pokrenite nakon što odgovor počne.

Smanjite lance backend zavisnosti

Paralelizujte nezavisne pozive. Keširajte odgovore sporih API-ja. Postavite timeout-e. Dizajnirajte fallback sadržaj za servise koji su korisni, ali nisu neophodni.

Spor widget za preporuke ne bi trebalo da odloži celu stranicu proizvoda.

Premestite compute bliže korisnicima

Ako su vaši korisnici globalni, a origin je u jednom regionu, latencija je strukturna. CDN keširanje može da sakrije veliki deo toga za javni sadržaj. Za dinamički sadržaj razmotrite regionalne deployment-e, edge rendering za pogodne rute ili premeštanje API-ja bliže publici.

Neka redirects budu dosadni

Canonicalizujte URL-ove u jednom skoku. Ažurirajte interne linkove tako da korisnici i crawlers idu direktno do konačnog odredišta. Auditujte stare campaign URL-ove i migracije platforme. Redirects je lako ignorisati jer su nevidljivi kada rade, ali i dalje koštaju vremena.

Šta ne treba raditi

Nemojte juriti savršen TTFB broj za svaku rutu. Autentifikovani izveštaj koji obavlja stvarno računanje neće se ponašati kao keširani blog post.

Nemojte koristiti prosečan 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 keširan. Proverite.

I nemojte tretirati TTFB kao odvojen od proizvodnih odluka. Personalizacija, eksperimentisanje, real-time inventory i servisi trećih strana imaju cenu u latenciji. Neki su vredni toga. Neki su samo navika.

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

💡 Испробајте ово: При дијагностиковању TTFB-а, Get Headers открива статус кеша, серверска времена и преусмеравања која често објашњавају одакле долази кашњење.

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

Smirena verzija plana

Spor TTFB je obično popravljiv kada prestanete da ga tretirate kao nejasan „serverski problem”. Izmerite zahtev dokumenta. Segmentirajte po regionu i tipu stranice. Pregledajte headers. Uporedite klijentsko vreme sa origin vremenom. Zatim popravite najveće potvrđeno usko grlo.

Većini sajtova nije potrebna egzotična arhitektura. Potrebno im je manje izbegljivih promašaja keša, manje blokirajućeg backend rada, čistiji redirects i jasnija ideja šta mora da se dogodi pre nego što se pošalje prvi bajt.