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ó.
Hogyan mérjük
Szekció neve “Hogyan mérjük”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.
Hogyan javítsd
Szekció neve “Hogyan javítsd”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:
- 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.
- CDN. A látogatóhoz közeli kiszolgálás lerövidíti az utat. Lásd a CDN oldalt.
- Á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.
- 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-Timingfejlé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. - Tárhely. Ha az előzők után is lassú a válasz, a szerver kapacitása lehet a szűk keresztmetszet.
WordPress
Szekció neve “WordPress”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,.
Hogyan ellenőrizd
Szekció neve “Hogyan ellenőrizd”Futtasd újra a riportot. A TTFB-t parancssorból is megmérheted:
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: