TTFB javítás: mitől lassú a szerver válaszideje?

Beírod a címet, entert nyomsz, és egy pillanatig nem történik semmi. Az oldal nem darabonként épül fel, a képernyő egyszerűen üres marad, a fülön meg pörög a töltésjelző. Ebben a szakaszban a böngésző még csak vár: elküldte a kérést, és nincs mit kirajzolnia, amíg a szerver nem válaszol. Ezt az időt méri a TTFB.

Mit mér pontosan a TTFB?

A TTFB (Time to First Byte, első bájtig eltelt idő) azt méri, mennyi idő telik el a kérés elküldése és aközött, hogy a szervertől megérkezik az első bájt. Ebbe minden belefér, ami addig történik: a domain feloldása, a kapcsolat felépítése, a titkosítás beállítása, az esetleges átirányítások, és végül maga a munka, amivel a szerver összerakja az oldalt.

Ezért kicsit félrevezető szerverválaszidőnek fordítani. A szerver saját gondolkodása csak az utolsó darab. Egy távoli géppel a kapcsolatfelvétel magában elvihet száz ezredmásodpercet, mielőtt a szerver egyetlen sort futtatott volna.

Mennyi a jó TTFB?

A Google 800 ezredmásodperc alatt tartja jónak, 1,8 másodperc felett gyengének. Ezek megengedő határok. A gyors oldalak jóval lejjebb vannak: a saját oldalam élesben 170 ezredmásodperc alatt válaszol, egy statikus HTML-fájl ugyanarról a szerverről 70 alatt.

Ha a te oldalad 1 másodperc körül vagy afelett van, ott van behozni való, akkor is, ha a PageSpeed ezt még nem pirosítja be.

Miért ez az első dominó?

Amíg a szerver nem válaszolt, a böngésző semmit nem tud kezdeni. Nem ismeri az oldal szerkezetét, nem tudja, milyen képek, stíluslapok és betűtípusok kellenek, tehát letölteni sem kezdi el őket. Minden ezredmásodperc, ami itt elmegy, egy az egyben benne marad a betöltést mérő mutatókban is.

Emiatt látszik olyan keveset a képoptimalizálás egy lassú szerveren. A képek lehetnek tökéletesek, ha a böngésző fél másodperccel később tud egyáltalán a létezésükről. A legnagyobb elem megjelenését mérő LCP soha nem lesz jobb, mint a TTFB, mert az egyik csak a másik után tud elkezdődni.

Hogyan mérd meg a saját oldaladon?

Három ingyenes út, egyikhez sem kell fejlesztő.

• PageSpeed Insights. A pontszám alatti diagnosztikai listában keresd az „Initial server response time" sort, magyarul a kezdeti szerverválaszidőt. Ott áll a konkrét szám.

• A böngésződ. F12, Hálózat (Network) fül, frissítsd az oldalt, és kattints a lista legelső sorára, magára a dokumentumra. Az Időzítés (Timing) résznél a „Waiting for server response" a keresett érték.

• Parancssor. Ha pontos számot akarsz, ez a leggyorsabb út:

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

Mérj egymás után többször. Az első kérés majdnem mindig lassabb, mert a gyorsítótár üres, és az olcsóbb tárhelyeken a gépnek is fel kell ébrednie hozzá. Ami számít, az a második és a harmadik mérés, meg az, mennyire szórnak az eredmények.

Mi viszi el az időt?

• A tárhely. Olcsó, megosztott csomagon több száz oldal osztozik egy gépen. Ha a szomszédok éppen dolgoznak, a te kérésed sorban áll. Magas TTFB-nél ez az első, amit megnézek.

• A szerver földrajzi helye. Egy amerikai szerver és egy magyar látogató között az adat oda-vissza útja magában 100-150 ezredmásodperc. Magyar közönséghez európai, még jobb esetben magyarországi szerver való.

• Minden kérésnél újra legenerált oldal. A WordPress alapesetben minden egyes látogatónál lefuttatja a PHP-t, lekérdezi az adatbázist, és összerakja ugyanazt az oldalt. Gyorsítótár nélkül ezerszer elvégzi ugyanazt a munkát ugyanazért a tartalomért.

• Átirányítás-lánc. A http://pelda.hu címről https://pelda.hu, onnan https://www.pelda.hu: két teljes kör a szerverhez, mielőtt az igazi oldal egyáltalán elindulna.

• Külső hívás a háttérben. Ha az oldal betöltés közben megkérdez egy másik szolgáltatást (árfolyam, készlet, hírlevélrendszer), és az lassan felel, az a te válaszidődben jelenik meg.

• Elavult PHP. Egy több éves verzió ugyanazt a munkát lassabban végzi el, és biztonsági javítást sem kap már. A váltás pár kattintás a tárhely vezérlőpultjában, de előtte ellenőrizni kell, hogy az oldal elbírja-e. Erről a weboldal karbantartásról szóló cikkben írtam bővebben.

Két másodperc, amit egy nem futó szolgáltatás vitt el

A saját oldalam fejlesztői példányát mértem, és a főoldal makacsul 2,17 másodperc alatt válaszolt. A kód rendben volt, az adatbázison nem volt terhelés, a gép sem csinált semmit. Kiderült, hogy a szerver minden kérésnél megpróbált csatlakozni egy háttérszolgáltatáshoz, ami nem futott, és mindannyiszor kivárta a beépített két másodperces időkorlátot, mielőtt továbbment volna. Miután kikapcsoltam, a válaszidő 87 ezredmásodpercre esett.

Nem arra akarok kilyukadni, hogy mindenkinél ez a baj. Arra, hogy a magas TTFB gyakran nem erőforrás-kérdés: a szerver sokszor nem dolgozik, hanem vár valamire, ami nem jön. Egy nagyobb tárhelycsomag ezen semmit nem javítana.

Mit tudsz javítani rajta?

Kapcsolj be gyorsítótárat. Ez adja a legnagyobb ugrást a legkevesebb munkával. A cél, hogy a szerver ne rakja össze újra ugyanazt az oldalt minden látogatónak, hanem egy kész változatot adjon vissza. WordPressen ezt egy cache bővítmény intézi, a szélesebb körben használtak a WP Super Cache, a LiteSpeed Cache és a W3 Total Cache. Sok tárhelyszolgáltatónál szerver szinten is van gyorsítótár, azt elég bekapcsolni a vezérlőpulton.

Számold meg az átirányításokat. Írd be a címet http-vel és www nélkül is, és nézd meg, hány ugrással jutsz el a végleges változatig. Egy ugrás belefér, kettő már mérhető veszteség. A szerver beállításában egy lépésre össze lehet vonni őket.

Frissítsd a PHP-t. A régebbi verziókhoz képest a mai kiadások érezhetően gyorsabban futtatják ugyanazt a kódot. Előbb mentés, utána váltás, és nézd végig az oldalt.

Ha a tárhely a szűk keresztmetszet, költözz. Váltás előtt ezeket nézd meg: hol van fizikailag a szerver, van-e beépített gyorsítótár, milyen PHP-verziók érhetők el, és mennyi erőforrást kapsz valójában. Az ár önmagában keveset mond, a TTFB viszont mérhető, és a jelenlegi szolgáltatódon is meg tudod nézni.

A CDN önmagában nem old meg mindent. Képek és fájlok kiszolgálására kiváló, de a HTML-oldalt alapbeállításon minden kérésnél a te szerveredtől kéri el. Ha nincs mögötte gyorsítótár, a TTFB ott marad, ahol volt.

Mikor nem a TTFB a gond?

Ha a szerver 200-300 ezredmásodperc alatt válaszol, és az oldal mégis lassan jelenik meg, akkor a probléma a böngésző oldalán van. Ilyenkor a képek, a render-blokkoló CSS, a JavaScript vagy a betűtípusok betöltése viszi el az időt.

A méréshez még annyit: a PageSpeed eredménye futásonként ingadozik. A saját oldalamon egymás utáni futásokon 3,3 és 5,1 másodperc közötti betöltési időket kaptam, miközben a szerver válaszideje stabilan 0,2 másodperc körül maradt. A szórás tehát a mérőeszközé volt, nem az oldalé. Ezért mérj többször, és a mutatókat figyeld, ne az összesített pontszámot.

Hol a helye a többi mutató között?

A TTFB a betöltés legelső szakasza, a többi mutató erre épül rá. Utána jön az LCP, ami a legnagyobb elem megjelenését méri, a CLS, ami az ugráló tartalmat, és az INP, ami a kattintásra adott válasz gyorsaságát. A teljes képet, a helyes méréssel és a leggyakoribb okokkal együtt itt találod: Miért lassú a weboldalad, és hogyan gyorsítsd fel?

Lassan válaszol az oldalad?

Küldd el az oldalad címét, megmérem, és megmondom, a szerver vagy a böngésző oldalán van a gond. Ha a tárhelyen múlik, azt is megírom, mit kérj számon a szolgáltatódon, mielőtt költözésben gondolkodnál. Itt tudsz írni.