Tovább a tartalomhoz

Első bájt (TTFB)

A teszt azt méri, mennyi idő után kezd válaszolni a szerver a nyitóoldalra; 600 ms felett hiba, javítás főleg oldal-gyorsítótárral és gyorsabb tárhellyel.

A TTFB (Time to First Byte, első bájt ideje) azt mutatja meg, mennyit vár a látogató azután, hogy kérte az oldalt, és mielőtt a szerver válasza megérkezne. Amíg ez az idő nem telik el, a böngésző semmit nem tud kirajzolni. A web.dev szerint a dokumentumkérésnél a TTFB minden más betöltési mérőszám előtt jön, tehát ami lassítja, az lassítja az egész betöltést. Maga a TTFB nem Core Web Vitals mutató.

A riport a nyitóoldalt egyszer lekéri a mérő szerverről, és méri, mennyi idő telik el a kérés indítása és a válasz fejlécének megérkezése között. Ha az oldal átirányít, az utolsó, tényleges oldalra irányuló kérés ideje számít. Az érték ezért a mérő szerver és a te szervered közti távolságtól is függ.

  • Megfelelő: 600 ms vagy kevesebb.
  • Hiba (közepes súlyosság): 600 ms felett, 1800 ms-ig.
  • Hiba (magas súlyosság): 1800 ms felett.

Egyetlen mérésből dolgozunk, ezért egy-egy lassú kiugrás is látszhat. Ha bizonytalan vagy, mérd újra néhányszor.

Nincs egyetlen kód, ami a TTFB-t javítja: az ok mindig az, hogy a szerver sokáig készíti el a választ, vagy messze van. Ezeket érdemes sorra venni:

  1. Oldal-gyorsítótár. A legnagyobb hatású lépés, hogy a szerver ne építse fel minden látogatásra újra az oldalt. Lásd az Oldal-gyorsítótár oldalt.
  2. CDN. A látogatóhoz közeli kiszolgálás lerövidíti az utat. Lásd a CDN oldalt.
  3. Átirányítások csökkentése. A web.dev szerint a valódi látogatóknál az átirányítások is hozzáadódnak a TTFB-hez, a labormérés viszont a végső címet méri, ezért ezt nem látja. A riport is csak az utolsó kérést méri, tehát a láncot az Átirányítások száma teszt nézi.
  4. Lassú szerveroldali munka. Nehéz adatbázis-lekérdezések, lassú bővítmények vagy kevés szerver-erőforrás. A web.dev a Server-Timing fejléc használatát javasolja, hogy lásd, a válaszidő melyik részét viszi el az adatbázis, a renderelés vagy a gyorsítótár.
  5. Tárhely. Ha az előzők után is lassú a válasz, a szerver kapacitása lehet a szűk keresztmetszet.

WordPressben a leggyakoribb ok, hogy minden kérésre lefut a PHP és az adatbázis-lekérdezések sora. A WordPress hivatalos teljesítmény-útmutatója szerint a leggyorsabb haszon a gyorsítótárazásból jön (a „Caching” fejezetet kínálja gyors megoldásként). Emellett nézd át, mely bővítmények lassítják a kiszolgálást,.

Futtasd újra a riportot. A TTFB-t parancssorból is megmérheted:

Terminál
curl -o /dev/null -s -w "TTFB: %{time_starttransfer} s\n" https://pelda.hu/

A time_starttransfer a kapcsolatfelépítést is tartalmazza, ezért kicsit nagyobb, mint a tiszta szerver-válaszidő. Futtasd többször, és gyorsítótár-bypass nélkül és azzal is nézd meg. A PageSpeed Insights a valódi látogatók mért adatait is megmutatja, ha az oldalnak van elég forgalma.

Készült:

Tiszteletben tartjuk a magánszférádat

Sütiket használunk a böngészési élmény javítására és a forgalom elemzésére. Az analitika csak akkor indul, ha engeded. Adatvédelmi irányelvek, Sütitájékoztató.

Sütibeállítások