# 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

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

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](https://hub.hellowp.io/hu/report/teljesitmeny/oldal-gyorsitotar/) oldalt.
2. **CDN.** A látogatóhoz közeli kiszolgálás lerövidíti az utat. Lásd a [CDN](https://hub.hellowp.io/hu/report/teljesitmeny/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](https://hub.hellowp.io/hu/report/alapok/atiranyitasok-szama/) 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.

### 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

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

```bash title="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](https://hub.hellowp.io/hu/knowledge-base/useful-tools/pagespeed-insights/) a valódi látogatók mért adatait is megmutatja, ha az oldalnak van elég forgalma.