Time to First Byte

Ce măsoară TTFB

Time to First Byte măsoară intervalul dintre începutul solicitării unei pagini și începutul răspunsului primit de browser. Valoarea este exprimată în milisecunde. Ea poate include căutarea DNS, conexiunea TCP, negocierea TLS pentru HTTPS, redirecționările și timpul necesar serverului pentru a începe răspunsul.

TTFB precedă alte metrici importante pentru experiența utilizatorului, precum First Contentful Paint (FCP) și Largest Contentful Paint (LCP). O valoare mare poate adăuga timp etapelor care urmează. Totuși, TTFB nu face parte din Core Web Vitals. Este o metrică de diagnostic, iar interpretarea sa trebuie corelată cu modul în care site-ul livrează conținutul.

Un site randat pe server poate avea un TTFB mai mare, dar valori FCP și LCP mai bune decât o aplicație care livrează rapid marcajul inițial și depinde apoi de JavaScript pentru conținutul relevant. Din acest motiv, pragurile TTFB sunt orientative. web.dev indică drept reper un TTFB de cel mult 0,8 secunde și consideră slabă o valoare de peste 1,8 secunde.

Date reale și teste de laborator

Datele din teren reflectă experiența utilizatorilor reali și includ efectul redirecționărilor. Testele de laborator pot porni direct de la URL-ul final și pot omite această întârziere. Diferențele pot proveni și din cache-ul serverului, condițiile de rețea sau limitările mediului de testare.

Auditul privind timpul de răspuns al serverului din Lighthouse exclude căutarea DNS și redirecționările. Prin urmare, acesta reprezintă doar o parte din TTFB.

Rolul în SEO clasic

TTFB contează deoarece apare înaintea afișării conținutului. O întârziere în răspunsul inițial poate adăuga timp metricilor ulterioare, inclusiv FCP și LCP. LCP face parte din Core Web Vitals, dar TTFB nu face parte din acest set. Optimizarea nu trebuie făcută izolat, ci în raport cu felul în care pagina este randată și cu valorile care descriu experiența efectivă.

TTFB ajută la identificarea problemelor legate de redirecționări, cache pe server, rețea, interogări către baza de date, randare pe server, acces la disc și utilizarea unui CDN. Pentru site-urile WordPress, numărul și calitatea pluginurilor sau tema utilizată pot influența performanța platformei.

Vizibilitatea în motoarele AI

Extrasele oficiale furnizate nu stabilesc TTFB drept semnal direct pentru includerea, citarea sau poziționarea conținutului în AI Overviews, AI Mode, ChatGPT, Perplexity ori Gemini. Nu poate fi promisă o creștere a vizibilității în aceste sisteme prin simpla reducere a TTFB.

Relevanța pentru GEO și LLM trebuie tratată indirect. TTFB face parte din livrarea tehnică a paginii și poate întârzia metricile care urmează, dar sursele prezentate nu descriu un mecanism separat prin care această metrică determină selecția unei surse de către motoarele AI. Prioritatea practică rămâne diagnosticarea livrării paginii și evaluarea sa împreună cu FCP, LCP și modul de randare.

Un magazin online românesc testează pagina unei categorii în PageSpeed Insights. Datele utilizatorilor reali arată un TTFB mai mare decât testul de laborator.

Echipa verifică traseul vizitatorilor și constată că unele accesări trec printr-o redirecționare. Testează apoi o pagină mai puțin accesată și un URL cu parametri diferiți pentru a vedea dacă rezultatul este influențat de cache-ul serverului. Pentru separarea timpului petrecut în baza de date de timpul de randare pe server, backendul poate trimite antetul:

Server-Timing: db;desc="Bază de date";dur=121.3, ssr;desc="Randare pe server";dur=212.2

Valorile pot fi analizate în panourile Network și Performance din Chrome DevTools. Exemplul arată de ce TTFB trebuie investigat pe componente, nu tratat doar ca o valoare agregată.

1. Deschide URL-ul public în PageSpeed Insights.
2. Verifică TTFB în secțiunea cu experiența utilizatorilor reali, dacă pagina este disponibilă în Chrome User Experience Report.
3. Consultă informația „Document request latency” pentru rezultatul de laborator.
4. Compară datele din teren cu cele de laborator. O diferență poate indica redirecționări, cache pe server, condiții de rețea sau constrângeri ale mediului de testare.
5. În Chrome DevTools, deschide panoul Network, păstrează înregistrarea activă și reîncarcă pagina.
6. Activează „Disable cache” pentru a simula un vizitator care nu beneficiază de cache-ul browserului.
7. Pentru o măsurare în browser, citește responseStart din PerformanceNavigationTiming:

const ttfb = performance.getEntriesByType("navigation")[0].responseStart;

8. Dacă backendul trimite antetul Server-Timing, verifică procesele raportate în panourile Network sau Performance din Chrome DevTools.

1. Analizează mai întâi datele utilizatorilor reali și apoi folosește testele de laborator pentru diagnostic.
2. Verifică redirecționările înainte de a atribui întreaga întârziere serverului final.
3. Compară răspunsurile cu și fără cache pentru a identifica efectul cache-ului de pe server.
4. Folosește Server-Timing sau o soluție APM pentru a separa interogările bazei de date, randarea pe server, accesul la disc și operațiunile CDN.
5. Evaluează dacă serviciul de găzduire poate gestiona traficul primit de site.
6. Pentru WordPress, analizează pluginurile și tema și consultă recomandările specifice platformei.
7. Corelează TTFB cu FCP și LCP înainte de a decide ce intervenție are prioritate.