Egy lassú oldalnál a leggyakoribb hiba nem az, hogy rossz eszközt használunk, hanem az, hogy rossz sorrendben. Bekerül egy PageSpeed-képernyőkép a csoportba, valaki felrak egy cache-bővítményt, valaki más a képeket kezdi tömöríteni, két hét múlva pedig ugyanott vagyunk, csak több a mozgó alkatrész és kevesebb a biztos pont. A sebességoptimalizálás nálam 80 százalékban mérés és 20 százalékban beavatkozás. Fordítva sosem működik: aki előbb nyúl bele, az utána már nem tudja megmondani, melyik lépés javított és melyik rontott. (Saját tapasztalat.)
Az alábbi sorrend azért szigorú, mert rétegenként halad kívülről befelé, és minden lépés kizár egy réteget. Ha a szerver már egy statikus fájlnál is lassú, semmi értelme a sablon lekérdezéseit nézni. Ha a HTML gyorsan megérkezik, de a látogató mégis vár, akkor a szűk keresztmetszet a böngészőben van, nem a kiszolgálón.
Miért a mérés a munka 80 százaléka?
Mert a „lassú az oldal” nem egy mérőszám, hanem legalább négy különböző jelenség gyűjtőneve: lassú első bájt, lassú fő tartalom-megjelenés, akadozó betöltés közbeni elmozdulás, és késleltetett interakció. Ezek javítása részben ellentétes irányba mutat, ezért ha nem tudod, melyikről van szó, akkor jó eséllyel olyat javítasz, ami nem fájt.
Tovább a témában: WordPress gyorsítótár-bővítmény választása · JavaScript-renderelés és az AI-botok
A Google hivatalos dokumentációja külön mutatót rendel ezekhez a jelenségekhez (LCP, INP, CLS), és külön kezeli a szerveroldali válaszidőt (TTFB) is. (Hivatalosan igazolt.) Ez a szétválasztás nem formaság: a TTFB a szerver felelőssége, az LCP nagyrészt a sablonoké és a képeké, az INP pedig szinte mindig JavaScripthez köthető. Az első kérdésed tehát ne az legyen, hogy „mit kapcsoljak be”, hanem hogy „melyik szám rossz”.
Egy gyakorlati fék, ami sok kört megspórol: minden mérést legalább ötször futtass le, és a mediánt jegyezd fel, ne a legjobb vagy a legrosszabb értéket. A megosztott tárhelyek terhelése percről percre változik, egyetlen mérésből levont következtetés inkább szerencse, mint diagnózis.
Milyen sorrendben mérj, ha lassú az oldal?
Négy réteg, kötött sorrendben. Mindegyikről mondj ki egy ítéletet, mielőtt továbblépsz a következőre:
- Nyers szervervalasz statikus fájlra. PHP, adatbázis és sablon nélkül. Ez a szerver alaphangja.
- HTML-válasz cache nélkül. Itt lép be a PHP, az adatbázis, a sablon és a bővítmények.
- Renderelés a böngészőben. Mikor jelenik meg a fő tartalom, mi blokkolja, mi tolja el.
- Egyes erőforrások. Képek, betűtípusok, külső szkriptek, harmadik feles beágyazások.
A szabály egyszerű: ha egy réteg tiszta, azt le is zárod, és nem térsz vissza rá, amíg új adat nem indokolja. Ez a lezárás a hibakeresés lényege, mert enélkül a kör sosem szűkül.
Hogyan méred meg a nyers szervervalaszt egy statikus fájlra?
Tölts fel egy pár kilobájtos, statikus fájlt (például egy sima szövegfájlt) a gyökérbe, és mérd meg parancssorból, PHP megkerülésével:
curl -o /dev/null -s -w 'connect: %{time_connect} ttfb: %{time_starttransfer} total: %{time_total}\n' https://pelda.hu/teszt.txt
Amit itt látsz, az a hálózat és a webkiszolgáló együttes alaphangja. Ha a time_starttransfer tartósan magas úgy is, hogy semmilyen alkalmazáslogika nem futott, akkor a probléma a tárhelyen, a hálózati útvonalon vagy a TLS-beállításokon van. Ilyenkor a bővítmények kikapcsolgatása időpazarlás. (Saját tapasztalat: a nem ritka eset, amikor a szerver egy szövegfájlt is lomhán ad ki, szinte mindig túlterhelt megosztott tárhelyet vagy távoli adatközpontot jelent.)
Két dolgot érdemes még itt megnézni. Az egyik, hogy a time_connect és a teljes idő különbsége mekkora: ha a kapcsolat felépítése lassú, az a hálózatra, nem a gépre mutat. A másik, hogy megismételve, más országból mérve is ugyanaz-e a kép. Ha csak külföldről lassú, az CDN-kérdés, nem szerverkérdés.
Mit árul el a cache nélküli HTML-válasz?
Rövid válasz: azt, hogy mennyi időbe kerül az oldal tényleges előállítása. A cache ugyanis nem gyorsítja az oldalt, hanem elrejti a lassúságát, és a hibakeresés első felében pontosan ezt nem akarod.
Mérd a HTML-t cache-megkerüléssel, és nézd meg a válaszfejlécet is:
curl -o /dev/null -s -D - -w 'ttfb: %{time_starttransfer}\n' 'https://pelda.hu/?nocache=1'
A fejlécekben keresd, hogy a cache réteg talált-e (a legtöbb rendszer x-cache, cf-cache-status vagy hasonló mezőt küld). Ha a statikus fájl gyors volt, de a cache nélküli HTML sokszorosa, akkor az alkalmazásréteg a hibás: sablon, bővítmény, adatbázis vagy külső API-hívás a kiszolgálás közben. Innen indul a szűkítés.
Egy fontos részlet, amit sokan kihagynak: mérd meg cache-sel is, és jegyezd fel mindkét számot. A kettő aránya mondja meg, hogy a cache mennyit takar el. Ha a különbség tízszeres, akkor a cache egy törött rendszert tart életben, és az első kosárba tétellel, bejelentkezéssel vagy admin-művelettel elő fog jönni a valóság.
Hogyan derül ki, hogy a sablon vagy egy bővítmény a hibás?
Három eszközöd van, és mindhármat staging környezetben használd, ne az élesen. Az éles oldalon végzett kikapcsolgatás nem hibakeresés, hanem szerencsejáték a bevétellel.
1. Lekérdezés-figyelő. WordPressen a Query Monitor, más rendszereken a beépített profilozó (Debug Toolbar, Symfony Profiler, Laravel Telescope) megmutatja a lekérdezések számát, a leglassabb lekérdezéseket, a PHP-időt és azt, melyik bővítmény vagy sablonfájl indította őket. Ez a leggyorsabb út: sok esetben már itt kiderül a bűnös, kikapcsolgatás nélkül. (Hivatalosan igazolt, hogy ezek az eszközök hívásonkénti bontásban adják vissza az adatot; hogy melyik számít soknak, az oldalfüggő.)
2. Bővítmények felezése. Ne egyesével haladj, hanem felezz. Kapcsold ki a bővítmények felét, mérj, majd a hibás felet felezd tovább. Húsz bővítménynél ez öt mérés helyett húsz helyett nagyjából öt lépést jelent. Minden lépés után ugyanazt az URL-t mérd, ugyanolyan állapotban, és írd fel az eredményt.
3. Alapértelmezett sablon próbaként. Válts ideiglenesen az alaprendszer saját sablonjára (WordPressen egy Twenty-* téma). Ha a lassúság eltűnik, a sablon vagy a hozzá tartozó oldalépítő a felelős. Ha megmarad, a sablon tiszta, és lezárhatod ezt a réteget. Ez próba, nem megoldás: a cél a bizonyítás, nem az, hogy ott is maradj.
Mit jelent, ha a főoldal gyors, de a termékoldal lassú?
Rövid válasz: majdnem biztosan nem szerverkapacitás-probléma, hanem oldaltípus-specifikus logika. Ha a szerver kevés lenne, a főoldal is szenvedne.
A tipikus okok, tapasztalati gyakorisági sorrendben: a termékoldal sablonja olyan lekérdezéseket futtat, amiket a főoldal nem (kapcsolódó termékek, változatok, készletadat, dinamikus ár), a termékoldal valós idejű külső hívást indít (készlet- vagy szállítási API), vagy éppen a termékoldal az, ami kimarad a cache-ből, mert személyre szabott elemet tartalmaz. (Saját tapasztalat.)
A szűkítés menete: mérj meg három különböző termékoldalt, majd egy kategórialistát, majd egy sima statikus aloldalt (például kapcsolat). Ha csak a termékoldal lassú, nyisd meg a lekérdezés-figyelőt pontosan azon az oldalon. Ha a lekérdezésszám a főoldal többszöröse, akkor N+1 típusú lekérdezésre gyanakodj: a sablon ciklusban kérdez le olyasmit, amit egyszer is lehetne. (Szakmai feltételezés az adott oldalra nézve, amíg a profilozó ki nem írja a hívási láncot.)
Mit jelent, ha a bejelentkezett nézet lassú, a kijelentkezett gyors?
Rövid válasz: azt, hogy nem az oldal gyors, hanem a cache. A bejelentkezett látogató megkerüli a lapszintű gyorsítótárat, és ilyenkor derül ki a valódi előállítási idő.
Ez a különbség önmagában nem hiba, de három dolgot jelezhet. Az első: az alkalmazásréteg tényleg lassú, csak eddig a cache takarta. A második: a bejelentkezett nézet extra munkát végez (admin sáv, jogosultság-ellenőrzés, személyre szabott blokkok, ütemezett feladatok, amiket a látogatói kérés indít el). A harmadik, ami webshopoknál a leggyakoribb: a kosár- és munkamenet-kezelés minden kérésnél írja az adatbázist vagy a munkamenet-tárat.
Ha a webshopod jelentős része bejelentkezett vagy kosaras forgalom, akkor a „gyors kijelentkezett nézet” hamis megnyugvás: a vásárláshoz legközelebb álló látogatóid pontosan a lassú változatot látják. Ez a diagnózis egyben rangsorol is: a bejelentkezett TTFB javítása jó eséllyel több bevételt érint, mint a főoldal LCP-jének finomhangolása, bár garantálni ezt egyetlen mérésből sem lehet.
Mikor jön a renderelés és az egyes erőforrások mérése?
Akkor, amikor a HTML már gyorsan megérkezik, de a látogató mégis vár. Nyisd meg a böngésző fejlesztői eszközeit, hálózati fül, cache kikapcsolva, és lassított hálózaton (throttling) mérj, mert asztali gépen, kábeles neten szinte minden oldal jónak tűnik.
Amit itt keresel: mi blokkolja a megjelenítést (fejlécbe tett szinkron szkriptek, nem kritikus CSS), mekkora a fő tartalomkép és mikor kezdődik a letöltése, hány külső domainre megy kérés, és van-e olyan harmadik feles szkript (chat, hőtérkép, hirdetéskövető, sütibanner), ami sokáig fut. A betűtípusoknál nézd meg, hogy a szöveg mikor válik láthatóvá, mert a rossz betűtöltési stratégia másodperceket rejt el.
Egy hasznos, kevésbé ismert eszköz: a Server-Timing fejléc. Ha a fejlesztő beleírja a szerveroldali fázisokat (adatbázis, sablon, külső hívás), akkor ezek a böngésző hálózati fülén, ügyfélszinten is láthatóvá válnak. (Hivatalosan igazolt: a Server-Timing szabványos fejléc, a böngészők fejlesztői eszközei megjelenítik.)
Milyen hibák viszik zsákutcába a hibakeresést?
- Egyszerre több változtatás. Ha két dolgot módosítasz, és javul, nem tudod, melyik javított, és a másik akár ronthatott is.
- Mérés cache-sel. Az első mérés a cache-t méri, nem az oldalt. Mindig legyen egy cache nélküli referenciaérték.
- Egyetlen mérés. Medián öt mérésből, különben a szerver pillanatnyi terhelését hiszed trendnek.
- Éles oldalon kísérletezés. A staging nem luxus, hanem a hibakeresés feltétele.
- A pontszám kergetése. A szintetikus pontszám nem azonos a valós felhasználói élménnyel; a terepadat (mezei látogatóktól gyűjtött mérés) közelebb van az igazsághoz.
- A változásnapló kihagyása. A leggyorsabb kérdés gyakran az, hogy mi történt az oldallal a lassulás előtti két hétben.
Hogyan add át a mérést a fejlesztőnek?
Rövid válasz: úgy, hogy ne kelljen elölről kezdenie. Az alábbi kilenc pont az a minimum, amivel egy fejlesztő azonnal dolgozni tud, és amit én is elvárok magamtól, mielőtt bárkinek továbbadom az ügyet.
- Mit mérünk: pontos URL-ek (főoldal, egy termékoldal, egy kategória, egy statikus aloldal), a mérés dátuma és órája budapesti idő szerint.
- Honnan mérünk: hálózat típusa, ország, eszköz, böngésző verziója, volt-e sávszélesség-korlátozás.
- Statikus fájl válaszideje: öt mérés, medián, kapcsolódási idő és teljes idő külön.
- HTML TTFB: cache nélkül és cache-sel, öt-öt mérés, a válaszfejléc cache-státusz mezőjével együtt.
- Az oldal állapota a méréskor: bejelentkezve vagy kijelentkezve, üres vagy tele kosár, nyelv, pénznem, aktív A/B teszt.
- Környezet: aktív sablon és bővítménylista verziószámmal, PHP- és adatbázis-verzió, tárhelytípus, cache- és CDN-réteg.
- Profilozó kimenete: lekérdezésszám, a három leglassabb lekérdezés, PHP-futásidő, csúcsmemória, külső HTTP-hívások száma és célja.
- Elvégzett próbák és eredményük: mely bővítménycsoport volt kikapcsolva, mit mértél alapértelmezett sablonnal, minden lépés utáni medián értékkel.
- Változásnapló és következő hipotézis: mi történt az oldallal a lassulás előtti 14 napban (frissítés, új bővítmény, importált termékek, kampányindulás), és egy mondatban a legvalószínűbb ok, amit ellenőrizni kérsz.
Ez a napló azért ér sokat, mert a rétegek lezárását dokumentálja. Egy fejlesztőnek nem az a hasznos, hogy „lassú az oldal”, hanem hogy „a statikus fájl 40 ms, a cache nélküli HTML 2,3 s, alapértelmezett sablonnal 2,1 s, tehát nem a sablon, és a profilozó 1400 lekérdezést mutat a termékoldalon”. Ez a mondat órákat spórol.
A méréssel töltött idő eleinte soknak tűnik, és a beavatkozás csábítóbb, mert látszik a munka. De az a beavatkozás, ami nem mérésből következik, nem javítás, csak változtatás. A különbség két hét múlva látszik meg, amikor kiderül, vissza tudod-e vonni.
Források és további olvasnivalók
- Google Search Central: oldalélmény és Core Web Vitals dokumentáció
- web.dev: LCP, INP, CLS és TTFB útmutatók
- Chrome DevTools hivatalos dokumentáció (Network és Performance panel)
- MDN Web Docs: Server-Timing, Cache-Control, Navigation Timing
- W3C: Server Timing és Resource Timing specifikáció
- WordPress Developer Resources: WP_DEBUG, Query Monitor
- curl hivatalos dokumentáció (write-out változók)
- HTTP Archive: Web Almanac teljesítmény-fejezetek
- Mindig kívülről befelé mérj: statikus fájl, cache nélküli HTML, renderelés, erőforrások.
- Ha a statikus fájl is lassan jön, felesleges a sablont és a bővítményeket bántani.
- A bővítményeket staging környezetben, felezéssel szűkítsd, ne az éles oldalon egyesével.
- Gyors főoldal és lassú termékoldal jellemzően lekérdezés- vagy sablonlogika-probléma, nem szerverkapacitás.
- Lassú bejelentkezett nézet mellett a gyors kijelentkezett nézet a cache megkerülésére utal, nem gyorsulásra.
Gyakori kérdések
Elég a PageSpeed Insights pontszám a hibakereséshez?
Nem, mert egyetlen összesített szám, ami elrejti, hogy szerver-, sablon- vagy erőforrás-problémáról van-e szó. Kiindulásnak jó, de a rétegenkénti mérést (statikus fájl, cache nélküli HTML, renderelés, erőforrások) nem váltja ki.
Miért kell staging környezet a bővítmények teszteléséhez?
Mert az éles oldalon a kikapcsolás közben a látogatók törött vagy hiányos oldalt látnak, és egyes bővítmények kikapcsoláskor adatot vagy beállítást is elveszíthetnek. A stagingen ugyanazt a felezéses szűkítést kockázat nélkül végigviheted.
Hány mérésből érdemes következtetni?
Legalább ötből, és a mediánt jegyezd fel. A megosztott tárhelyek terhelése percről percre változik, ezért egyetlen mérésből levont következtetés inkább véletlen, mint diagnózis.
Megoldja-e a cache-bővítmény a lassú oldalt?
A cache elrejti a lassúságot, nem szünteti meg. Bejelentkezett látogatónál, kosárnál és pénztárnál általában megkerülik a lapszintű cache-t, ezért ott előjön a valódi előállítási idő. Először mérj cache nélkül, és csak utána tegyél rá gyorsítótárat.
Mit tegyek, ha a statikus fájl is lassan jön?
Akkor a tárhely, a hálózati útvonal vagy a TLS-beállítás a szűk keresztmetszet, és a bővítmények vizsgálata felesleges. Kérd meg a szolgáltatót a szerver terhelésének ellenőrzésére, és mérj más országból is, hogy kiderüljön, útvonal- vagy gépproblémáról van-e szó.
Honnan tudom, hogy N+1 lekérdezési probléma van?
A lekérdezés-figyelő eszközben ugyanaz a lekérdezéstípus sokszor, ciklusszerűen ismétlődik, és a lekérdezésszám az elemek számával arányosan nő. Ez erős jel, de a végleges megerősítés a profilozó hívási láncából jön.
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.