Egy lassú WordPress weboldalnál könnyű rögtön a tárhelyre, a bővítményekre vagy az Elementor használatára gyanakodni. A valóságban azonban egészen apró technikai részletek is látványosan befolyásolhatják a teljesítményt.
Előfordulhat, hogy egy nagy kép késlelteti az első tartalom megjelenését. Máskor egy olyan betűtípust tölt le a böngésző, amely végül sehol sem jelenik meg. Egy külső szolgáltatás, egy rosszul működő bővítmény vagy a szerver lassú válasza ugyanúgy állhat a háttérben.
Ezért a WordPress weboldal gyorsítását érdemes diagnózissal kezdeni.
A jó sorrend:
mérés → probléma azonosítása → célzott módosítás → újramérés.
Ez sokkal pontosabb megközelítés annál, mint amikor találomra telepítünk egy újabb optimalizáló bővítményt, majd reméljük, hogy gyorsabb lesz az oldal.
Mit jelent valójában az, hogy lassú a weboldal?
A látogató szempontjából egyszerű a helyzet: rákattint egy linkre és várnia kell.
A háttérben azonban több különböző folyamat zajlik.
A böngészőnek többek között:
- kapcsolatba kell lépnie a szerverrel;
- meg kell kapnia az oldal HTML-kódját;
- le kell töltenie a stíluslapokat;
- be kell töltenie a képeket;
- le kell kérnie a betűtípusokat;
- végre kell hajtania a szükséges JavaScriptet;
- fel kell építenie az oldal vizuális elrendezését;
- működőképessé kell tennie az interaktív elemeket.
A lassulás ezek bármelyik pontján kialakulhat.
Ezért két, hasonlóan lassúnak érződő WordPress weboldal mögött egészen eltérő technikai probléma állhat.
Az első kérdés tehát kevésbé az, hogy:
„Hogyan gyorsítsam fel?”
Sokkal hasznosabb így feltenni:
„Pontosan hol és miért lassul le?”
1. Először mérd meg az aktuális állapotot
Sebességoptimalizálás előtt érdemes rögzíteni a kiindulási állapotot.
Erre több eszköz használható, például:
- Google PageSpeed Insights;
- Chrome DevTools;
- Lighthouse;
- WebPageTest;
- GTmetrix.
Ezek eltérő részletességgel mutatják meg, hogyan töltődik be az oldal.
A PageSpeed Insights jó kiindulópont lehet, viszont egy fontos dolgot érdemes szem előtt tartani:
a PageSpeed-pontszám önmagában kevés diagnosztikai információt ad.
Egy 65-ös vagy 92-es értékből még nem derül ki, mit kell módosítani.
Sokkal érdekesebbek az alatta látható konkrét adatok.
Például:
- mikor jelenik meg a fő tartalom;
- mennyit kell várni a szerver válaszára;
- mely fájlok nagyok;
- milyen erőforrások késleltetik a megjelenítést;
- elmozdulnak-e az oldal elemei betöltés közben;
- mennyi JavaScriptet kell feldolgozni.
A mérés célja tehát elsősorban az, hogy megtaláljuk a szűk keresztmetszetet.
2. A tárhely már az első képpont megjelenése előtt számít
Egy WordPress weboldal jelentős része szerveroldalon áll össze.
Amikor a látogató megnyit egy oldalt, a szervernek többek között:
- el kell indítania a WordPress folyamatát;
- adatokat kell kérnie az adatbázisból;
- végre kell hajtania a szükséges PHP-kódot;
- össze kell állítania a választ.
Ha ez lassan történik, a böngésző már az első érdemi tartalomra is sokáig várhat.
Ennek oka lehet például:
- túlterhelt tárhely;
- kevés rendelkezésre álló erőforrás;
- lassú PHP-környezet;
- problémás bővítmény;
- lassú adatbázis-lekérdezés;
- külső rendszerre váró folyamat.
Mikor érdemes a tárhelyre gyanakodni?
Jellemző jel lehet például, ha:
- a WordPress adminisztráció is feltűnően lassú;
- több különböző oldal hasonlóan lassan indul;
- napszaktól függően nagy eltérések vannak;
- kevés tartalom mellett is hosszú ideig tart az első válasz.
Ilyenkor érdemes megnézni a szerveroldali válaszidőt, mielőtt képek optimalizálásával vagy további WordPress-bővítményekkel kezdünk foglalkozni.
A drágább tárhely önmagában szintén kevés garanciát ad. Először érdemes bizonyítani, hogy valóban a tárhelykörnyezet a probléma forrása.
3. A bővítményeknél a működés fontosabb, mint a darabszám
Gyakran hallani, hogy egy WordPress oldal azért lassú, mert „túl sok plugin van rajta”.
Ez így túl egyszerű megközelítés.
Tíz jól elkészített, kis erőforrásigényű bővítmény akár kisebb terhelést is jelenthet, mint egyetlen problémás plugin.
A fontosabb kérdések inkább ezek:
- milyen műveleteket végez;
- minden oldalbetöltéskor fut-e;
- mennyi adatbázis-lekérdezést indít;
- milyen CSS- és JavaScript-fájlokat tölt be;
- kommunikál-e külső szolgáltatással;
- megfelelően karbantartott-e;
- valóban szükség van-e rá.
Egy régebbi WordPress weboldalon különösen könnyen előfordul, hogy idővel felhalmozódnak olyan bővítmények, amelyek már alig látnak el feladatot.
A WordPress weboldal hosszú távú karbantartásának ezért része lehet a használaton kívüli komponensek időszakos felülvizsgálata is.
Diagnosztikához használható például a Query Monitor, amely segíthet megvizsgálni az adatbázis-lekérdezéseket és különböző WordPress-folyamatokat.
Fontosabb weboldalon a bővítmények tesztelését lehetőleg tesztkörnyezetben érdemes végezni, különösen akkor, ha űrlap, webshop, foglalás vagy más üzletileg fontos funkció is működik az oldalon.
4. A képek mérete gyakori teljesítményprobléma
A képek sok weboldalon a legnagyobb letöltendő elemek közé tartoznak.
Gyakori helyzet például, hogy egy 2500–3000 pixel széles kép kerül egy olyan blokkba, ahol valójában csak 600–800 pixel szélességben jelenik meg.
A látogató böngészője ilyenkor fölöslegesen tölt le jóval több adatot.
Képoptimalizálásnál több dolgot érdemes együtt nézni
- megfelelő képméret;
- megfelelő tömörítés;
- korszerű fájlformátum;
- reszponzív változatok;
- lazy loading;
- a kép szerepe az oldalon.
WebP vagy AVIF formátum használata sok esetben csökkentheti a fájlméretet.
Ugyanilyen fontos azonban az is, hogy a kép eleve megfelelő méretű legyen.
A lazy loading sem minden képnél jó
A képernyő alatt található képek késleltetett betöltése hasznos lehet.
A hero szakasz legfontosabb képe viszont gyakran már az első pillanatban szükséges.
Ha ezt is túl későn kezdi el letölteni a böngésző, maga az optimalizálási módszer ronthatja az érzékelt sebességet.
Itt is az adott elem szerepe számít.
5. A képek méretének megadása az oldal stabilitását is befolyásolja
A fájlméret mellett létezik egy másik, kevésbé látványos probléma.
A böngészőnek tudnia kell, mekkora helyet kell fenntartania egy képnek.
Ha egy kép szélessége és magassága csak a letöltés után válik ismertté, előfordulhat, hogy a körülötte lévő tartalom betöltés közben elmozdul.
Tipikus példa:
- megjelenik a fejléc;
- a böngésző még kevés helyet tart fenn a logónak;
- megérkezik a kép;
- a fejléc mérete megváltozik;
- az alatta lévő tartalom lejjebb ugrik.
Ez az oldal vizuális stabilitását rontja.
A Core Web Vitals egyik mérőszáma, a Cumulative Layout Shift – röviden CLS – éppen az ilyen váratlan elmozdulásokat vizsgálja.
Ezért egy logó vagy más fontos kép optimalizálásánál a fájlméret mellett a megfelelő méretinformáció is számít.
6. Egy valódi példa: mit mutatott meg az élezés.hu teljesítménymérése?
A teljesítményoptimalizálás egyik tanulsága számomra az volt, hogy a problémák egy része szerkesztés közben egyáltalán nem látható.
Az élezés.hu oldalán végzett teljesítménymérésnél például olyan betűtípus betöltésére derült fény, amelyet a weboldal látható felületén tudatosan sehol sem használtam.
A weboldal vizuálisan megfelelően jelent meg. A böngésző azonban a háttérben ettől még lekérte a fölösleges fontfájlt.
Ránézésre ezt gyakorlatilag lehetetlen lett volna észrevenni.
A teljesítménymérés és a böngésző által betöltött erőforrások vizsgálata mutatta meg, hogy olyan fájl is része a betöltési folyamatnak, amelyre az oldalnak már nincs szüksége.
Ez jól mutatja, hogy egy sablon, oldalépítő, korábbi beállítás vagy bővítmény akkor is hagyhat maga után fölösleges erőforrást, amikor annak már nincs látható nyoma a weboldalon.
Ugyanezen az oldalon a logó is tanulságos volt
Az élezés.hu logójánál nem volt megfelelően meghatározva a fix megjelenítési méret.
Ez elsősorban az elrendezés stabilitását érintette.
A böngésző csak a kép betöltése után tudta pontosabban meghatározni, mekkora helyre lesz szükség, ami hozzájárulhatott az elemek betöltés közbeni elmozdulásához.
A megoldás egyik esetben sem egy újabb „WordPress gyorsító plugin” telepítése volt.
Konkrét technikai részleteket kellett rendezni:
- a fölöslegesen betöltött betűtípus azonosítását;
- a ténylegesen szükséges fontok körének szűkítését;
- a logó méretének egyértelmű meghatározását;
- majd az oldal újramérését.
Ezért sebességoptimalizálásnál ma már előbb keresem az okot és csak utána választok megoldást.
Egyetlen mérés időnként többet ér, mint öt általános gyorsítási tipp.
7. A betűtípusokból is könnyen túl sokat tölthet be az oldal
A webfontok önmagukban teljesen indokolt részei lehetnek egy weboldal vizuális rendszerének.
A problémát inkább az okozza, amikor fölöslegesen sok változat töltődik be.
Például:
- több különböző betűcsalád;
- sok fontvastagság;
- dőlt változatok;
- olyan karakterkészletek, amelyekre nincs szükség;
- korábban használt, de már eltávolított betűtípusok.
Egy egyszerű tipográfiai rendszer gyakran kevesebb erőforrással is kialakítható.
Például:
- egy fő betűcsalád;
- néhány valóban használt vastagság;
- csak a szükséges fontfájlok.
Azt is érdemes ellenőrizni, hogy valóban csak a látható betűtípusok tölti be a rendszer?
Ahogy az élezés.hu példája is mutatja, egy sablon, oldalépítő vagy korábbi konfiguráció olyan fontot is kérhet a böngészőtől, amely végül egyetlen látható szövegen sem jelenik meg.
Ezt általában hálózati vizsgálattal vagy teljesítményméréssel lehet észrevenni.
8. A CSS és JavaScript is késleltetheti az oldal megjelenését
Egy WordPress oldal több forrásból is kaphat stílusokat és JavaScriptet.
Például:
- WordPress;
- sablon;
- Elementor;
- Elementor-kiegészítők;
- űrlapbővítmények;
- sütikezelő;
- analitika;
- chat;
- marketingrendszerek;
- külső widgetek.
Egy részük szükséges.
A kérdés inkább az, hogy:
mikor és melyik oldalon szükségesek?
Előfordulhat például, hogy egy bővítmény minden oldalon betölti a JavaScriptjét, miközben a hozzá tartozó funkció csak egyetlen aloldalon szerepel.
Mit jelent a renderelést blokkoló erőforrás?
Bizonyos fájlokat a böngészőnek fel kell dolgoznia, mielőtt megfelelően meg tudja jeleníteni az oldalt.
Ha sok ilyen erőforrás érkezik egyszerre, az első látható tartalom később jelenhet meg.
Lehetséges optimalizálási módszer például:
- JavaScript késleltetése;
- bizonyos scriptek későbbi indítása;
- kritikus CSS kezelése;
- fölösleges CSS csökkentése;
- fájlok feltételes betöltése.
Ezek azonban már olyan beavatkozások, amelyeknél minden változtatás után érdemes működési tesztet végezni.
A túl agresszív optimalizálás okozhat például:
- hibás menüt;
- működésképtelen űrlapot;
- eltűnő elemeket;
- hibás galériát;
- JavaScript-hibát.
A gyorsabb oldal kevés értéket jelent, ha közben valamelyik fontos funkció működése sérül.
9. Az Elementor használata önmagában kevés magyarázat a lassúságra
Elementorral is készülhet gyors, jól kezelhető WordPress weboldal.
A teljesítményt sokkal inkább az befolyásolja, hogyan épül fel az oldal.
Például:
- hány konténerszint található egymásban;
- mennyi widget működik;
- hány kiegészítő Elementor-csomag van telepítve;
- mennyi animáció fut;
- milyen méretű háttérképek szerepelnek;
- hány külső font és script töltődik be.
Egy látványosan egyszerű oldal mögött is lehet szükségtelenül bonyolult DOM-struktúra.
Ezért a teljesítményoptimalizálás egy része már az oldal felépítésekor elkezdődik.
A könnyebben áttekinthető szerkezet ráadásul a látogató számára is előnyös. A vizuális és tartalmi túlterhelés problémáját a túl bonyolult weboldalakról szóló cikk más oldalról vizsgálja.
10. A külső szolgáltatások is hozzáadódnak a betöltési időhöz
Egy weboldal ritkán működik teljesen önálló rendszerként.
Külső szolgáltatástól érkezhet például:
- Google Fonts;
- Google Analytics;
- Google Tag Manager;
- Meta Pixel;
- YouTube;
- Google Maps;
- chat;
- értékelési widget;
- foglalási rendszer;
- közösségi média elem.
Minden külső kapcsolat további hálózati kommunikációt jelenthet.
Ezek közül sok valóban szükséges.
A cél ezért elsősorban annak ellenőrzése, hogy minden betöltődő külső szolgáltatásnak van-e jelenlegi feladata.
Egy régen telepített, alig használt widget eltávolítása időnként látványosabb eredményt hozhat, mint sok apró CSS-optimalizálás.
11. A cache sokat segíthet, de önmagában ritkán old meg mindent
A gyorsítótárazás célja, hogy a rendszer bizonyos tartalmakat gyorsabban tudjon újra kiszolgálni.
WordPress környezetben többféle cache létezhet:
- oldal-cache;
- böngésző-cache;
- objektum-cache;
- szerveroldali cache;
- CDN.
Egy jól beállított gyorsítótárazási rendszer jelentősen csökkentheti a szerver munkáját.
Ettől azonban egy 2 MB-os hero kép továbbra is 2 MB marad.
Ugyanígy a cache kevéssé old meg:
- fölösleges külső scripteket;
- problémás JavaScriptet;
- rosszul méretezett képeket;
- hibás bővítményt;
- fölösleges fontokat.
A cache ezért csak egy réteg az optimalizálásban és kevésbé univerzális megoldás.
Több, azonos feladatot ellátó gyorsító bővítmény párhuzamos használatát szintén érdemes kerülni, mert könnyen átláthatatlanná válhat, melyik rendszer mit módosít.
12. Az adatbázis is okozhat lassulást
A WordPress az adatbázisban tárolja a tartalom és a rendszer számos elemét.
Idővel felhalmozódhatnak például:
- korábbi bejegyzés-verziók;
- lejárt transientek;
- naplóadatok;
- bővítmények által létrehozott táblák;
- már eltávolított funkciók maradványai.
Egy egyszerű, néhány oldalas bemutatkozó weboldalnál ez ritkán az első hely, ahol optimalizálást kezdenék.
Nagyobb vagy régebb óta működő rendszernél azonban már releváns lehet.
Különösen akkor, ha:
- a WordPress adminfelülete is lassú;
- sok tartalom található az oldalon;
- WooCommerce működik;
- sok dinamikus adat keletkezik.
Adatbázis-módosítás előtt különösen fontos használható biztonsági mentést készíteni.
A mentések és frissítések rendszeréről a WordPress hosszú távú karbantartásáról szóló cikkben írtam részletesebben.
13. Egy weboldal az idő múlásával is belassulhat
Egy induláskor gyors oldal teljesítménye később megváltozhat.
Az évek során kerülhet rá:
- új bővítmény;
- több kép;
- új analitikai kód;
- chat;
- videó;
- foglalási rendszer;
- közösségi widget;
- új Elementor-kiegészítő.
A technikai környezet is változik:
- WordPress;
- PHP;
- bővítmények;
- Elementor;
- sablon;
- tárhely.
Ezért az időszakos teljesítménymérés hasznos része lehet a WordPress-karbantartásnak.
Ha a lassulás hirtelen jelentkezik, különösen hasznos kérdés:
Mi változott közvetlenül előtte?
Egy új plugin, frissítés, külső script vagy nagyobb tartalmi módosítás gyorsan leszűkítheti a lehetséges okokat.
Milyen sorrendben érdemes megvizsgálni egy lassú WordPress oldalt?
A találgatás helyett használható egy egyszerű ellenőrzési sorrend.
1. Mérd meg a jelenlegi állapotot
Rögzítsd a kiinduló értékeket, később ezekhez tudod hasonlítani az eredményt.
2. Nézd meg a szerver válaszát
Ha már az első válasz lassú, érdemes itt kezdeni a vizsgálatot.
3. Ellenőrizd a nagy fájlokat
Különösen:
- hero kép;
- háttérképek;
- videók;
- fontok.
4. Nézd meg a betöltődő erőforrásokat
Van-e közöttük olyan CSS, JavaScript vagy font, amelyre az adott oldalon nincs szükség?
5. Vizsgáld meg a külső szolgáltatásokat
Analitika, chat, videó, térkép és marketingrendszerek egyaránt hozzáadhatnak a betöltési folyamathoz.
6. Nézd át a bővítményeket
Különösen a régi vagy kevéssé használt elemeket.
7. Ellenőrizd a cache működését
Valóban működik-e a gyorsítótárazás?
8. Vizsgáld meg az adatbázist és a WordPress-környezetet
Főként régebbi vagy összetettebb oldal esetén.
9. Módosíts egyszerre kevés dolgot
Így később megállapítható, melyik változtatás milyen hatással járt.
10. Mérj újra
A teljesítményoptimalizálásban ez az egyik legfontosabb lépés.
Ha nincs újramérés, könnyen úgy gondolhatjuk, hogy valamit javítottunk, miközben a változás alig mérhető.
Mikor érdemes optimalizálás helyett újraépítésben gondolkodni?
Egy lassú WordPress weboldal miatt önmagában ritkán szükséges azonnal új rendszert építeni.
Sok esetben célzott javítás elegendő.
Más a helyzet akkor, ha egyszerre több strukturális probléma is jelen van.
Például:
- elavult sablon;
- több korábbi oldalépítő maradványa;
- sok egymásra épülő bővítmény;
- folyamatos kompatibilitási hibák;
- nehezen frissíthető rendszer;
- túlzottan összetett oldalstruktúra;
- minden módosítás újabb problémát hoz létre.
Ilyenkor már érdemes összevetni a folyamatos javítás költségét egy rendezettebb rendszer kialakításával.
A döntési szempontokat részletesebben az elavult WordPress weboldal javításáról vagy újraépítéséről szóló cikkben veszem végig.
A gyorsabb weboldal jobb Google-helyezést jelent?
A weboldal teljesítménye része a technikai minőségnek, a Google-helyezést azonban sok tényező együttesen alakítja.
Ezért egy PageSpeed-pontszám javítása önmagában kevés alap arra, hogy automatikus helyezésjavulást várjunk.
A kereső számára ugyanúgy fontos többek között:
- a keresési szándékhoz illeszkedő tartalom;
- az oldal témája;
- a címsorstruktúra;
- a belső linkek;
- az indexelhetőség;
- a mobilos használhatóság;
- a technikai állapot.
A sebesség ennek egyik része.
Ha a cél kifejezetten a keresőből érkező forgalom növelése, a weboldal organikus látogatottságának növeléséről szóló útmutató ad tágabb képet.
Gyors WordPress weboldal: előbb diagnózis, utána optimalizálás
Egy lassú WordPress weboldalnál sokféle megoldás szóba jöhet:
- jobb képoptimalizálás;
- cache;
- tárhelykörnyezeti változtatás;
- bővítmények cseréje;
- fölösleges scriptek eltávolítása;
- betűtípusok rendezése;
- egyszerűbb Elementor-struktúra;
- adatbázis-optimalizálás.
A kérdés mindig az, hogy az adott oldalon melyikre van szükség.
Az élezés.hu példája számomra pontosan ezt mutatta meg.
Az egyik teljesítményprobléma egy olyan betűtípusból származott, amelyet a kész oldalon már nem is láttam. Egy másik mérési probléma hátterében a logó méretének hiányzó meghatározása állt.
Egyik hibát sem lehetett volna megbízhatóan megtalálni abból, hogy egyszerűen ránézek az oldalra.
A mérés viszont megmutatta, hol érdemes keresni.
Ezért a WordPress gyorsításánál a legjobb kiindulópont általában:
mérni, megérteni, majd célzottan javítani.
Gyakori kérdések
Miért lett hirtelen lassú a WordPress weboldalam?
Érdemes először megnézni, milyen változás történt közvetlenül a lassulás előtt. Frissítés, új bővítmény, kép, külső script, tárhelyváltozás vagy új funkció egyaránt jó kiindulópont lehet.
A sok WordPress-bővítmény lassítja az oldalt?
A bővítmények darabszáma önmagában keveset mond. A kód minősége, az elvégzett műveletek, az adatbázis-használat és a betöltött CSS- vagy JavaScript-fájlok fontosabbak.
Segít egy cache plugin a lassú WordPress weboldalon?
Sok esetben igen, főként a szerveroldali feldolgozás csökkentésében. A túl nagy képek, fölösleges fontok, külső scriptek vagy problémás bővítmények okát azonban külön kell kezelni.
Lassíthatják a betűtípusok a WordPress oldalt?
Igen. Különösen akkor, ha több betűcsalád vagy sok különböző vastagság töltődik be. Olyan fontfájl is jelen lehet a betöltési folyamatban, amely végül láthatóan sehol sem szerepel az oldalon.
Miért fontos a képek szélességének és magasságának megadása?
A böngésző így már a kép letöltése előtt tud helyet fenntartani számára. Ez csökkentheti az oldal elemeinek váratlan elmozdulását betöltés közben.
Mikor érdemes tárhelyet váltani?
Akkor érdemes komolyan megvizsgálni, amikor a mérés azt mutatja, hogy a szerver válaszideje tartósan problémás és a lassulás forrása ténylegesen a tárhelykörnyezethez kapcsolódik.
Milyen gyakran érdemes sebességet mérni?
Nagyobb technikai vagy tartalmi változtatás után mindenképpen. Emellett a teljesítménymérés a rendszeres WordPress-karbantartás része is lehet.
