WordPress sebesség: teljes útmutató

A WordPress sebesség három rétegen múlik: a szerveren (hosting, PHP-verzió, adatbázis), a gyorsítótárazáson (oldal-, objektum- és böngészőcache) és a front-enden (képek, CSS, JavaScript, betűtípusok). A leggyorsabb javulást általában az oldalcache bekapcsolása, a képek optimalizálása és a felesleges bővítmények eltávolítása hozza. Az eredményt mindig valós felhasználói adatokkal, Core Web Vitals mutatókkal mérd.

Alapfogalmak

Mielőtt bármit állítanál a beállításokon, érdemes tisztázni, mit jelent pontosan a „gyors” egy WordPress oldalnál. A sebesség nem egyetlen szám. Egy oldal lehet gyors a szerveren, de lassú a böngészőben, és fordítva: a szerver villámgyorsan válaszol, a látogató mégis másodpercekig egy üres vagy ugráló felületet néz. Ezért a fogalmakat érdemes rétegenként szétválasztani.

TTFB: az első bájtig eltelt idő

A TTFB (Time to First Byte) azt méri, mennyi idő telik el a kérés elküldésétől addig, amíg a böngésző megkapja a válasz első bájtját. WordPressnél ez főleg azon múlik, hogy a szervernek minden kérésnél le kell-e futtatnia a PHP-t és le kell-e kérdeznie az adatbázist, vagy egy kész, gyorsítótárazott HTML-t ad vissza. Magas TTFB jellemzően gyenge hostingra, cache hiányára vagy egy nehéz bővítményre utal.

Core Web Vitals

A Google által használt felhasználói élmény mutatók közül hármat érdemes fejből tudni:

Mutató	Mit mér	„Jó” küszöb
LCP (Largest Contentful Paint)	Mikor jelenik meg a legnagyobb látható elem (gyakran a hero kép vagy a főcím)	2,5 másodperc vagy kevesebb
INP (Interaction to Next Paint)	Mennyire gyorsan reagál az oldal kattintásra, gépelésre	200 ms vagy kevesebb
CLS (Cumulative Layout Shift)	Mennyit ugrál a tartalom betöltés közben	0,1 vagy kevesebb

Az INP 2024-ben váltotta fel a korábbi FID mutatót, ezért ha régebbi útmutatóban FID-ről olvasol, az már elavult szempont. A küszöböket a látogatások 75. percentilisén értékelik, vagyis nem elég, ha a te gépeden gyors az oldal: a lassabb telefonokon és mobilneten is jónak kell lennie.

Labor adat és terepadat

Gyakori félreértés forrása, hogy kétféle mérés létezik. A labor adat (például egy Lighthouse futtatás) szimulált körülmények között, egyszeri méréssel készül, ezért hibakeresésre kiváló. A terepadat valódi látogatók böngészőiből származik (Chrome felhasználói adatok), és ez az, ami a keresőoptimalizálás szempontjából számít. A kettő eltérhet, és ez normális.

Cache típusok egy mondatban

Oldalcache: a teljes legenerált HTML-t eltárolja, így a következő látogatónak már nem kell PHP-t futtatni.
Objektumcache: az adatbázis-lekérdezések eredményét tartja memóriában (például Redis vagy Memcached segítségével), ami bejelentkezett felhasználóknál és webshopoknál hasznos.
Böngészőcache: a statikus fájlokat (képek, CSS, JS) a látogató gépén tárolja, így visszatéréskor nem kell újra letölteni.
CDN cache: a fájlokat a látogatóhoz földrajzilag közelebbi szervereken tárolja.

Ha ezt a négy fogalmat és a három Core Web Vitals mutatót érted, a WordPress sebesség körüli beállítások nagy része logikussá válik. A sebesség egyébként a technikai SEO egyik pillére, a tágabb képet a WordPress SEO témakör adja.

Hogyan működik?

Ahhoz, hogy célzottan gyorsíts, látnod kell, mi történik egyetlen oldalbetöltés során. A WordPress dinamikus rendszer: alapállapotban minden egyes kérésre újra összerakja az oldalt. Ez rugalmas, de drága művelet, és itt keletkezik a legtöbb lassulás.

Egy kérés útja lépésről lépésre

A látogató böngészője DNS-lekérdezéssel megkeresi a szervert, majd kapcsolatot épít ki (TLS kézfogással HTTPS esetén).
A webszerver (például Nginx, Apache vagy LiteSpeed) fogadja a kérést. Ha van érvényes oldalcache, itt azonnal visszaküldi a kész HTML-t, és a folyamat nagy része kimarad.
Ha nincs cache, elindul a PHP: betöltődik a WordPress mag, az összes aktív bővítmény és a téma.
A WordPress lekérdezi az adatbázist: a bejegyzést, a menüket, a widgeteket, a beállításokat (köztük az automatikusan betöltött opciókat).
Elkészül a HTML, a szerver elküldi a böngészőnek.
A böngésző értelmezi a HTML-t, letölti a hivatkozott CSS, JavaScript, kép és betűtípus fájlokat, majd kirajzolja az oldalt.
A JavaScript lefut, és ettől lesz az oldal interaktív.

