Megnyitod az oldalad. Egy másodperc. Kettő. Három. Még mindig tölt.
Tudod, hogy a látogatóid ugyanezt látják – és azt is tudod, hogy ők nem várnak. A mobilozók 53 százaléka otthagyja az oldalt, ha 3 másodpercnél tovább tart a betöltés. Ez nem vélemény, ez Google-adat. És mégis, a legtöbb magyar WordPress oldal – most, 2025-ben – lassabb ennél.
Ebben a cikkben megnézzük, mi áll mögötte: mi lassítja le a WordPress oldalakat valójában, mit jelent ez a számokban, és mit lehet tenni ellene. Akkor is, ha nem vagy fejlesztő – és akkor is, ha már megpróbáltad megoldani, de nem segített.
Az a bizonyos tévhit a tárhelyről
Az első és leggyakoribb reflex: „Tárhelyet kell váltani.”
Megértem, miért gondolják ezt sokan. Ha lassú az autó, logikusnak tűnik nagyobb motort venni. De a WordPress lassúsága az esetek 70–80 százalékában nem a szerver teljesítményének kérdése. Több mint 70 aktív WordPress oldalt tartok karban, és ezt újra meg újra látom: az oldal saját tartalmai, beállításai és rétegesen felhalmozott hibái lassítják le – nem az a szerver, amin fut.
Gondolj bele, hogy épül fel egy tipikus WordPress oldal az évek alatt. A fejlesztő elkészíti az oldalt, de a sebességgel nem foglalkozik – mert nem kérik tőle. A képek felkerülnek ahogy vannak, kamerafotó méretben, tömörítés nélkül. Pluginek kerülnek rá, mert kényelmes, mert valaki ajánlotta, mert „hátha kell”. A Google Fonts alapból a Google szervereiről töltődik. Fél év, egy év – és az oldal csendben „meghízik”, mire valaki észreveszi, a Google már régen hátrébb sorolta.
Ez nem a te hibád. Így működik a legtöbb WordPress oldal – és pontosan ezért van szükség célzott optimalizálásra.
Az 5 leggyakoribb ok, amiért lassú a WordPress oldalad
1. Tömörítetlen képek
Az oldal teljes méretének általában 60–80 százaléka kép. Ha a fotóid úgy kerülnek fel, ahogy a kamerából kijönnek – 4–5 megabájtos fájlokban –, akkor ezt a terhet minden látogató minden egyes oldalbetöltésnél letölti. Mobilon, gyengébb hálózaton ez 10 másodperc is lehet.
A megoldás három lépés: WebP formátum, megfelelő képméret és lazy loading – vagyis a képek csak akkor töltődnek be, ha a felhasználó letekert hozzájuk. Ezzel az oldalsúly 60–80 százalékkal csökkenthető, az eredmény azonnali és érzékelhető.
Ami kevésbé ismert: a WebP ugyanolyan minőségű képet ad, mint a JPEG vagy PNG, de 25–35 százalékkal kisebb fájlméretben. Az AVIF formátum még ennél is hatékonyabb, és a modern böngészők már mindkettőt kezelik.
2. Felesleges vagy lassú pluginek
Minden telepített plugin PHP kódot futtat, adatbázist kérdez le, HTTP kéréseket ad hozzá az oldalhoz. Egy 35–40 plugines WordPress oldal szinte biztosan kétszer lassabb a szükségesnél – nem azért, mert a pluginek rosszak, hanem mert sok esetben egymást átfedő funkciókat látnak el, vagy eleve lassúak.
Amit kevesen tudnak: nem minden plugin egyformán lassít. Van, amelyik teljesen átlátható teljesítmény szempontjából – és van, amelyik önmagában fél-egy másodpercet tesz a betöltési időhöz. Ezt nem érzésre, csak méréssel lehet megmondani.
Egy alapos plugin audit megmutatja, melyik okoz valódi terhelést, melyiket lehet könnyebb alternatívával leváltani, és melyiket lehet egyszerűen kikapcsolni. Az eredmény általában meglepő.
3. Render-blocking CSS és JavaScript fájlok
Ez talán a legkevésbé ismert – mégis az egyik legsúlyosabb – sebességprobléma.
Amikor megnyitsz egy weboldalt, a böngésző sorban tölti le a fájlokat: HTML, CSS, JavaScript. Ha egy CSS vagy JS fájl úgy van beállítva, hogy „blokkoló” – vagyis a böngészőnek meg kell várnia a letöltését, mielőtt az oldalt megjelenítené –, a felhasználó fehér képernyőt lát. Ez az a pár másodperces fehér semmi, amit mindannyian ismerünk és utálunk.
A megoldás: defer és async betöltés a JavaScript fájloknál, és a kritikus CSS közvetlen beágyazása a HTML-be, hogy az oldal megjelenjen, mielőtt az összes fájl letöltődik.
4. Nem optimalizált adatbázis
A WordPress adatbázisában hónapok, évek alatt csendben gyűlnek fel a felesleges adatok. Post revíziók – minden egyes mentésnél új verzió születik. Spam kommentek ezres nagyságrendben. Törölt pluginek és bejegyzések után maradt orphan meta adatok. Lejárt tranzient opciók, amelyek sosem törlődnek maguktól.
Ezek nem láthatók a felületen, de lelassítják az összes adatbázis-lekérést. Egy megtisztított adatbázis nemcsak gyorsabb – a backup is kisebb lesz tőle, a migráció is egyszerűbb.
5. Hiányzó vagy rosszul beállított cache
Ha a weboldalad TTFB-je (Time to First Byte – az idő, amíg a szerver elküldi az első adatot) meghaladja az 500 milliszekundumot, az komoly probléma.
Cache nélkül minden oldalbetöltésnél a WordPress nulláról építi fel az oldalt az adatbázisból: PHP fut, SQL lekérések zajlanak, minden összerakódik. Ez kb. olyan, mintha minden alkalommal nulláról főznéd el a vacsorát, ahelyett, hogy egyszer elkészítenéd és felmelegítenéd.
A page cache ezt megoldja: az első betöltés után elmenti a kész HTML-t, és azt tállalja az összes következő látogatónak. Ennek eredménye: a TTFB 500 ms-ről akár 50–100 ms-re eshet. A legnépszerűbb megoldások: LiteSpeed Cache (LiteSpeed szerveren kiemelkedő), WP Rocket (bármely szerveren megbízható), W3 Total Cache (haladóknak). De ezeket jól kell beállítani – egy rosszul konfigurált cache plugin képes rontani a helyzeten.
Mit jelent mindez a számokban?
Sokan azt gondolják, a lassú oldal csak kényelmetlenség. Nem az.
53% – a mobilfelhasználók aránya, akik elhagyják az oldalt, ha 3 másodpercnél tovább tölt. 7% – konverziócsökkenés minden egyes másodperc késlekedésnél. Ha az oldal 4 másodperc helyett 2 alatt tölt be, az matematikailag 14 százalékkal több megkeresést, leadet, rendelést jelent.
2021 óta a Core Web Vitals mutatók közvetlen Google rangsorolási tényezők. A lassú oldal tehát nemcsak látogatókat veszít, hanem organikus forgalmat is – mert a Google hátrébb sorolja. Ha ráadásul Google Ads hirdetéseket futtatsz lassú landing page-re, a Quality Score csökken, és a kattintásonkénti ár emelkedik. Ugyanannyit fizetsz, kevesebb emberért.
Az összefüggés egyértelmű: gyorsabb oldal = kevesebb visszafordulás = több ügyfél = jobb SEO pozíció = olcsóbb hirdetési forgalom.
A Google Fonts – az apró részlet, ami meglepően sokat számít
A Google Fonts az egyik legnépszerűbb webes betűtípus-megoldás – és az egyik leggyakrabban rosszul konfigurált elem WordPress oldalakon.
Az alapértelmezett betöltés így néz ki: az oldal megnyitásakor a böngésző kapcsolatot vesz fel a Google szervereivel, elkéri a betűtípus fájlt, letölti, majd megjeleníti a szöveget. Ez minden egyes oldalbetöltésnél megtörténik – extra DNS lekérés, extra kapcsolat, extra várakozás.
A megoldás kétlépéses. Első: lokális betöltés – a betűtípus fájlokat egyszer letöltjük és a saját szerveren tároljuk. A böngészőnek többé nem kell kommunikálnia a Google szervereivel. Második: font-display: swap beállítás, ami biztosítja, hogy a szöveg azonnal megjelenjen egy tartalék betűtípussal, miközben a végleges betöltődik.
Mellékhatásként: ha a betűtípus a saját szerverről töltődik, az európai látogatók IP-je nem kerül át a Google szervereire – ami GDPR szempontból is tisztább megoldás.
Mit mutat valójában a Google PageSpeed Insights?
Sokan megnyitják a PageSpeed Insights-ot, látják a piros 34-es pontszámot, és nem tudják, mit kezdjenek vele. A legfontosabb mutatók:
Performance score (0–100): Az 50 alatti érték komoly problémákat jelez. A 90 feletti a cél – de a 80 feletti már elfogadható. Fontos: a mobil score a mérvadó, nem az asztali. A Google a mobil verziót indexeli, és szimulált mobilhálózatot használ a mérésnél, ezért a mobil szám szinte mindig alacsonyabb.
LCP – Largest Contentful Paint: Az az idő, amíg az oldal legfontosabb látható eleme (általában a főkép vagy az H1 cím) megjelenik. Google elvárás: 2,5 másodperc alatt. Ha ez 4–5 másodperc, az piros zóna.
FCP – First Contentful Paint: Az az idő, amíg az oldal bármilyen látható tartalmat mutat. Célérték: 1,8 másodperc alatt.
TBT – Total Blocking Time: Az összes blokkoló JavaScript futási ideje összesítve. Ha magas, az oldal lassú és „ragadós” érzetű – még akkor is, ha vizuálisan már betöltött.
CLS – Cumulative Layout Shift: Az oldal elemeinek ugrálása betöltés közben. Ha egy gomb betöltés közben 200 pixelt ugrik, és véletlenül rákattintasz – ez CLS-probléma. A felhasználói élménynek és a konverziónak egyaránt árthat.
Ezeket a mutatókat nem egyenként kell javítani – a legtöbb összefügg egymással. Egy jól végrehajtott optimalizálás egyszerre több mutatón is javít.
Mikor nem elég a cache plugin?
Sok vállalkozó telepít egy cache plugint, és azt gondolja, megoldotta a sebességproblémát. Ez részben igaz – de tényleg csak részben.
A cache javít a TTFB-n és az általános betöltési időn. De nem tömöríti a képeket, nem javítja a render-blocking szkripteket, nem auditálja a felesleges plugineket, nem tisztítja az adatbázist, és nem lokalizálja a betűtípusokat. Ezek a problémák egymást erősítve katasztrofális PageSpeed score-hoz is vezethetnek. Egy komplex WordPress gyorsítás mindezeket együtt kezeli.
Hogyan néz ki a WordPress gyorsítás a valóságban?
Sebesség-audit. Az első lépés mindig a mérés: PageSpeed Insights, GTmetrix és Lighthouse elemzés. Nem tippelünk – megnézzük, mi pontosan mi lassít, milyen súllyal. Egy-egy oldalnál akár 10–15 különböző sebességproblémát is azonosítunk.
Prioritizálás. Nem minden probléma egyforma. Van fix, amelyik 2 perc alatt 30 százalékos javulást hoz – és van, amelyik órákat vesz igénybe, és csak néhány százalékot ad. A sorrendet szakmai szempontok döntik el.
Backup – kivétel nélkül. Mielőtt bármit megérintünk az oldalon, teljes mentés készül. Ha bármi nem a várt módon működik, egy gombnyomással visszaállítható az eredeti állapot.
Az optimalizálás. Képek tömörítése és WebP konverzió, cache konfiguráció, CSS/JS minifikálás és defer betöltés, Google Fonts lokalizálás, adatbázis-tisztítás, plugin audit – minden lépés dokumentálva.
Mérési riport. Az átadáshoz előtte-utána képernyőképeket és mérési eredményeket adunk: PageSpeed score, LCP idő, oldalsúly, HTTP kérések száma. Nem marketingszöveg: a valódi számok.
Mennyi javulásra lehet számítani – egy valós példa
Egy WooCommerce webshop, amin az audit a következőket találta:
- 4,8 MB-os oldalsúly, tömörítetlen képekkel
- Render-blocking Google Fonts betöltés
- 94 HTTP kérés
- LiteSpeed Cache nélküli szerver konfiguráció
- PageSpeed mobil score: 34
Az optimalizálás után:
- Oldalsúly: 4,8 MB → 1,2 MB (75% csökkentés)
- HTTP kérések: 94 → 38
- LCP: 5,2 mp → 2,0 mp
- PageSpeed mobil score: 34 → 98
Ez nem kivételes eset – ez az átlag. A legtöbb oldalnál a mobil score 30–40-ről 80 fölé kerül, az LCP idő 4–6 másodpercről 1,5–2,5 másodpercre csökken.
WooCommerce webshopok – miért más ez a kategória?
A WooCommerce webshopok különleges esetet jelentenek, mert dinamikus tartalmakat kezelnek: kosár, termék-elérhetőség, árak, felhasználói munkamenetek. Ezeket nem lehet ugyanúgy cachelni, mint egy statikus bemutatkozó oldalt.
WooCommerce esetén a gyorsítás külön figyelmet igényel. Object cache (Redis vagy Memcached) a dinamikus tartalmakhoz, fragment caching – csak a statikus részeket cacheljük, a dinamikusokat nem –, termékoldalak egyenkénti optimalizálása, és külön figyelem a checkout sebességére, mert a kosár és a pénztár lassúsága közvetlen konverzióveszteséget jelent. Egy 1 másodperccel gyorsabb terméklap statisztikailag mérhető bevételnövekedést hoz.
Apache, Nginx, LiteSpeed – nem mindegy, melyiken fut az oldalad
Bár az elmondottak alapján a tárhely ritkán a fő probléma, a szerver típusa mégis befolyásolja az optimalizálási stratégiát.
Apache – a leggyakoribb, de sebességoptimalizálás szempontjából nem a legjobb választás. Apache-on a legjobb kombináció általában a WP Rocket és egy CDN.
Nginx – jobb teljesítményű, különösen nagy forgalom esetén. A FastCGI cache Nginx-en rendkívül hatékony tud lenni.
LiteSpeed – ez a legjobb kombináció WordPress-hez, ha a tárhely ezt kínálja. A LiteSpeed Cache plugin natívan integrálódik a szerverrel, és olyan szintű cache-elést tesz lehetővé, amit Apache-on vagy Nginx-en nehéz elérni. Ha a tárhelyed LiteSpeed-et kínál és nem használod a LiteSpeed Cache plugint, komoly lehetőséget hagyasz az asztalon.
CloudLinux – ez operációs rendszer szintű megoldás, amit sok managed WordPress tárhely használ. Biztosítja, hogy egy „rossz szomszéd” (egy másik ügyfél a szerveren) ne rontsa a te oldalad teljesítményét.
A szerver típusát általában a tárhely vezérlőpanelén (cPanel, Plesk) vagy a válaszfejlécek alapján lehet ellenőrizni. Ezért is fontos az audit első lépéseként ezt is megnézni.
Érdemes-e CDN-t használni?
A CDN (Content Delivery Network) az oldal statikus fájljait – képek, CSS, JS – több földrajzi helyen lévő szerverről tállalja. Ha egy látogató Debrecenből nyitja meg az oldalad, a fájlokat a hozzá legközelebb eső CDN-csomópontról kapja.
Ha az oldalad látogatói szétszórtan helyezkednek el – egész Magyarországról vagy más országokból is jönnek –, a CDN érzékelhetően csökkenti a betöltési időt. Cloudflare az egyik leginkább elterjedt megoldás: az ingyenes csomag is rendelkezik CDN-nel, DDoS védelemmel, SSL tanúsítvánnyal és tűzfallal. BunnyCDN gyors és olcsó, kifejezetten jó választás közepes méretű oldalakhoz. KeyCDN megbízható, jó európai lefedettséggel.
Fontos: a CDN önmagában nem old meg minden problémát. Ha az alapoptimalizálás nincs elvégezve, a CDN csak minimálisan javít. Ha viszont az alap rendben van, a CDN valódi bónuszt ad a végeredményhez.
Tárhelyváltás vs. optimalizálás – mit hoz a kettő?
Aki tárhelyet vált sebesség reményében, az általában 10–15 százalékos javulást tapasztal, ha szerencsés. Egy komplex optimalizálás ugyanazon a tárhelyen 40–70 százalékos javulást hoz. A tárhely csak a TTFB-n segít – és ez az összes sebességprobléma egyik kis szegmense. Nem csökkenti az oldalsúlyt, nem oldja meg a render-blocking fájlokat, nem tömöríti a képeket.
Az egyetlen eset, amikor érdemes először tárhelyet váltani: ha a TTFB 1–2 másodperc felett van, és egyértelműen a szerver a szűk keresztmetszet. Ezt az audit azonnal megmutatja.
Mikor kell profi segítség?
Sokan próbálják saját maguk megoldani a sebességproblémát. Vannak, akiknek ez sikerül – főleg, ha van alapszintű technikai tudásuk és idejük. De néhány helyzet van, amikor a DIY megközelítés többet árthat, mint használ.
Ha cache plugin telepítése után romlott az oldal. Ez megtörténik – egy rosszul konfigurált cache plugin CSS-t cachelhet frissítés után, vagy dinamikus tartalmakat (kosár, bejelentkezett felhasználók adatai) helytelen állapotban tálalja. Cache-beállítás nem egyszerű feladat, különösen WooCommerce esetén.
Ha megjavítottad, de a számok nem javultak. Sokszor előfordul, hogy valaki telepít egy optimalizáló plugint, az zöldet mutat – de a PageSpeed score nem mozdul. Ennek oka általában az, hogy a plugin nem érte el a valódi szűk keresztmetszeteket.
Ha azt mondják, „ez így normális”. Sajnos néha mondják. Egy WordPress fejlesztő feladata az, hogy az oldal működjön – a sebességoptimalizálás külön szakterület, amit sokan nem ismernek mélyen.
Ha Google Ads hirdetéseket futtatsz lassú landing page-re. Ebben az esetben minden nap pénzt veszítesz: drágábban éred el a kattintásokat, és kevesebb ügyfelet szerzel belőlük. A gyorsítás megtérülése ilyen esetben szinte azonnali.
Mit tehetsz most azonnal?
Ha eljutottál idáig, valószínűleg felismerted az oldalad egyik-másik problémáját. Íme, amit azonnal megcsinálhatsz:
- Mérd meg az oldalad. Látogass el a PageSpeed Insights oldalra, add meg a weboldalad URL-jét, és nézd meg a mobil pontszámot. Ha 50 alatt van, komoly teendők várnak.
- Ellenőrizd az oldalsúlyt. A GTmetrix.com ingyenesen megmutatja az oldal méretét és a HTTP kérések számát. Ha 2 MB felett van, a képoptimalizálás biztosan segít.
- Számold meg a plugineket. Ha 30 felett van, szinte biztosan van felesleges közöttük.
- Nézd meg a TTFB-t. A GTmetrix Waterfall nézetében az első sor mutatja a szerver válaszidejét. Ha 500 ms felett van, a szerver konfigurációt is érdemes vizsgálni.
- Nyisd meg mobilon, valódi hálózaton. A PageSpeed szimulált körülményeket mér. Nyisd meg az oldalad egy 4G-s mobilon, és figyeld meg, mennyit vársz – ez az a valódi élmény, amit a látogatóid tapasztalnak.
Ha ezeket megnézted és komoly problémákat látsz – vagy ha nem tudod értelmezni a számokat –, érdemes szakmai felmérést kérni. Ez elvégzi a diagnózist, és pontosan megmutatja, mi a baj és mit érdemes tenni.
