Šta je to TTFB („time to first byte“), tj. vreme do prvog bajta?
- To je vreme čekanja da pretraživač primi prvi komad informacije od veb servera od kojeg ga je zatražio
- TTFB znači „Time To First Byte“, vreme do prvog bajta
- Može da dovede do primetnog kašnjenja u predstavljanju veb stranice
- Predstavlja kombinaciju uticaja brzine mreže i pitanja stranice na serverskoj strani
Kašnjenja mogu da nastaju od trenutka kada pretraživač napravi zahtev do trenutka kada pretraživač primi odgovor. Ta kašnjenja se sabiraju, pa je TTFB mera koju možemo da koristimo za utvrđivanje ozbiljnosti svih tih kašnjenja.
Koji su uzroci sporih TTFB-a?
U načelu, postoje četiri glavna uzroka za spor TTFB:
- pitanja mreže
- pravljenje dinamičkog sadržaja
- konfigurisanje veb servera
- količina saobraćaja
Kako ubrzati TTFB
Prvi korak je da se optimizuje ono što se lako kontroliše. Vi kontrolišete:
- pravljenje dinamičkog sadržaja
- konfigurisanje veb servera
Teže možete da kontrolišete:
- pitanja mreže
- količinu saobraćaja
Dobro je to da ako se pobrinete za ono što možete da kontrolišete, reagovanje vašeg veb servera (i njegov TTFB) biće bolje u situacijama koje ne kontrolišete.
Pravljenje dinamičkog sadržaja
Čekaj Izvini, Sačekaj sekundu, dve |
Najčešći razlog za sporo TTFB vreme je pravljenje dinamičkog sadržaja. Kada veb server obezbeđuje dinamički sadržaj (kao što je WordPress stranica) između trenutka kada on primi zahtev i trenutka kada pruži odgovor mora da se desi nekoliko stvari. Najbolji način da se to ilustruje je da se opiše razlika između statičkih fajlova i dinamičkog sadržaja.
Statički: Daj mi ovo Važi, evo ga Dinamički: Daj mi tu veb stranicu, Sačekaj da ti je napravim, baza podataka |
- Kada pretraživač zatraži statički fajl, server može trenutno da pošalje taj fajl kao odgovor.
- Kada pretraživač zatraži dinamički fajl, server mora da napravi fajl da bi ga vratio pretraživaču kao odgovor.
WordPress stranice su dinamičke. To znači da moraju da se naprave tako što se uzmu php fajlovi i vrše upiti u bazu podataka.
Često je veliki deo TTFB-a vreme potrebno da se napravi ili dogradi stranica |
To može da znači na stotine, pa čak i na hiljade interakcija samo da bi se napravila jedna stranica. To se događa svaki put kada pretraživač zatraži tu stranicu, čak i ako se sadržaj stranice nije promenio. Ovaj proces produžava vaš TTFB i usporava ga (ponekad taj proces traje sekundu ili više).
Spori TTFB i WordPress
Glavni način da se to ispravi na sajtovima koji koriste WordPress je da napravite keširane verzije svojih stranica.
Keširanje statičkih verzija vaših WordPress stranica
Gore pomenuti deo „pravljenja stranice“ dešava se svaki put kada neki pretraživač zatraži stranicu.
Šta kad ne bismo čekali da je pretraživač zatraži? Šta kad bismo unapred napravili stranicu tako da nam HTML bude spreman za pretraživač čim mu zatreba?
Daj mi ovu veb stranicu Bez keširanja: Treba mi sekund, dva Sa keširanjem: U redu, evo je |
To se zove keširanje, a uglavnom se postiže na jedan od sledeća dva načina:
- Instaliranje dodatka za keširanje
- Upotreba WordPress hostinga koji pruža uslugu keširanja
Instaliranje dodatka za keširanje
Probajte W3 Total Cache ili WP Super Cache ili potražite kroz Google pojam „wp caching plugins“. Dodatke za WordPress keširanje morate neko vreme da učite i imaju nekoliko opcija za konfigurisanje, ali kad ih jednom savladate mogu da budu veoma efikasni.
Upotreba WordPress hostinga koji pruža uslugu keširanja
Ako se koristi kvalitetno WordPress hostiranje problem je rešen čim se prebacite na njih. Pokušajte da nađete neki dobar, kao što je WP Engine koji nudi automatsko keširanje i zaštitu od budućih grešaka konfigurisanja i drugih stvari koje se događaju nadobudnim urednicima veb stranica (kao što je instaliranje dodataka koji pokvare brzinu vaših stranica).
Konfigurisanje veb servera
Sledeće područje nad kojim imate kontrolu je izbor veb servera i njegovo konfigurisanje. Kada kažem veb server, ne mislim na računar već na softver koji on koristi (Apache, NGINX, IIS, Litespeed, itd.). Opisaćemo samo jedan primer konfigurisanja veb servera, ali to je najčešće pitanje.
Apache fajl .htaccess
Na Apache serverima je fajl .htaccess glavni razlog za loš TTFB. Fajl .htaccess je prikladan način za konfigurisanje servera. U stvari je toliko prikladan da se često koristi i kada ne bi trebalo. Fajl .htaccess je jedan veb fajl koji, ako je prisutan, može da se koristi za davanje serveru uputstava kako da postupa. Ovaj fajl se često koristi za pravljenje preusmeravanja i modula mod_rewrite, za dodavanje zaglavlja, itd.
Problem je u tome što .htaccess ozbiljno utiče na performanse
Zvanična Apache dokumentacija kaže:
However, in general, use of .htaccess files should be avoided when possible. Any configuration that you would consider putting in a .htaccess file, can just as effectively be made in a (Međutim, uglavnom bi trebalo izbegavati .htaccess fajlove kad god je to moguće. Svako konfigurisanje koje biste stavili u .htaccess fajl može isto tako efikasno da se izvrši u odeljku |
Apache dodatno ističe razne probleme performansi do kojih dolazi zbog toga što se koristi .htaccess:
– „httpd will look in every directory for .htaccess files. Thus, permitting .htaccess files causes a performance hit, whether or not you actually even use them! Also, the .htaccess file is loaded every time a document is requested. („httpd traži .htaccess fajlove u svim direktorijumima. Prema tome, ako dozvolite .htaccess fajlove to utiče na performanse, bez obzira na to da li ih uopšte koristite! Osim toga, fajl .htaccess se učitava svaki put kad se zatraži neki dokument.) – „In the case of RewriteRule directives, in .htaccess context these regular expressions must be re-compiled with every request to the directory, whereas in main server configuration context they are compiled once and cached. Additionally, the rules themselves are more complicated, as one must work around the restrictions that come with per-directory context and mod_rewrite.“ („U slučaju direktiva RewriteRule, u kontekstu fajla .htaccess ti regularni izrazi moraju da se prevedu za svaki zahtev prema direktorijumu, dok se u kontekstu glavnog konfigurisanja servera prevedu samo jednom i keširaju. Pored toga, sama pravila su složenija, pošto morate da zaobiđete ograničenja u kontekstu pojedinačnih direktorijuma i za mod_rewrite.“) |
Već sama prethodna dva pitanja mogu da dovedu do ozbiljnih TTFB kašnjenja. Takođe, ako uzmemo u obzir veliku ulogu koju mod_rewrite može da ima u tipičnom WordPress sajtu, možemo da zamislimo koliko situacija može da se pogorša.
Koji god veb server da koristite, povedite računa da imate najnoviju verziju i da primenjujete oprobane tehnike
Često već samo ažuriranje softvera popravi TTFB.
PHP
Za php je posebno važno ažuriranje na najnoviju verziju pošto svako od poslednjih nekoliko ažuriranja sadrži važna unapređenja performansi. Isti skript se izvršava sporije na starijoj php verziji nego na novijoj verziji.
A sada ono što nismo mogli da kontrolišemo
Na početku ovog članka sam pomenuo četiri stvari koje utiču na TTFB.
Ono što lako kontrolišete je:
- pravljenje dinamičkog sadržaja
- konfigurisanje veb servera
Ono što teže možete da kontrolišete je:
- količina saobraćaja
- pitanja mreže
Ako ste smanjili svoj TTFB, vi u stvari ipak donekle „kontrolišete“ i pitanje saobraćaja.
Saobraćaj
Ako je vaš TTFB i sveukupan rad servera bio spor, to je uticalo na količinu saobraćaja koju je vaš server mogao da podnese. Ako unapredite način na koji vaš server upravlja pravljenjem dinamičkog sadržaja i konfigurisanjem servera, moći ćete bolje da izlazite na kraj sa većom količinom saobraćaja koristeći isti hardver.
Šta je to prosečan TTFB?
Teško je odrediti tačan broj zato što postoji mnogo različitih scenarija, ali uopšteno govoreći za moderan veb sajt i pod pretpostavkom da se stranica testira iz istog opšteg geografskog regiona gde je stranica hostovana:
- manje od 100 milisekundi je sjajno
- 200 milisekundi je idealno
- 500 milisekundi nije idealno
- 1 sekunda je loše
- 2 sekunde ili više je veoma loše
Što ste udaljeniji od stranice koju tesirate TTFB će biti duži zbog latencije.
Kao primer, Google.com ima TTFB od ~100 milisekundi, početna stranica Računarskog fakulteta ima TTFB od ~239 milisekunde.
Google je izjavio da veb serveri treba da imaju serversko vreme odgovora od 200 milisekundi ili manje.