Az első öt lépés a szerveroldali idő, ez határozza meg a TTFB-t. A hatodik és hetedik a front-end, ez határozza meg főleg az LCP-t, az INP-t és a CLS-t.

Miért lassít minden bővítmény?

Minden aktív bővítmény a harmadik lépésnél betöltődik, akkor is, ha az adott oldalon semmit nem csinál. Egy kapcsolatűrlap-bővítmény például gyakran minden aloldalra betölti a saját CSS és JS fájljait, nem csak oda, ahol az űrlap van. Nem a bővítmények száma a döntő, hanem az, hogy mit csinálnak: egy jól megírt, kicsi bővítmény alig érezhető, egy rosszul megírt viszont minden kérésnél tucatnyi adatbázis-lekérdezést futtathat.

A renderelést blokkoló erőforrások

A böngésző a head részben lévő CSS-t és a szinkron módon betöltött JavaScriptet le kell, hogy töltse, mielőtt bármit kirajzolna. Ha egy téma tíz külön CSS fájlt és öt nagy szkriptet tölt be a fejlécben, a látogató addig fehér képernyőt lát. Ezért beszélnek az optimalizáló eszközök a kritikus CSS-ről (csak a hajtás feletti részhez szükséges stílusok előre betöltése) és a szkriptek késleltetéséről (defer, delay).

Szemléltető példa: hol megy el az idő

Vegyünk egy kitalált, de tipikus blogot: osztott tárhely, cache nélkül, egy népszerű oldalépítő témával és 25 bővítménnyel. Egy ilyen oldalnál nem ritka, hogy a szerver válasza önmagában közel egy másodpercig tart, utána pedig a böngésző több megabájtnyi képet és szkriptet tölt le. Ha bekapcsolod az oldalcache-t, a szerveroldali rész jellemzően töredékére csökken, de a front-end probléma (nagy hero kép, sok JS) érintetlen marad. Ez a példa csak szemléltetés, a valós számok oldalanként eltérnek, a lényeg a logika: a két réteget külön kell kezelni, és mindkettőt mérni.

Fő módszerek

A gyorsítási lépéseknek van egy ésszerű sorrendje. Azokkal kezdd, amelyek nagy hatásúak és kevés kockázattal járnak, és csak utána nyúlj a finomhangoláshoz, ami könnyen eltörhet valamit az oldalon.

1. Hosting és szerverkörnyezet

Ha a szerver alapból lassú, a többi lépés csak tüneti kezelés. Érdemes ellenőrizni, hogy a tárhely támogatott, aktuális PHP-verziót futtat-e (a régebbi verziók érezhetően lassabbak és biztonsági szempontból is kockázatosak), van-e szerveroldali cache, és használható-e objektumcache. Egy forgalmasabb webshopnál a megosztott tárhely gyakran szűk keresztmetszet lesz, ilyenkor egy menedzselt WordPress tárhely vagy VPS lehet a megoldás.

2. Oldalcache bekapcsolása

A legnagyobb egyszeri nyereség általában innen jön. Ha a tárhelyed saját cache megoldást kínál (például LiteSpeed szervernél a hozzá tartozó bővítményt, vagy menedzselt tárhelyeknél a beépített cache-t), azt használd. Ha nem, egy cache bővítmény is megoldja. Fontos szabály: egyszerre csak egy oldalcache megoldás fusson, két egymásra rakott cache bővítmény ütközést és furcsa hibákat okoz.

3. Képoptimalizálás

Méretezd át a képeket feltöltés előtt a valós megjelenítési méretre, ne tölts fel 5000 pixel széles fotót egy 800 pixeles helyre.
Használj modern formátumot (WebP vagy AVIF), a WordPress újabb verziói ezt már alapból kezelik.
Adj meg szélességet és magasságot minden képnek, ez megelőzi a CLS-t.
A hajtás alatti képeket töltsd lustán (lazy loading), de a hero képet, ami az LCP elem, ne: azt épp hogy előre érdemes betölteni.

4. CSS és JavaScript

Itt történik a legtöbb törés, ezért óvatosan haladj. A sorrend: először távolítsd el, amit nem használsz (felesleges bővítmény, oldalépítő modul), aztán állítsd be, hogy a bővítmények csak ott töltsenek be fájlokat, ahol kellenek, és csak a végén kísérletezz minifikálással, összevonással, késleltetéssel. A szkriptek késleltetése különösen sokat javíthat az INP-n és a betöltési időn, de a menük, sliderek, sütibanner működését minden módosítás után ellenőrizd.

