Ce timp de răspuns al serverului e bun pentru un magazin Magento?

Un client apasă pe un produs. Înainte să apară un titlu, o poză sau un preț, telefonul lui așteaptă primul răspuns de la serverul tău. Așteptarea aceasta are un nume: timpul de răspuns al serverului, sau TTFB (Time to First Byte, timpul până la primul byte). Google are o cifră clară pentru ea: 0,8 secunde sau mai puțin.

Mai jos găsești ce măsoară cifra, de ce aceeași cifră arată diferit pe pagini diferite, de ce clienții reali văd altceva decât un test și cum îți verifici singur magazinul, în zece minute.

Ce este, de fapt, „primul byte”

Gândește-te la o comandă la ghișeu. TTFB nu este timpul până primești mâncarea. Este timpul până când omul de la ghișeu îți spune primul cuvânt.

Google descrie TTFB pe web.dev ca suma câtorva etape:

• eventualele redirecționări (de exemplu de la magazin.ro la www.magazin.ro);
• căutarea adresei (DNS);
• deschiderea conexiunii securizate;
• cererea propriu-zisă, până sosește primul byte al răspunsului.

Ultima etapă e cea în care lucrează Magento: rulează codul, modulele și interogările din baza de date ca să construiască pagina. Pe un magazin lent, aici se pierde aproape tot timpul.

Contează pentru că totul vine după el. Textul, imaginile și butoanele nu pot începe să apară înainte de primul byte. Un server care răspunde în 3 secunde adaugă acele 3 secunde la orice altă cifră a paginii.

Ce spune Google: 0,8 secunde sau mai puțin

Pe web.dev, Google scrie că un TTFB bun este de 0,8 secunde sau mai puțin, iar unul slab trece de 1,8 secunde. Tot acolo numește pragurile „un ghid aproximativ”.

Două lucruri merită știute înainte să te sperii de o cifră:

• TTFB nu este un Core Web Vital. Google scrie că nu e absolut necesar ca un site să atingă pragul „bun”, atâta timp cât asta nu îl împiedică să aibă rezultate bune la cifrele care contează, adică Core Web Vitals.
• Pragul are un scop. Google îl leagă de primul conținut afișat: serverul ar trebui să răspundă destul de repede încât 3 din 4 vizite (percentila 75) să vadă primul conținut în limita „bună”.

Pe scurt: TTFB nu îți dă o notă de la Google, dar e primul pas din cifrele care contează pentru notă. Pe Magento, un TTFB mare e aproape mereu semnul că serverul construiește prea mult pentru fiecare pagină.

De ce pagina principală și o pagină din cache dau cifre diferite

Un magazin Magento bine pus la punct răspunde în două feluri.

Din cache. Varnish, cache-ul paginilor, păstrează o copie gata făcută a paginii. Când vine următorul client, o trimite direct, fără să pornească Magento și fără să atingă baza de date. Răspunsul vine în milisecunde.

Construită de la zero. Când pagina nu e în cache (prima vizită după o modificare, o pagină rar deschisă, un cache care nu funcționează), Magento o construiește din nou. Durata depinde de cât de multă muncă pune magazinul în fiecare pagină.

Exemplul nostru cel mai cunoscut arată ambele situații. La Vitacom, răspunsul serverului a coborât de la 15.814 ms la 12 ms, în teste de viteză pe magazinul live. Cu acest proiect am câștigat Best Performance Improvement la HIVE Germany 2026. Dar cele două cifre nu vin de pe aceeași pagină, și îți spunem asta deschis:

• 15.814 ms a fost pagina principală, construită de serverul vechi, într-un test din februarie 2026;
• 12 ms este o pagină de produs servită de Varnish din cache, după reconstrucție;
• amândouă sunt teste unice, iar testul de după nu are dată.

Pagini diferite, deci. Ce au în comun: amândouă măsoară cât așteaptă un client primul byte, pe magazinul live. Diferența uriașă vine din faptul că pe serverul vechi Varnish era instalat, dar ocolit, așa că fiecare pagină se construia de la zero.

