Website-ul pare lent, deși imaginile sunt optimizate și conexiunea la internet funcționează normal? Una dintre valorile care merită verificată este TTFB – Time to First Byte.
TTFB indică timpul necesar până când browserul începe să primească răspunsul pentru o solicitare. Un TTFB ridicat poate indica o întârziere înainte ca pagina să înceapă efectiv să fie transmisă către vizitator.
Pe infrastructura NameBox, unde serviciile de găzduire utilizează cPanel, LiteSpeed și CloudLinux, există mai multe instrumente prin care poți investiga cauza: verificarea cache-ului LiteSpeed, analiza resurselor din cPanel și identificarea proceselor sau activităților care solicită intens contul.
În acest articol explicăm ce este TTFB, ce îl poate influența și cum poți diferenția o problemă de cache, resurse sau aplicație.
Ce este TTFB?
TTFB vine de la Time to First Byte și reprezintă intervalul dintre inițierea unei solicitări și momentul în care browserul primește primul byte al răspunsului.
Pe scurt, browserul solicită o pagină, iar serverul trebuie să proceseze cererea și să înceapă să trimită răspunsul.
Un traseu simplificat poate arăta astfel:
Browser → DNS → conexiune → LiteSpeed → aplicație/PHP → baza de date → răspuns
În funcție de modul în care este măsurat, TTFB poate include și timpul necesar pentru rezolvarea DNS, stabilirea conexiunii și negocierea conexiunii HTTPS, nu doar timpul efectiv de procesare PHP.
De aceea, un TTFB ridicat nu trebuie interpretat automat ca o problemă a serverului.
TTFB nu este același lucru cu timpul total de încărcare
TTFB măsoară doar perioada până la începutul răspunsului. Nu măsoară cât timp durează încărcarea completă a paginii.
De exemplu, un website poate avea un TTFB bun, dar să se încarce lent din cauza:
- imaginilor foarte mari;
- fișierelor JavaScript;
- fișierelor CSS;
- fonturilor externe;
- numeroaselor request-uri către servicii terțe;
- elementelor complexe din pagină.
Este posibilă și situația inversă: pagina poate fi bine optimizată în browser, dar serverul sau aplicația să aibă nevoie de prea mult timp înainte să înceapă să livreze conținutul.
În acest caz, TTFB devine un indicator important pentru investigație.
Ce se întâmplă atunci când accesezi un website?
Pentru a înțelege de unde poate apărea întârzierea, trebuie să urmărim pe scurt ce se întâmplă după introducerea adresei unui website în browser.
Browserul trebuie mai întâi să identifice serverul asociat domeniului prin DNS și să stabilească o conexiune.
Solicitarea ajunge apoi la LiteSpeed Web Server.
Din acest punct există două situații principale:
- pagina poate fi disponibilă în cache și poate fi servită rapid;
- pagina trebuie generată dinamic de aplicație.
Dacă este necesară generarea dinamică, aplicația poate executa cod PHP, poate efectua interogări către baza de date și poate comunica inclusiv cu servicii externe înainte să genereze răspunsul.
Oricare dintre aceste etape poate contribui la creșterea timpului de răspuns.
Cum poate LiteSpeed Cache să influențeze TTFB?
Unul dintre avantajele unui sistem de cache este faptul că pagina nu trebuie generată complet la fiecare accesare.
Dacă website-ul utilizează LiteSpeed Cache și pagina solicitată poate fi cache-uită, LiteSpeed poate servi o versiune deja generată a paginii.
În această situație sunt evitate o parte dintre operațiunile necesare generării dinamice, precum executarea completă a aplicației și anumite interogări către baza de date.
Acest lucru poate reduce considerabil timpul necesar până la începerea răspunsului.
Ce înseamnă Cache HIT și Cache MISS?
Atunci când verifici o pagină care folosește LiteSpeed Cache, poți întâlni două situații importante.
Cache HIT
Un HIT înseamnă că pagina solicitată a fost găsită în cache și a fost servită folosind conținutul deja disponibil.
X-LiteSpeed-Cache: hit
În acest caz, aplicația nu trebuie să reconstruiască integral pagina pentru request-ul respectiv.
Cache MISS
Un MISS înseamnă că răspunsul respectiv nu a fost servit din cache.
X-LiteSpeed-Cache: miss
În acest caz, pagina poate necesita procesare dinamică, iar după generare poate fi stocată în cache dacă regulile aplicației permit acest lucru.
Un singur Cache MISS nu indică automat o problemă. De exemplu, prima accesare după golirea cache-ului poate produce un MISS, iar următoarea solicitare poate fi servită din cache.
Cum verifici dacă LiteSpeed Cache funcționează?
Poți verifica acest lucru direct din browser.
În Google Chrome, Firefox sau alte browsere moderne, deschide instrumentele pentru dezvoltatori și accesează secțiunea Network.
Pașii sunt:
- deschide website-ul;
- deschide Developer Tools;
- accesează secțiunea Network;
- reîncarcă pagina;
- selectează request-ul principal al paginii;
- accesează Headers;
- verifică secțiunea Response Headers.
Dacă pagina este servită din LiteSpeed Cache, poți vedea un header precum:
X-LiteSpeed-Cache: hit
Dacă apare:
X-LiteSpeed-Cache: miss
request-ul respectiv nu a fost servit din cache.
Dacă header-ul nu apare deloc, nu trebuie concluzionat imediat că LiteSpeed nu funcționează. Website-ul poate să nu utilizeze LiteSpeed Cache, pagina poate avea reguli speciale sau configurația aplicației poate determina un alt comportament.
De ce poate fi TTFB mare chiar dacă serverul folosește LiteSpeed?
LiteSpeed poate îmbunătăți semnificativ timpul de răspuns, însă prezența sa nu înseamnă că orice pagină va fi automat servită din cache.
Există numeroase situații în care pagina trebuie procesată dinamic.
Printre cauzele care trebuie investigate se numără:
- pagina nu este eligibilă pentru cache;
- cache-ul tocmai a fost golit;
- aplicația generează răspunsul lent;
- un plugin sau o extensie execută operațiuni costisitoare;
- există interogări lente către baza de date;
- aplicația așteaptă răspunsul unui API extern;
- există importuri sau sincronizări în desfășurare;
- un Cron Job rulează în acel moment;
- contul utilizează intens CPU sau I/O;
- există multe procese simultane;
- website-ul primește un volum ridicat de solicitări.
Prin urmare, un TTFB ridicat trebuie investigat împreună cu comportamentul aplicației și utilizarea resurselor.
Nu toate paginile trebuie să fie cache-uite
Este important să nu urmărești obținerea unui Cache HIT pentru fiecare pagină a website-ului.
Unele pagini conțin informații dinamice sau personalizate și trebuie procesate diferit.
În cazul unui magazin online, pot exista pagini precum:
- coșul de cumpărături;
- checkout-ul;
- contul clientului;
- anumite pagini pentru utilizatori autentificați.
Aceste pagini nu trebuie forțate în cache doar pentru a obține un TTFB mai mic, deoarece conținutul lor poate diferi de la un utilizator la altul.
În cazul paginilor dinamice, obiectivul este optimizarea procesării aplicației și a bazei de date.
Cum verifici resursele website-ului în cPanel?
Pe serverele care utilizează CloudLinux, cPanel oferă o interfață prin care poți analiza consumul de resurse al contului.
Accesează:
cPanel → Metrics → Resource Usage
Din această secțiune poți verifica dacă website-ul se apropie sau ajunge la anumite limite de resurse.
Printre valorile pe care le poți întâlni se numără:
- CPU – puterea de procesare utilizată;
- PMEM – memoria fizică utilizată;
- I/O – viteza operațiunilor de citire și scriere;
- IOPS – numărul operațiunilor de citire și scriere;
- EP – Entry Processes;
- NPROC – numărul proceselor.
Pentru mai multe informații despre această secțiune poți consulta ghidul nostru Monitorizare resurse cPanel.
Cum poate CloudLinux să influențeze timpul de răspuns?
CloudLinux permite controlul și monitorizarea resurselor utilizate de fiecare cont de găzduire.
Este important de precizat că CloudLinux nu trebuie considerat automat cauza unui TTFB mare.
Dacă însă aplicația solicită mai multe resurse decât sunt disponibile în acel moment, anumite limite pot influența timpul necesar procesării request-urilor.
De exemplu, atunci când un cont ajunge la limita CPU, procesarea poate fi încetinită. În cazul limitării I/O, operațiunile de citire și scriere pot necesita mai mult timp.
Dacă aplicația trebuie să execute PHP, să citească numeroase fișiere și să interogheze baza de date înainte să genereze pagina, această întârziere se poate reflecta și într-un TTFB mai mare.
Pentru o explicație mai detaliată despre tehnologie poți consulta articolul Ce este CloudLinux?.
Ce înseamnă Faults în Resource Usage?
În secțiunea Resource Usage poți întâlni și informații despre depășirea anumitor limite.
Aceste evenimente pot apărea sub forma unor Faults.
De exemplu, poți întâlni indicatori asociați cu:
- CPU;
- memorie;
- I/O;
- IOPS;
- Entry Processes;
- numărul de procese.
Dacă website-ul devine lent într-un anumit interval, verifică dacă în aceeași perioadă apar valori ridicate sau Faults în Resource Usage.
Corelarea orei la care apare problema cu istoricul resurselor este mult mai utilă decât verificarea unui singur moment în care site-ul funcționează normal.
TTFB mare doar în anumite momente ale zilei
Dacă website-ul funcționează rapid în general, dar devine lent la anumite ore, cauza poate fi o activitate periodică.
Merită verificate:
- Cron Jobs;
- WP-Cron;
- importurile automate;
- sincronizările de produse sau stocuri;
- generarea feed-urilor;
- operațiunile de backup;
- crawlerele și boții;
- perioadele cu trafic crescut.
De exemplu, dacă website-ul devine lent în fiecare oră la minutul 00, iar în cPanel → Cron Jobs există un proces programat să ruleze la începutul fiecărei ore, acel proces trebuie inclus în investigație.
Pentru mai multe informații despre sarcinile programate poți consulta articolul nostru despre Cron Jobs în cPanel.
Un Cron Job poate crește TTFB-ul?
Da, indirect.
Dacă un Cron Job execută un import mare, procesează numeroase produse sau face multe interogări către baza de date, acesta poate utiliza o parte importantă din resursele contului.
În același timp, vizitatorii website-ului solicită pagini care trebuie procesate de aceeași aplicație.
Dacă activitatea cron-ului crește semnificativ CPU-ul, I/O-ul sau numărul proceselor, paginile dinamice pot necesita mai mult timp pentru a fi generate.
Problema este și mai evidentă atunci când execuțiile cron se suprapun.
TTFB mare doar pe anumite pagini
Dacă homepage-ul răspunde rapid, dar o anumită pagină are constant un TTFB ridicat, este puțin probabil ca problema să fie una generală a întregului cont de găzduire.
Trebuie investigat ce face diferit pagina respectivă.
De exemplu, aceasta poate:
- executa mai multe interogări către baza de date;
- afișa un catalog foarte mare;
- folosi un plugin sau modul suplimentar;
- efectua request-uri către un API extern;
- genera filtre complexe;
- procesa conținut personalizat pentru utilizator.
Comparația dintre o pagină rapidă și una lentă de pe același website este foarte utilă pentru localizarea problemei.
TTFB mare pe paginile dinamice, dar mic pe paginile cache-uite
Acesta este unul dintre cele mai utile scenarii pentru diagnosticare.
Să presupunem că homepage-ul afișează:
X-LiteSpeed-Cache: hit
și răspunde foarte rapid.
În schimb, o pagină dinamică care nu este servită din cache are un TTFB mult mai ridicat.
În această situație, serverul LiteSpeed este capabil să livreze rapid conținutul cache-uit, iar investigația trebuie orientată spre ceea ce se întâmplă în timpul generării dinamice a paginii.
Trebuie analizate în special:
- codul PHP;
- pluginurile sau modulele aplicației;
- interogările bazei de date;
- serviciile externe;
- resursele utilizate în timpul request-ului.
Interogările către baza de date pot crește TTFB-ul
Majoritatea aplicațiilor dinamice au nevoie de baza de date pentru a construi pagina.
Un singur request poate genera numeroase interogări.
Dacă acestea sunt lente, foarte numeroase sau procesează volume mari de date, aplicația va avea nevoie de mai mult timp înainte să poată trimite răspunsul.
Problema poate apărea în special pe website-uri cu:
- cataloage mari de produse;
- filtre complexe;
- multe extensii instalate;
- tabele foarte mari;
- interogări neoptimizate;
- operațiuni automate de import sau sincronizare.
În astfel de cazuri, creșterea resurselor nu ar trebui să fie prima și singura soluție. Trebuie verificat și modul în care aplicația folosește baza de date.
Serviciile externe pot întârzia generarea paginii
Unele website-uri comunică cu servicii externe în timpul generării paginii.
Acestea pot fi:
- API-uri;
- sisteme ERP;
- servicii de plată;
- sisteme de stoc;
- platforme de marketing;
- feed-uri externe.
Dacă aplicația așteaptă răspunsul unui serviciu extern înainte să genereze pagina, întârzierea acelui serviciu poate crește și timpul de răspuns al website-ului.
În această situație, serverul de găzduire poate funcționa normal, iar cauza întârzierii se află în afara infrastructurii de hosting.
Cum îți dai seama dacă problema este de hosting sau de website?
Un singur test TTFB nu este suficient pentru a stabili cauza.
Investigația trebuie făcută prin comparație.
Verifică mai multe pagini
Dacă toate paginile sunt lente în același timp, trebuie verificată utilizarea generală a resurselor și conectivitatea.
Dacă doar o pagină este lentă, investigația trebuie orientată spre funcționalitatea acelei pagini.
Compară paginile cache-uite cu cele dinamice
Dacă paginile servite cu:
X-LiteSpeed-Cache: hit
sunt rapide, dar paginile dinamice sunt lente, aplicația și baza de date trebuie investigate mai atent.
Verifică Resource Usage
Dacă TTFB-ul ridicat apare în același timp cu valori foarte mari sau Faults pentru resursele CloudLinux, există o corelație care merită investigată.
Verifică momentul în care apare problema
Dacă problema apare întotdeauna la aceeași oră, verifică Cron Jobs, importurile, backup-urile și alte operațiuni programate.
Testează în momente diferite
Un singur rezultat nu este suficient. Repetă testul în intervale diferite și compară rezultatele.
Exemplu: TTFB mare, Cache MISS și resurse normale
Să presupunem că o pagină răspunde lent și observi:
X-LiteSpeed-Cache: miss
În același timp, în Resource Usage nu există un consum ridicat de CPU, memorie sau I/O.
În această situație, investigația trebuie orientată mai întâi către aplicație.
Trebuie verificat de ce pagina necesită atât de mult timp pentru a fi generată și dacă este normal ca aceasta să nu fie servită din cache.
Cauza poate fi un plugin lent, o interogare către baza de date sau un request către un serviciu extern.
Exemplu: TTFB mare și CPU sau I/O ridicat
Într-un alt scenariu, website-ul începe să răspundă greu, iar în:
cPanel → Metrics → Resource Usage
observi în același interval o utilizare ridicată a CPU-ului sau I/O-ului.
În acest caz trebuie identificată activitatea care generează consumul.
Poate fi vorba despre:
- trafic crescut;
- un crawler agresiv;
- un import;
- un Cron Job;
- o operațiune de procesare;
- o funcționalitate costisitoare a aplicației.
Doar după identificarea cauzei poți stabili dacă este nevoie de optimizarea website-ului sau de mai multe resurse.
Un pachet mai mare rezolvă întotdeauna TTFB-ul?
Nu.
Dacă website-ul ajunge constant la limitele resurselor din cauza unui volum legitim de trafic sau a unei aplicații care are nevoie efectiv de mai multă putere de procesare, creșterea resurselor poate fi justificată.
În schimb, dacă un plugin execută o interogare neoptimizată sau un Cron Job pornește inutil la fiecare minut, mai multe resurse pot doar să mascheze temporar problema.
Înainte de upgrade trebuie verificat ce consumă resursele.
Pentru o explicație mai detaliată poți consulta articolul Cum alegi resursele unui pachet de găzduire?.
Cum poți reduce TTFB-ul unui website?
Soluția depinde de cauza identificată.
Printre optimizările care pot ajuta se numără:
- configurarea corectă a LiteSpeed Cache;
- folosirea cache-ului pentru paginile care pot fi cache-uite în siguranță;
- optimizarea codului PHP;
- eliminarea pluginurilor sau modulelor inutile;
- optimizarea interogărilor bazei de date;
- optimizarea Cron Jobs;
- evitarea suprapunerii proceselor programate;
- reducerea request-urilor lente către servicii externe;
- investigarea traficului automat și a boților;
- monitorizarea constantă a resurselor în cPanel;
- creșterea resurselor atunci când utilizarea reală o justifică.
Este important ca optimizarea să pornească de la măsurători, nu de la modificări făcute la întâmplare.
TTFB trebuie analizat împreună cu website-ul și resursele sale
Un TTFB ridicat este un semnal că există o întârziere înainte ca browserul să înceapă să primească răspunsul, dar valoarea singură nu spune unde se află problema.
Pe infrastructura NameBox, combinația dintre LiteSpeed, CloudLinux și cPanel oferă mai multe puncte utile de diagnosticare.
Începe prin a verifica dacă pagina este servită din LiteSpeed Cache, apoi analizează Resource Usage pentru intervalul în care apare problema și verifică dacă există Cron Jobs, importuri sau alte procese care rulează simultan.
Dacă paginile cache-uite răspund rapid, resursele sunt în limite normale, iar doar anumite pagini dinamice au TTFB ridicat, investigația trebuie orientată către aplicație, baza de date și serviciile externe utilizate.
Prin corelarea acestor informații poți identifica mult mai precis cauza unui website lent și poți evita modificări sau upgrade-uri care nu rezolvă problema reală.