A TTFB (Time To First Byte) az az idő, amennyi a kérés elküldésétől az első válaszbájt megérkezéséig telik el. Ez a szám a legtöbb magyar WordPress oldalon négy különböző dolgot takar egyszerre, és amíg nem bontod szét őket, minden gyorsítási kísérlet vaktában lövöldözés. A leggyakoribb hiba, hogy valaki meglát egy 1,4 másodperces TTFB-t, és azonnal tárhelyváltásban kezd gondolkodni, holott az idő nagy része a saját kódjában és bővítményeiben keletkezik.
Miből áll össze pontosan a TTFB?
A TTFB nem egy művelet, hanem egy lánc: ha bármelyik szeme lassú, az egész szám megnő. A négy fő szakasz a következő.
- DNS-feloldás: a domainnév IP-címre fordítása. Hideg cache mellett 20-150 ms, jó szolgáltatónál ennél kevesebb. Ha ez a rész tartósan 200 ms fölött van, a névszervereddel van baj, nem a tárhellyel.
- TCP-kapcsolat felépítése: a hálózati kézfogás. Nagyjából a ping fele-egésze. Magyar látogató és magyar szerver között tipikusan 5-25 ms, egy amerikai szerverig 110-160 ms.
- TLS-kézfogás: a HTTPS titkosítás kiépítése. Első kapcsolatnál egy-két további körút, tehát nagyjából megduplázza a hálózati költséget. Újralátogatásnál a session újrahasznosítás miatt lényegesen kevesebb.
- Szerveroldali feldolgozás: a webszerver átveszi a kérést, elindul a PHP, lefut a WordPress, lekérdez az adatbázisból, összerakja a HTML-t. Lassú oldalon ez a szakasz viszi az idő 70-90 százalékát.
Hivatalosan igazolt: a Chrome fejlesztői dokumentációja szerint a TTFB nem önálló Core Web Vitals mérőszám, viszont minden későbbi betöltési metrika alsó korlátja: az LCP soha nem lehet gyorsabb a TTFB-nél. Szakmai feltételezés: a válaszmotorok és AI-crawlerek türelme rövidebb, mint egy emberé, ezért egy tartósan másodperces szerverválasz jó eséllyel rontja az indexelés és az idézhetőség esélyét is, bár erre publikus küszöbszámot egyik szolgáltató sem közöl.
Hogyan mérd külön a TTFB összetevőit?
A leggyorsabb és legpontosabb eszköz a curl, mert szakaszonként adja vissza az időt. Ezt futtasd le a saját oldaladra, lehetőleg magyar hálózatról.
curl -s -o /dev/null -w 'dns: %{time_namelookup}\ntcp: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n' https://pelda.hu/
A kimenetet nem önmagában, hanem kivonásokkal kell olvasni. Így kapod meg az egyes szakaszok tényleges hosszát:
- DNS = time_namelookup
- TCP = time_connect mínusz time_namelookup
- TLS = time_appconnect mínusz time_connect
- Szerveroldali feldolgozás = time_starttransfer mínusz time_appconnect
Ez az utolsó szám a lényeg. Ha ez 100 ms, a szervered rendben van, és a hálózaton vagy a DNS-en kell dolgozni. Ha 900 ms, akkor a PHP a szűk keresztmetszet, és felesleges CDN-t vásárolni a HTML elé.
Böngészőben ugyanez a Network fülön látszik: kattints a legelső dokumentum-kérésre, majd a Timing szakaszra. Ott külön sorban jelenik meg a Queueing, a Stalled, a DNS Lookup, az Initial connection, az SSL és a Waiting for server response. Ez utóbbi a szerveroldali idő. Fontos, hogy bejelentkezett adminként mért érték félrevezető, mert az adminsáv és a bejelentkezett munkamenet kikerüli a gyorsítótárat: mindig mérj privát ablakban vagy kijelentkezve is.
Külső eszközből érdemes legalább kettőt használni. A PageSpeed Insights a labormérés mellett valós felhasználói (CrUX) adatot is mutat, ha van elég forgalmad. A WebPageTest előnye, hogy választható mérési helyszín és megismételhető, hideg cache-es futtatás. Az uptime-figyelők (bármelyik, ami percenként pingel) pedig azért hasznosak, mert megmutatják a napszaki ingadozást, ami az osztott tárhely szomszédhatásának a legjobb árulkodó jele. Saját tapasztalat: egyetlen mérés semmit nem ér, mert a szórás nagyobb, mint a különbség, amit keresel. Legalább 8-10 mérést futtass, és a mediánt nézd, ne a legjobb és ne a legrosszabb futást.
Mi számít jó TTFB-értéknek magyar tárhelyen?
Magyar látogató, magyar adatközpont és WordPress esetén a következő sávokkal érdemes dolgozni.
- 200 ms alatt: jó, itt már nem a TTFB a szűk keresztmetszet.
- 200-500 ms: elfogadható, dinamikus oldalnál teljesen reális cél.
- 500-800 ms: gyanús, itt már biztosan van legalább egy javítható ok.
- 800 ms fölött: beavatkozás kell. Hivatalosan igazolt: a Chrome fejlesztői ajánlása a 800 ms-ot jelöli meg a jó sáv határának, és 1800 ms fölött minősít gyengének.
Egy fontos torzítás: ha a mérőeszköz Frankfurtból vagy Virginiából mér, a hálózati szakasz miatt kapsz plusz 30-150 ms-ot, ami nem a tárhelyed hibája. Ezért a benchmarkolást mindig magyar hálózatról indított curl-lel zárd le, a külső eszköz csak kiegészítő.
Miért lassú a szerveroldali feldolgozás WordPress alatt?
Ha a szerveroldali szakasz a nagy, gyakorlatilag mindig ezek közül kerül ki az ok.
- Felfúvódott autoload beállítások. A wp_options tábla autoload mezői minden egyes kérésnél betöltődnek. Ha ez több megabájt, minden oldalletöltés fizeti az árát. Ellenőrizd:
SELECT option_name, LENGTH(option_value) FROM wp_options WHERE autoload = 'yes' ORDER BY 2 DESC LIMIT 20;A leggyakoribb bűnösök az eltávolított bővítmények ottfelejtett gyorsítótárai és a naplózó bővítmények. - Külső API-hívás a betöltés közben. Licenckulcs-ellenőrzés, árfolyam-lekérés, közösségi számláló, futárszolgálati díjkalkuláció: ha ezek nem gyorsítótárazottak, és a hívott szolgáltatás lassú, a te oldalad vár rá. Egyetlen ilyen hívás simán ad 400-1500 ms-ot a TTFB-hez.
- Régi PHP-verzió, hiányzó OPcache. A PHP 7.4-ről 8.2-re vagy 8.3-ra lépés önmagában érezhető gyorsulást hoz. OPcache nélkül a PHP minden kérésnél újrafordítja a kódot.
- Lassú vagy sok lekérdezés. Indexeletlen postmeta-keresés, rosszul megírt WP_Query, terméklistázás nagy webshopban. Nem a lekérdezések száma önmagában a baj, hanem az össz-lekérdezési idő.
- A wp-cron a látogató kérésén fut. Alapértelmezésben a WordPress az ütemezett feladatokat egy beérkező kéréshez csapja hozzá, tehát egy szerencsétlen látogató fizeti ki a hírlevélküldés vagy a szinkron idejét.
- Osztott tárhely szomszédhatása. Ugyanazon a fizikai gépen futó másik oldal CPU-t vagy lemez-IO-t eszik. Ennek a jele, hogy a TTFB napon belül 2-5-szörös szórást mutat változatlan kód mellett.
- Hiányzó oldalgyorsítótár. Full page cache nélkül minden látogatás végigfuttatja a teljes PHP-t, akkor is, ha a tartalom hetek óta változatlan.
Milyen sorrendben diagnosztizálj?
Ez a hat lépés a leggyorsabb út odáig, hogy megbízhatóan tudd, hol van a baj. Ne ugorj sorrendet, mert a 4. lépés eredménye a 3. lépés nélkül félreérthető.
- Mérj kívülről, ismételve. Futtasd a curl-parancsot 10-szer, jegyezd fel a mediánt és a legrosszabb értéket. Csináld meg délelőtt és este is.
- Bontsd fel a szakaszokat. Ha a DNS, TCP és TLS együtt kevesebb, mint az összeg negyede, innentől csak a szerveroldallal foglalkozz.
- Mérj egy statikus fájlt is. Kérj le egy kicsi képet vagy CSS-t ugyanarról a domainről. Ez PHP nélkül fut. Ha a statikus fájl TTFB-je is magas, a szerver vagy a hálózat a hibás. Ha a statikus gyors és a HTML lassú, a WordPress a hibás. Ez a legfontosabb elágazás az egész folyamatban.
- Nézd meg a nyers PHP-időt. Kapcsold ki átmenetileg a full page cache-t egy staging másolaton, és futtasd a Query Monitor bővítményt: megmutatja az össz-lekérdezési időt, a leglassabb lekérdezéseket, a HTTP API-hívásokat és a memóriahasználatot. A betöltés közbeni külső hívások itt bukkannak elő.
- Felezz bővítménnyel. Staging környezetben kapcsold ki a bővítmények felét, mérj, majd a maradék felét. Négy-öt körben megvan a felelős. Élesben ezt soha ne csináld.
- Vizsgáld a szomszédhatást. Nézd meg a tárhely vezérlőpultjában a CPU- és IO-limit naplót, és futtass egy folyamatos, percenkénti mérést 24 órán át. Ha az erőforrás-napló rendszeresen limitet jelez, vagy a P95-ös TTFB a medián háromszorosa, az már a szolgáltató oldalán van.
Mit tudsz javítani a szolgáltatóváltás előtt?
A váltás drága és kockázatos lépés, ezért előtte fusd végig ezt a listát. Saját tapasztalat: ezeknek együtt általában nagyobb a hatásuk, mint egy tárhelycserének.
- Állítsd a PHP-t a legfrissebb támogatott verzióra (ma 8.2 vagy 8.3), és ellenőrizd, hogy az OPcache be van-e kapcsolva.
- Tegyél be egy megbízható full page cache megoldást, és győződj meg róla, hogy tényleg talál (a válaszfejlécben látszik a cache hit).
- Ha a szolgáltató ad Redis vagy Memcached objektum-gyorsítótárat, kapcsold be. Nagy wp_options táblánál ez látványos.
- Takarítsd az autoload beállításokat: a régi bővítmények maradékát töröld, a nagy értékeket állítsd autoload = no értékre, ha nem kell minden kérésnél.
- Vedd le a wp-cront a látogatói kérésről:
define('DISABLE_WP_CRON', true);a wp-config.php-ban, majd állíts be percenkénti rendszer cront a wp-cron.php-ra. - Minden külső API-hívást tegyél transient mögé, és adj neki rövid időkorlátot, hogy egy lassú külső szolgáltatás ne rántsa magával az oldalt.
- Ritkítsd a bővítményeket. Amit nem használsz, azt ne csak deaktiváld, hanem töröld is.
- Csökkentsd a Heartbeat API gyakoriságát, és nézd meg, mennyi admin-ajax kérés fut a nyilvános oldalakon.
- Ellenőrizd a DNS-t: rövid, de nem irreális TTL, és lehetőleg anycast névszerverek.
- Kapcsold be a HTTP/2-t vagy HTTP/3-at, és a statikus tartalmat tedd CDN mögé (a HTML-t magyar közönségnél nem feltétlenül éri meg).
Milyen mérési eredmény jelenti, hogy tárhelyet kell váltani?
Akkor váltasz, ha a szerver a te kódod nélkül is lassú. Konkrétan ezek a jelek:
- Egy statikus fájl TTFB-je magyar hálózatról tartósan 400-600 ms fölött van. Ez PHP nélküli mérés, tehát nem lehet a WordPressre fogni.
- Egy üres WordPress-telepítés (alaptéma, nulla bővítmény, ugyanaz a tárhely) TTFB-je is 500 ms fölött marad.
- A P95-ös érték a medián három-ötszöröse, és ez napról napra ismétlődik, változatlan kód mellett.
- Az erőforrás-napló rendszeresen CPU- vagy IO-limitet jelez, és a magasabb csomag sem oldja meg tartósan.
- A szolgáltató nem ad friss PHP-t, OPcache-t vagy objektum-gyorsítótárat, és nincs rá ütemterve.
- Az ügyfélszolgálat két konkrét, mérési adattal alátámasztott megkeresésre sem ad érdemi választ.
Ha ezek közül legalább kettő teljesül, a váltás jó eséllyel megtérül. Ha egy sem, akkor a váltás valószínűleg csak áthelyezi ugyanazt a problémát egy másik gépre. Garantált javulást egyik esetben sem lehet ígérni, mert a végeredmény a kódtól és a forgalomtól is függ.
Miért ritkán a tárhely az igazi ok?
Saját tapasztalat: a hozzám kerülő lassú magyar WordPress oldalak túlnyomó többségénél nem a tárhely a szűk keresztmetszet, hanem a bővítménykészlet. A tipikus minta: egy nehéz oldalépítő, mellé három egymást átfedő SEO- és gyorsítóbővítmény, egy sütikezelő, két űrlapkezelő, egy statisztikai bővítmény, ami minden megtekintést az adatbázisba ír, és néhány évek óta ott felejtett kiegészítő. Ez a készlet ugyanannyira lesz lassú egy prémium szerveren is, csak drágábban.
Szakmai feltételezés: a váltás azért olyan vonzó magyarázat, mert egyetlen döntéssel lezárható, míg a bővítmény-ritkítás munka, kockázat és vita az ügyféllel arról, hogy melyik funkció maradhat el. A mérés viszont eldönti a kérdést: a 3. lépésben leírt statikus fájl teszt fél perc alatt megmondja, hogy egyáltalán van-e értelme a szolgáltatóról beszélni. Kezdd ott, és csak azután nyiss új tárhelyet.
Források és további olvasnivalók
- Google Search Central: Core Web Vitals és oldalélmény dokumentáció
- Chrome for Developers / web.dev: Time to First Byte (TTFB) és LCP útmutatók
- WordPress Developer Resources: Performance és WP_Query dokumentáció
- curl hivatalos dokumentáció: a --write-out időzítési változói
- MDN Web Docs: HTTP caching, HTTP/2 és HTTP/3 áttekintés
- PHP hivatalos kézikönyv: OPcache konfiguráció
- W3C: Navigation Timing és Resource Timing specifikáció
- Schema.org: strukturált adat szótár
- A TTFB-t bontsd fel DNS-feloldásra, TCP-kapcsolatra, TLS-kézfogásra és szerveroldali feldolgozásra, mert mindegyiket máshol kell javítani.
- Egy curl-parancs időzítési paramétereivel másodpercek alatt megmondható, hogy a hálózat vagy a PHP lassú.
- Magyar látogatónak magyar szerverről 200 ms alatti TTFB jó, 800 ms fölött már beavatkozás kell.
- A szerveroldali idő leggyakoribb okai: felfúvódott autoload beállítások, betöltés közbeni külső API-hívás, régi PHP-verzió és a hiányzó gyorsítótár.
- Tárhelyváltás akkor indokolt, ha egy statikus fájl vagy egy bővítmény nélküli WordPress is lassú marad, és a napszaki szórás nagy.
Gyakori kérdések
Mennyi a jó TTFB magyar tárhelyen?
Magyar látogató és magyar adatközpont esetén 200 ms alatt jó, 200-500 ms között elfogadható, 800 ms fölött pedig beavatkozás kell. A Chrome fejlesztői ajánlása is a 800 ms-ot jelöli a jó sáv határának, 1800 ms fölött már gyengének minősít.
Hogyan tudom megnézni, hogy a hálózat vagy a szerver lassú?
Futtass egy curl parancsot a --write-out időzítési változóival, és vond ki a time_appconnect értéket a time_starttransfer értékből. Ez a különbség a tiszta szerveroldali idő. Ha ez kicsi, de az összes TTFB nagy, a DNS-sel vagy a hálózati úttal van baj.
A TTFB rangsorolási tényező a Google-nél?
Önmagában nem: hivatalosan a TTFB nem Core Web Vitals mérőszám. Viszont felső korlátot szab minden más betöltési metrikának, például az LCP soha nem lehet gyorsabb nála, így közvetve az oldalélmény-jelzéseken keresztül számít.
Segít-e a CDN a magas TTFB-n?
Statikus fájloknál igen, a HTML-nél viszont csak akkor, ha a CDN tényleg gyorsítótárazza az oldalt. Ha a lassúság a PHP feldolgozásból jön, és a HTML nincs cache-elve, a CDN nagyrészt csak továbbítja a várakozást.
Mennyi bővítmény a sok WordPress alatt?
Nem a darabszám dönt, hanem az össz-feldolgozási idő. Egy Query Monitor mérés megmutatja, melyik bővítmény mennyi lekérdezést és külső hívást okoz. Előfordul, hogy 30 könnyű bővítmény gyorsabb, mint 8 nehéz.
Mit tegyek, ha csak napszakonként lassú az oldal?
Futtass 24 órán át percenkénti mérést, és hasonlítsd a mediánt a P95-höz. Ha a különbség tartósan három-ötszörös változatlan kód mellett, az jó eséllyel osztott tárhelyen jelentkező szomszédhatás, és érdemes a szolgáltatóhoz fordulni a mérési adatokkal.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.