Lecția pentru propriul magazin: o comparație corectă folosește aceeași pagină, înainte și după. Am scris despre asta în Cinci întrebări pentru orice „înainte și după” de viteză.

Clienți reali sau o vizită de test

Aceeași pagină poate avea două valori de TTFB, amândouă corecte.

O vizită de test. PageSpeed Insights și alte instrumente încarcă pagina o dată, dintr-un centru de date, la momentul în care apeși butonul. Vezi cât de repede răspunde serverul pe acel drum, în acel moment. Rulează testul din nou și cifra se mișcă.

Clienții reali. Partea de sus a raportului PageSpeed Insights vine din Chrome UX Report: vizite reale din Chrome, din ultimele 28 de zile, la percentila 75. Aici intră și rețeaua fiecărui client, telefonul lui și distanța până la server. De aceea cifra clienților reali e mai mare decât cea a unui test, chiar pe un magazin rapid.

Un exemplu cu cifre reale: la Equitana, după mutarea de pe Magento 1 pe Magento 2 cu Hyvä, TTFB-ul pe telefon, la clienții reali, a scăzut de la 3.653 ms la 344 ms. Fereastra de dinainte merge de la 19 iulie la 15 august 2026, ultimele 28 de zile complet pe Magento 1. Cea de după, de la 30 august la 26 septembrie 2026. Cu 344 ms, magazinul stă confortabil sub pragul de 0,8 secunde al Google, pentru clienți reali, pe telefon. Povestea mutării este în Încă pe Magento 1 în 2026? Equitana s-a mutat în cinci zile.

Același magazin, într-o vizită de test: pe aceleași pagini, serverul Equitana răspunde acum în 15 până la 18 ms, față de 940 până la 5.180 ms înainte de mutare. Diferența dintre 18 ms și 344 ms ține de partea clientului: rețeaua telefonului, stabilirea conexiunii și drumul dus-întors.

Când cineva îți arată o cifră de TTFB, întreabă mai întâi: vizită de test sau clienți reali?

Cum îți verifici singur magazinul

Ai nevoie de Chrome și de zece minute.

1. Deschide PageSpeed Insights pentru pagina principală, o categorie și un produs. În partea de sus, la datele clienților reali, caută „Time to First Byte (TTFB)”. Sub 0,8 s este bine. Dacă apare „no data”, magazinul are prea puține vizite din Chrome ca Google să publice cifra. Asta nu e un eșec.
2. Uită-te dacă datele sunt ale paginii sau ale întregului site. Când pagina are prea puține vizite, PageSpeed Insights arată cifra pentru tot site-ul.
3. Citește vizita de test de mai jos pentru aceeași pagină. Lista de diagnostice arată cât a durat răspunsul serverului în acel test. Rulează-l de câteva ori și notează cea mai mică și cea mai mare valoare.
4. Încarcă aceeași pagină de produs de două ori, ca vizitator neautentificat. Dacă și a doua oară răspunsul durează secunde, pagina nu vine din cache.
5. Compară corect. Aceeași pagină, același instrument, cu data notată, înainte și după orice modificare.

Dacă pagina principală, categoria și produsul au cifre foarte diferite, aproape sigur unele vin din cache și altele nu. Acolo începe munca.

Pe Magento și Hyvä

Liquid Framework, acceleratorul nostru Hyvä, lucrează exact la așteptarea dinaintea primului byte: clienții primesc pagini gata făcute din cache, nu pagini construite de la zero, iar pagina următoare poate începe să se încarce înainte de click.

La Equitana, care rulează pe Liquid Framework, 53% din vizualizările de pagină pe telefon se deschid instant: 26,7% sunt preîncărcate, iar 25,9% vin din cache-ul înainte/înapoi al browserului. Înainte, pe Magento 1, ambele erau 0%.

Nu știi dacă magazinul tău răspunde din cache sau construiește fiecare pagină de la zero? Programează un apel de strategie gratuit, de 30 de minute. Ne uităm împreună la cifrele tale și îți spunem de unde începem.