5. Betűtípusok

Kevesebb betűcsalád és kevesebb vastagság kevesebb letöltést jelent. A saját szerverről kiszolgált betűtípus megspórol egy külső kapcsolódást, a font-display: swap pedig megakadályozza, hogy a szöveg láthatatlan maradjon a betöltés alatt.

6. Adatbázis karbantartás

A régi revíziók, a lejárt átmeneti adatok és a törölt bővítmények által hátrahagyott, automatikusan betöltött opciók idővel lassíthatják a lekérdezéseket. Mentés után érdemes időnként kitakarítani.

Döntési szabály: mivel kezdj?

Ha ezt látod	Akkor először ezt nézd
Magas TTFB minden oldalon	Hosting, oldalcache, PHP-verzió
Jó TTFB, de rossz LCP	Hero kép mérete, renderblokkoló CSS, betűtípus
Rossz INP	Nehéz JavaScript, oldalépítő, harmadik féltől származó szkriptek
Rossz CLS	Méret nélküli képek, hirdetések, késve betöltődő betűtípus vagy sütibanner
Csak az admin lassú	Objektumcache, adatbázis, nehéz bővítmény a háttérben

Gyakori hibák

A WordPress gyorsítás tele van jó szándékú, de hibás lépésekkel. Az alábbiak azért érdekesek, mert sokszor ezek miatt nem javul az oldal, vagy javul a pontszám, miközben a valódi élmény romlik.

Pontszámvadászat a valós élmény helyett

A legelterjedtebb tévhit, hogy a cél a 100-as Lighthouse pontszám. A pontszám egy szimulált, egyszeri mérés összegzése, a rangsorolás szempontjából viszont a terepadat számít. Láttunk már olyan helyzetet (tipikus mintázat), hogy egy agresszív szkriptkésleltetés felhúzza a labor pontszámot, közben a valódi felhasználónál a menü csak az első görgetés után válik kattinthatóvá. Ez rontja az élményt, amit a pontszám nem mutat meg.

Több cache bővítmény egyszerre

Két oldalcache bővítmény, vagy egy tárhelyszintű cache mellé telepített másik cache bővítmény gyakran ütközik: elavult oldalak jelennek meg, a kosár rosszul frissül, a bejelentkezés furcsán viselkedik. Egy réteg, egy eszköz.

Minden optimalizáció bekapcsolása egyszerre

Ha egy cache bővítményben egyszerre kapcsolod be a CSS összevonást, a JS késleltetést, a kritikus CSS generálást és a lusta betöltést, és valami eltörik, nem fogod tudni, mi okozta. Mindig egyesével kapcsolj, és minden lépés után nézd meg az oldalt privát böngészőablakban, mobilon is.

A hero kép lusta betöltése

A lazy loading jó dolog, de a hajtás feletti fő kép esetén pont rossz: a böngésző később kezdi el letölteni, ezért romlik az LCP. Egyes témák és bővítmények minden képre automatikusan ráteszik, ezt érdemes ellenőrizni.

Webshop és bejelentkezett felhasználók elfelejtése

Az oldalcache a kosár, a pénztár és a fiókoldal esetén általában ki van kapcsolva, mert ott személyre szabott tartalom van. Ha csak a nyitóoldalt méred, a vásárlás leglassabb lépései rejtve maradnak. WooCommerce oldalnál ezeket külön kell mérni, és itt sokat segíthet az objektumcache.

További tipikus hibák röviden

Inaktív, de telepítve hagyott bővítmények (sebességet nem, de biztonsági kockázatot jelentenek, és a takarítás logikáját is zavarják).
Túl sok harmadik féltől származó szkript: csevegőablak, több analitika, hőtérkép, pixel, amelyeket senki nem néz.
Videó beágyazása közvetlenül, előnézeti kép helyett.
Elavult PHP-verzió, mert „eddig is működött”.
Cache ürítés elfelejtése módosítás után, ami miatt a változtatás hatástalannak tűnik.
Optimalizálás mentés nélkül, éles oldalon, tesztkörnyezet nélkül.

Ellenpélda: amikor a bővítmény törlése nem segít

Sokan a bővítmények számát okolják. Ha viszont a lassulást egy nehéz oldalépítő téma vagy egy lassú külső API-hívás okozza, öt kisebb bővítmény törlése szinte semmit nem fog változtatni. Előbb mérj (például egy lekérdezés-figyelő bővítménnyel tesztkörnyezetben), aztán törölj.

Mérés

Mérés nélkül a gyorsítás találgatás. A cél nem egy szép szám, hanem annak igazolása, hogy egy adott módosítás valóban javított a látogatók élményén. Ehhez kétféle eszköz és egy fegyelmezett folyamat kell.

