TTFB (Time to First Byte)

Sebesség

A TTFB minden későbbi mérőszám kiindulópontja. Egy 1500 ms-os TTFB mellett a LCP már eleve 1,5 másodperc hátrányból indul. A képtömörítés és a render-blokkoló erőforrások rendezése ilyenkor alig hoz látható javulást.

Feltérképezés

A Google crawl-költségvetése részben a szerver válaszidejétől függ. Lassú oldalnál a robot ritkábban és kevesebb URL-t néz meg. A Search Console Beállítások menüjében a feltérképezési statisztikák között ez az átlagos válaszidő konkrétan látszik.

AI-olvasás

A generatív keresők robotjai valós időben hívják le az oldalt. Ha a válasz lassú, a tartalom kimarad a válaszból. A riportokban rendszeresen látjuk, hogy egy oldal tartalmilag rendben van, de a válaszidő miatt mégsem kerül be az idézett források közé.

Üzlet

A lassú első bájt a felhasználónál fehér képernyőként jelentkezik. Mobilneten ez a legdrágább másodperc: ilyenkor még semmi nem történik a képernyőn, amiért érdemes lenne várni.

Minden nyilvános weboldalra vonatkozik, típustól függetlenül.

Kiemelten számít:

• dinamikus CMS-ek: WordPress, WooCommerce, egyedi PHP-oldalak
• webshopok, ahol a kosár és a készlet miatt a cache-elés nehezebb
• sok aloldalas, nagy katalógusú oldalak
• külföldi látogatókat is kiszolgáló oldalak, ahol a földrajzi távolság is beleszámít

Kevésbé számít:

• statikus generált oldalak (CDN mögött), ahol a TTFB jellemzően 100 ms alatt van
• belső rendszerek, staging-környezetek, admin-felületek

A Shopify, Unas és Shoprenter felhasználóknál a szerveroldal a szolgáltató kezében van. Ott a saját mozgástér szűkebb, de nem nulla: a sablon, a beépülő appok és az átirányítások itt is rontják a TTFB-t.

Böngésző devtools

1. Nyisd meg a Network fület, és tölts be egy friss oldalt (Ctrl+Shift+R).
2. Kattints a legelső, HTML-dokumentum kérésre.
3. Válaszd a Timing fület.
4. Olvasd le a Waiting for server response értéket: ez a szerveroldali rész.
5. Nézd meg a fölötte lévő sorokat is: átirányítás, DNS, TLS.

curl

Parancssorból a legpontosabb, mert a böngésző cache nem zavar be. A time_starttransfer érték a TTFB.

PageSpeed Insights

A PageSpeed Insights a mezei adatok között külön sorban mutatja a Szerver válaszidejét. Ez CrUX-adat, tehát valódi látogatók mérése, nem labor.

Search Console

A Beállítások alatt a Feltérképezési statisztikák mutatják az átlagos válaszidőt ezredmásodpercben, időbeli grafikonnal. Itt derül ki, ha a lassulás egy adott naptól kezdődött.

Jó jel:

• 200-400 ms a fő aloldalakon
• első és ismételt kérés között kicsi a különbség
• nincs átirányítás a fő URL előtt

Rossz jel:

• 800 ms feletti érték hétköznap, forgalmas időszakban
• az első kérés 3 másodperc, a második 200 ms (üres cache)
• aloldalanként erősen szóró értékek
• 1-2 átirányítás a végleges URL előtt

WordPress

1. Kapcsolj be oldal-cache-t: LiteSpeed Cache, WP Rocket vagy a tárhely saját megoldása.
2. Ellenőrizd a PHP-verziót. A régi PHP önmagában 2-3-szoros feldolgozási időt jelent.
3. Kapcsold ki vagy ritkítsd a WP-Cron futását, és tedd át rendszerszintű cronba.
4. Nézd át a beépülőket. Query Monitorral megnézheted, melyik lassítja a kérést.
5. Tedd az objektum-cache-t Redisre, ha a tárhely támogatja.

Shopify

1. A szerveroldalt nem tudod hangolni, a sablont igen.
2. Nézd át a telepített appokat, és távolítsd el a nem használtakat.
3. Kerüld a Liquid-sablonban a nagy ciklusokat és a felesleges metafield-lekéréseket.
4. Ellenőrizd, hogy nincs-e felesleges átirányítási lánc a kampány-URL-eken.

Unas

1. Kapcsold be a rendszer saját gyorsítótár-beállításait az adminban.
2. Csökkentsd a kategóriaoldalanként megjelenített termékek számát.
3. Vedd ki a felesleges külső szkripteket a fejlécből.
4. Lassulásnál nyiss hibajegyet, mert a szerveroldali rész a szolgáltatónál van.

Shoprenter

1. Ellenőrizd a bekapcsolt modulokat, és kapcsold ki a nem használtakat.
2. Vizsgáld át a sablonba illesztett egyedi kódokat.
3. Nézd meg, nem fut-e szinkron külső készlet- vagy ERP-lekérés az oldalbetöltésben.
4. Szolgáltatói oldalon a tárhelycsomag is korlát lehet.

Egyedi fejlesztés

1. Mérd ki, hol megy el az idő. APM vagy egyszerű timing-log elég a kezdéshez.
2. Keresd az N+1 lekérdezéseket és a hiányzó adatbázis-indexeket.
3. Vezess be teljes oldal-cache-t a publikus, nem személyre szabott oldalakon.
4. Tedd aszinkronná a külső API-hívásokat, vagy cache-eld a válaszukat.
5. Rakd CDN mögé a HTML-t is, ne csak a képeket.
6. Szüntesd med a átirányítási láncokat, és ellenőrizd a HTTP/2 vagy HTTP/3 támogatást.

A tömörítés a TTFB-t nem javítja, a letöltési időt igen. A kettőt ne keverd.

• Frontend-optimalizálás magas TTFB mellett: képeket tömörítesz, miközben a szerver 2 másodpercig gondolkodik.
• Mérés meleg cache-sel: a saját, gyakran látogatott oldalad gyorsnak tűnik, egy új látogatónál nem az.
• Egyetlen URL mérése: a főoldal cache-elt, a kategória- és keresési oldalak viszont nem.
• Átirányítási lánc a fő URL előtt: http, www és nyelvi prefix, három ugrás, három TTFB.
• Külső szkript szinkron hívása a headben: egy lassú harmadik fél az egész oldalt megfogja.
• A CDN csak a képekre: a HTML továbbra is a lassú origin szerverről érkezik.
• Tárhelyváltás mint egyetlen válasz: rossz kód gyorsabb vason is rossz kód marad.

TTFB mérése parancssorból, cache nélkül:

curl -o /dev/null -s -w "dns: %{time_namelookup}\ntcp: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n" -H "Cache-Control: no-cache" https://pelda.hu/

A time_starttransfer a TTFB. Ha ebből a time_appconnect viszi el a nagy részt, a TLS-beállítás a szűk keresztmetszet. Ha a kettő különbsége nagy, a szerveroldali feldolgozás lassú.

Így néz ki egy jól cache-elt válasz fejléce:

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: public, max-age=3600
x-cache: HIT
age: 412
server-timing: cache;desc="HIT", db;dur=0

Az x-cache: HIT és az age azt jelzi, hogy a választ gyorsítótárból kapod. A server-timing fejlécet te is beállíthatod, és a devtools külön oszlopban mutatja:

server-timing: db;dur=53, render;dur=120, total;dur=180

Ez a legolcsóbb módja annak, hogy éles környezetben lásd, hol megy el a betöltési idő szerveroldali része.