Eszközök és mire valók

Eszköz	Adattípus	Mire használd
PageSpeed Insights	Terepadat (ha van elég forgalom) és labor adat	Gyors állapotfelmérés egy adott URL-re
Search Console, Core Web Vitals jelentés	Terepadat, URL-csoportokra	Melyik oldaltípus problémás az egész webhelyen
Chrome fejlesztői eszközök (Lighthouse, Performance panel)	Labor adat	Hibakeresés: melyik fájl, melyik szkript lassít
Vízesés diagramot mutató tesztelő	Labor adat	A letöltések sorrendjének, méretének vizsgálata

A terepadat késve frissül, mert egy hosszabb időszak összesített értékét mutatja, ezért egy módosítás hatása nem jelenik meg másnap. Ez nem hiba, hanem a mérés természete.

Mérési workflow lépésről lépésre

Alapállapot rögzítése: válassz ki oldaltípusonként egy reprezentatív URL-t (nyitóoldal, blogbejegyzés, kategóriaoldal, termékoldal, pénztár). Írd fel a terepadatot és három labor futtatás mediánját, mobil nézetben.
Hipotézis: egy mondatban fogalmazd meg, mit vársz („a hero kép WebP-re cserélése javítja az LCP-t a blogbejegyzéseken”).
Egyetlen módosítás: egyszerre csak egy dolgot változtass, lehetőleg tesztkörnyezetben.
Cache ürítés: minden rétegben (bővítmény, szerver, CDN).
Újramérés: ugyanazokon az URL-eken, ugyanazzal a beállítással, ismét három futtatás mediánjával.
Funkcionális ellenőrzés: menü, űrlap, kosár, sütibanner működik-e mobilon is.
Naplózás: dátum, módosítás, eredmény egy egyszerű táblázatba.
Terepadat visszaellenőrzése néhány hét múlva a Search Console jelentésben.

Miért a medián?

A labor mérések között futtatásonként is lehet eltérés a hálózat és a szerverterhelés miatt. Egyetlen mérés alapján könnyű rossz következtetést levonni. Három futtatás mediánja kiszűri a kiugró értékeket, és jóval megbízhatóbb összehasonlítást ad.

Ellenőrzőlista egy sebességauditra

Támogatott, aktuális PHP-verzió fut?
Pontosan egy oldalcache megoldás aktív?
Van objektumcache, ha webshop vagy sok bejelentkezett felhasználó van?
Az LCP elem nincs lustán betöltve, és megfelelő méretű?
Minden képnek van megadott mérete?
A bővítmények csak ott töltenek be fájlokat, ahol szükség van rájuk?
Felmérted és megindokoltad a harmadik féltől származó szkripteket?
A betűtípusok száma minimális, és van font-display beállítás?
Megnézted külön a kosár és pénztár oldalakat?
Van napló a módosításokról és mért eredményeikről?

Ha ezt a listát negyedévente egyszer végigviszed, a WordPress sebesség nem egy egyszeri projekt lesz, hanem karbantartott állapot, ami a bővítményfrissítések és új tartalmak mellett is stabil marad.

Kapcsolódó részletes útmutatók

A sebesség a technikai SEO része, de önmagában nem hoz rangsort: a tartalom, a metaadatok, az indexelhetőség és a belső linkelés legalább ennyire számít. Ha a gyorsítás után a többi WordPress SEO beállítást is rendbe tennéd, az alábbi útmutatók segítenek továbblépni.

Mire figyelj az SEO bővítmény kiválasztásakor sebesség szempontból?

Az SEO bővítmények is a minden kérésnél betöltődő kódok közé tartoznak, ezért érdemes csak azokat a moduljaikat bekapcsolni, amelyeket ténylegesen használsz. Két SEO bővítmény párhuzamos futtatása nemcsak felesleges terhelés, hanem duplikált metaadatokhoz és ütköző sémajelölésekhez is vezethet. Válassz egyet, és azt állítsd be alaposan.

WordPress SEO: a témakör összefoglaló oldala.
WordPress SEO: teljes útmutató: a technikai és tartalmi alapok egy helyen.
Yoast SEO: teljes útmutató: beállítások és gyakori buktatók.
Rank Math: teljes útmutató: modulok és konfiguráció lépésről lépésre.
All in One SEO: teljes útmutató: telepítés, beállítás, ellenőrzés.

Javasolt sorrend: először a sebesség alapjait rendezd (cache, képek, felesleges bővítmények), utána állítsd be az SEO bővítményt, végül a mérési naplód alapján finomhangold mindkettőt. Így minden változtatás hatása külön látszik, és nem kell találgatnod, mi javított vagy mi rontott az eredményeken.