- A darabszám félrevezető mérőszám: ugyanaz az egy bővítmény lehet ingyen vagy nagyságrenddel drágább, attól függően, hol fut.
- A Query Monitor bővítményenkénti lekérdezés-számot és PHP-időt mutat, így a lassítás nem érzés, hanem szám lesz.
- A minden oldalon betöltő script- és stílusfájlokat oldaltípusonként érdemes kiszedni, nem globálisan törölni.
- Elhagyott bővítménynél a kockázat elsősorban biztonsági, a sebesség csak másodlagos indok a cserére.
- Törlés előtt teszteld a shortcode-maradványokat és az adatbázis-maradékot, mert a nyers szöveg és a felduzzadt beállítás-tábla is költség.
Ha egy WordPress-oldal lassú, a leggyakoribb első reakció az, hogy sok a bővítmény, tehát törölni kell belőle. Ez vakon vág, mert a darabszám önmagában nem mérőszám. Egy jól megírt bővítmény, ami egyetlen oldaltípuson tölt be pár kilobájtot, gyakorlatilag ingyen van. Egy másik viszont minden kérésnél több tucat adatbázis-lekérdezést indít, és három JavaScript-fájlt rak olyan aloldalakra is, ahol a funkciója meg sem jelenik. Ugyanaz az egy darab, nagyságrendnyi különbség.
Az alábbi módszer arról szól, hogyan tedd mérhetővé ezt a különbséget a saját oldaladon, bővítményenként, számokkal, és mit kezdj az eredménnyel. A végén találsz egy leltár-sablont is, amit egy táblázatkezelőben vezethetsz tovább.
Miért nem a bővítmények száma számít?
Röviden: nem az a kérdés, hány bővítmény van telepítve, hanem hogy közülük hány fut olyan oldalon, ahol nincs is rá szükség.
Egy tipikus kisvállalkozói oldalon a kapcsolatűrlap-kezelő a saját szkriptjét és stíluslapját minden bejegyzésen, minden szolgáltatás-aloldalon és a főoldalon is betölti, pedig űrlap csak egy helyen van. A csúszka-bővítmény akkor is fut, ha csúszka egyedül a nyitóoldalon szerepel. A vélemény-megjelenítő minden kérésnél lekérdezi az adatbázist, akkor is, ha az adott sablonban nincs hova kiírnia. Ezek egyenként észrevehetetlenek, együtt viszont már másodperces nagyságrendű különbséget adnak a szerver válaszidejében.
Saját tapasztalat: a húsz bővítményes oldalak jelentős részénél a mérhető lassulás öt-hat bővítményből jön, a többi tizenöt gyakorlatilag nem látszik a számokban. Ezért a leltár célja nem a sorozatos törlés, hanem az, hogy tudd, melyik ötöt érdemes megfogni.
Hogyan méred meg bővítményenként a lassítást?
Röviden: telepíts egy fejlesztői mérőeszközt, aminek van bővítményenkénti bontása, és mindig ugyanazon az oldaltípuson mérj, bejelentkezés nélküli és bejelentkezett állapotban is.
A legelterjedtebb ingyenes eszköz a Query Monitor. Hivatalos információ: a bővítmény a WordPress hivatalos könyvtárában érhető el, és az adminsáv alatt jeleníti meg a futási adatokat: az összes adatbázis-lekérdezést, ezek időtartamát, a betöltött script- és stílusfájlokat, a lefutott hookokat, valamint a PHP-hibákat. A lekérdezéseket komponens szerint is csoportosítja, tehát külön sorban látod, hogy melyik bővítmény hány lekérdezést és mennyi időt hozott. Alternatíva a szerveroldali profilozó, például az XHProf vagy egy hosting-szolgáltatói APM-felület, de a legtöbb esetben a Query Monitor bontása elég a döntéshez.
A mérés menete:
- Telepítsd a mérőeszközt, lehetőleg egy tükrözött, éles adatbázissal működő próbakörnyezetben, ne közvetlenül a látogatók előtt.
- Válassz ki négy-öt jellemző oldaltípust: főoldal, egy szolgáltatás- vagy termékoldal, egy blogbejegyzés, egy listaoldal (kategória vagy blogarchívum), és ha van webshop, a kosár.
- Töltsd be mindegyiket, és jegyezd fel a Queries panelről az összes lekérdezés számát, a lekérdezésekre fordított időt, valamint a generálás teljes idejét és a memóriahasználatot.
- Nyisd meg a Queries by Component nézetet, és írd ki a három-öt legnagyobb bővítményt lekérdezés-szám és idő szerint.
- Ismételd meg ugyanezt kijelentkezve is, mert a gyorsítótár és a jogosultság-ellenőrzés miatt a két érték eltér.
Fontos, hogy sorozatban mérj: ugyanazt az oldalt legalább háromszor töltsd be, és a középső értéket használd. Az első betöltés szinte mindig lassabb az üres gyorsítótár miatt, és ha erre alapozol, rossz bővítményt fogsz meggyanúsítani.
Mit olvass ki a lekérdezés-számból és a PHP-időből?
Röviden: a lekérdezés-szám azt mutatja, mennyit dolgozik az adatbázis, a PHP-idő azt, mennyit a szerver, és a kettő nem mindig ugyanarra a bővítményre mutat.
Tapasztalati viszonyítási pontok, nem szabványok: egy egyszerű bemutatkozó oldal aloldalán ötven alatti lekérdezés-szám kényelmes, száz körül már érdemes megnézni, mi hozza, kétszáz fölött szinte biztosan van olyan bővítmény, ami minden kérésnél újraszámol valamit. Webshopnál a kosár és a pénztár természetes módon többet kérdez, ott a listaoldalhoz érdemes viszonyítani, nem abszolút számhoz.
Amit a bontásban keress:
- Sok lekérdezés, kevés idő: jellemzően beállítás-olvasás. Nem vészes, de jelzi, hogy a bővítmény nem gyorsítótáraz.
- Kevés lekérdezés, sok idő: van egy nehéz, rosszul indexelt lekérdezés. Ez a legjobb célpont, mert egyetlen ponton javítható.
- Külső HTTP-kérés a futás közben: a Query Monitor HTTP API Calls panelje mutatja. Ha egy bővítmény minden oldalbetöltésnél külső szolgáltatáshoz fordul, a te oldalad sebessége az ő szerverük válaszidejétől függ. Ez a leggyakoribb rejtett lassítás.
- Admin-ajax hívások: ha a böngésző hálózati fülén sűrűn látsz admin-ajax kéréseket, az háttérterhelést jelent akkor is, ha az oldal látszólag betöltött.
Szakmai feltételezés: a legtöbb oldalnál a felhasználó által érzékelt lassúságért nagyobb részben a felesleges front-end fájlok felelnek, mint a szerveroldali PHP-idő, egyszerűen azért, mert a renderelést a blokkoló CSS és JavaScript állítja meg. Ez oldalanként eltér, ezért mérd mindkettőt.
Hogyan találod meg a minden oldalon betöltő script- és stílusfájlokat?
Röviden: a mérőeszköz Scripts és Styles panelje kilistázza a betöltött fájlokat a forrásukkal együtt, és ebből azonnal látszik, melyik bővítmény tölt be olyan oldalon, ahol nincs dolga.
Nyisd meg egy blogbejegyzésen a Scripts panelt, és nézd végig a listát. Minden sornál tedd fel a kérdést: ennek az oldalnak a tartalmához kell ez a fájl? Ha a bejegyzésben nincs űrlap, csúszka, térkép, galéria vagy lightbox, de a hozzájuk tartozó szkript mégis szerepel, megtaláltad a felesleges betöltést. Ugyanezt csináld végig a stíluslapokkal, mert a CSS blokkolja a megjelenítést, tehát a felesleges stíluslap gyakran drágább, mint a felesleges szkript.
A fájlok azonosítóját (a handle nevét) írd fel, mert erre lesz szükséged a kikapcsoláshoz. Ha nem látod a handle-t, a WordPress globális objektumaiból is kinyerhető: global $wp_scripts; print_r( $wp_scripts->queue ); egy ideiglenes teszt-kódrészletben megmutatja a sorban álló azonosítókat.
Hogyan kapcsold ki a felesleges betöltéseket oldaltípusonként?
Röviden: ne globálisan tiltsd le a fájlt, hanem feltételesen, oldaltípus szerint, és mindig hagyd meg ott, ahol a funkció tényleg megjelenik.
A WordPress erre a wp_dequeue_script() és wp_dequeue_style() függvényeket kínálja, elég késői prioritással beakasztva, hogy a bővítmény már beregisztrálta a fájlját. Egy gyermeksablon functions.php fájljába vagy egy saját kis bővítménybe kerüljön, ne közvetlenül a sablonba, különben a következő frissítés elviszi.
add_action( 'wp_enqueue_scripts', function() { if ( is_singular( 'post' ) ) { wp_dequeue_style( 'pelda-urlap-stilus' ); wp_dequeue_script( 'pelda-urlap-script' ); } }, 100 );
Néhány szabály, amit érdemes tartani:
- Egyszerre egy fájlt vegyél ki, és utána nézd meg az oldalt. Ha ötöt szedsz ki egyszerre, nem fogod tudni, melyik törte el a megjelenést.
- A feltétel legyen szűk és pozitív. A
is_singular(),is_front_page(),is_page()ésis_woocommerce()hívások megbízhatóbbak, mint az URL-re illesztés. - A JavaScript-függőségeket vedd figyelembe. Ha egy szkript másikra épül, és az alapot kiveszed, a konzolban hibát fogsz kapni.
- Ellenőrizd a böngésző konzolját és a hálózati fület minden lépés után, ne csak szemre nézd meg az oldalt.
Létezik erre felület alapú megoldás is (a betöltés-kezelő bővítmények oldaltípusonként engedik ki-be kapcsolni a fájlokat). Ez kényelmes, de figyelj rá, hogy egy újabb réteget teszel a rendszerbe, aminek szintén van futási költsége, és amitől függővé válsz.
Mit tegyél a nem frissülő, elhagyott bővítményekkel?
Röviden: az elhagyott bővítmény elsősorban biztonsági kockázat, a sebesség csak másodlagos indok a cserére, de a kettő általában együtt jár.
Hivatalos információ: a WordPress bővítmény-könyvtár minden bővítmény adatlapján kiírja az utolsó frissítés dátumát, és figyelmeztetést jelenít meg, ha a bővítményt régóta nem tesztelték a WordPress aktuális főverziójával. Ha a bővítményt eltávolították a könyvtárból, az adatlap helyén a listázás felfüggesztéséről szóló üzenet jelenik meg.
A gyakorlati küszöb, amit használni szoktunk: két évnél régebbi utolsó frissítés esetén kiváltandó, egy év fölött megfigyelendő. Kiváltó megoldás keresésekor ebben a sorrendben nézz körül:
- Beépített WordPress-funkció. Sok régi bővítmény olyat old meg, amit a mag azóta tud (blokkok, beágyazások, képméretek, lapozás, sablonrészek).
- A sablonod saját funkciója. A nagyobb sablonkeretek gyakran hoznak galériát, csúszkát, ikonkészletet, tehát a külön bővítmény duplikáció.
- Egy már meglévő, aktívan fejlesztett bővítmény, amit úgyis használsz, és tud egy modulnyival többet. Egy karbantartott, több funkciós eszköz gyakran olcsóbb, mint három elhagyott kicsi.
- Néhány soros saját kód a gyermeksablonban. Ha a bővítmény összes dolga annyi, hogy hozzáad egy meta-tagot vagy átír egy címkét, arra nem kell bővítmény.
Ha nincs kiváltás, és a funkció üzletileg fontos, a kockázatot dokumentáld: mit csinál, mi történik, ha kiesik, és mennyi idő pótolni. Ez a döntés része, nem a leltáré.
Mit tesztelj a törlés előtt?
Röviden: mentést, deaktiválás melletti átnézést, shortcode-keresést és adatbázis-maradványokat, ebben a sorrendben.
- Teljes mentés, fájl és adatbázis együtt, visszaállítási próbával. Ha nem próbáltad vissza, nincs mentésed.
- Deaktiválás, nem törlés. Kapcsold ki a bővítményt, és nézd végig a jellemző oldaltípusokat, plusz azokat, ahol a funkciója szerepelt.
- Shortcode-keresés. A törölt bővítmény shortcode-jai nyers szövegként jelennek meg a tartalomban, például szögletes zárójelek között az azonosító. Keress rá a bejegyzések és oldalak tartalmában, a widgetekben, a menüleírásokban és az egyedi mezőkben is. Blokk-alapú tartalomnál a nem regisztrált blokk helyén hibaüzenet vagy üres terület marad.
- Adatbázis-maradványok. A legtöbb bővítmény törléskor sem takarít maga után: marad a beállítás-sorai a beállítás-táblában, gyakran automatikus betöltésre jelölve, maradnak egyedi mezők a poszt-metában, néha egész saját táblák. Ez elsősorban nem sebesség-kérdés, hanem takarítás, de a felduzzadt, automatikusan betöltődő beállítás-halmaz minden kérésnél memóriába kerül.
- Belső linkek és űrlap-célok. Ha a bővítmény oldalakat vagy végpontokat hozott létre, ezek a törlés után hibás oldalt adnak. Nézd meg a menüket, a lábléc-linkeket és a hirdetések céloldalait is.
- Újramérés. Deaktivált állapotban futtasd le ugyanazt a mérést, és írd be a különbséget a leltárba. Ez lesz a mérhető sebesség-hatás oszlop tartalma.
A tesztelés helye lehetőleg egy próbakörnyezet legyen. Éles oldalon a deaktiválás pillanatában is vannak látogatók, és egy törött kosár vagy űrlap azonnal pénzbe kerül.
Hogyan néz ki egy használható bővítmény-leltár?
Röviden: öt oszlop elég, és az utolsó oszlopba mért szám kerüljön, ne benyomás.
A sablon oszlopai:
- Bővítmény: a pontos név és a verzió.
- Funkció: egy mondatban, üzleti nyelven, hogy mit ad a látogatónak vagy neked.
- Kiváltható-e: igen (mivel) / részben / nem, plusz a kiváltás becsült munkája.
- Utolsó frissítés: dátum, és jelöld, ha a könyvtárból eltávolították.
- Mérhető sebesség-hatás: lekérdezés-szám és PHP-idő különbsége aktív és deaktivált állapot között, plusz a betöltött front-end fájlok száma és mérete, oldaltípus megjelölésével.
Egy kitöltött sor így néz ki szövegesen: Kapcsolatűrlap-kezelő 5.9 | űrlap a Kapcsolat oldalon | részben (blokk-alapú űrlap) | 2026-06 | blogbejegyzésen 2 fájl, 48 KB, 0 lekérdezés. Ebből azonnal látszik a döntés: a bővítmény maradhat, de a fájljait ki kell venni a bejegyzésekről.
Érdemes egy hatodik, szabad szöveges oszlopot is nyitni a döntésnek: marad, feltételesre állítva, kiváltandó, törölhető. A leltárt negyedévente frissítsd, mert az utolsó frissítés dátuma és a mért hatás is változik.
Számít-e mindez az AI-válaszmotoroknál?
Röviden: közvetve igen, mert a gyorsan és megbízhatóan kiszolgált, tiszta HTML könnyebben feldolgozható, de a sebesség önmagában nem hoz idézettséget.
Hivatalos információ: a Google Search Central az oldalélményt és a Core Web Vitals mutatókat a keresési élmény részeként tárgyalja, de nem egyetlen döntő tényezőként. Szakmai feltételezés: az AI-válaszmotorok lekérő rendszerei jellemzően időkorláttal dolgoznak, tehát a lassú vagy hibázó válasz kihagyott tartalmat jelenthet, a felesleges szkriptek pedig zajt visznek a kinyert szövegbe. Ez nem garantál semmit, de a takarítás mellett szóló érv. A lényeg ugyanaz marad: ami nem kell az adott oldalon, az ne fusson rajta.
Források és további olvasnivalók
- WordPress Developer Resources, Plugin Handbook és a szkript-kezelő függvények dokumentációja
- WordPress Plugin Directory (bővítmény-adatlapok, utolsó frissítés és kompatibilitási jelzés)
- Query Monitor hivatalos dokumentációja
- Google Search Central, Page Experience és Core Web Vitals útmutatók
- web.dev, Core Web Vitals mérési és optimalizálási anyagok
- W3C, HTML és teljesítmény-vonatkozású ajánlások
Gyakori kérdések
Hány bővítmény a sok egy WordPress-oldalon?
Nincs értelmes felső szám. Egy húsz bővítményes oldal lehet gyorsabb, mint egy nyolc bővítményes, ha a húszból csak három fut az adott oldaltípuson. A mérőszám nem a darabszám, hanem a kérésenkénti lekérdezés-szám, a PHP-idő és a betöltött front-end fájlok mennyisége.
Élesben is telepíthetem a Query Monitort?
Technikailag igen, és a mérési adatokat alapból csak bejelentkezett adminisztrátor látja. Mégis biztonságosabb próbakörnyezetben mérni, mert a mérőeszköz maga is fogyaszt erőforrást, és éles oldalon minden extra bővítmény extra felület. Ha élesen mérsz, a mérés után kapcsold ki.
Mi történik, ha törlöm a bővítményt, de a shortcode-ja bent maradt a tartalomban?
A shortcode nem fut le, hanem nyers szövegként, szögletes zárójelekkel jelenik meg a látogató előtt. Ezért kell törlés előtt rákeresni a bejegyzések, oldalak, widgetek és egyedi mezők tartalmában, és a talált helyeket kicserélni vagy eltávolítani.
Elég, ha csak deaktiválom a nem használt bővítményeket?
A deaktivált bővítmény nem fut, tehát sebességben már nem kerül semmibe. Biztonsági szempontból viszont a fájljai a szerveren maradnak, ezért ami tartósan nem kell, azt a tesztelés után érdemes törölni is.
Honnan tudom, hogy egy bővítmény elhagyott?
A bővítmény hivatalos adatlapján szerepel az utolsó frissítés dátuma és az, hogy melyik WordPress-verzióval tesztelték. Ha két évnél régebbi a frissítés, vagy az adatlap helyén a listázás felfüggesztéséről szóló üzenet áll, kiváltandó kategóriába kerül.
Megéri gyorsítótárazó bővítménnyel elfedni a problémát?
A gyorsítótár sokat javít a szerveroldali időn, de a felesleges front-end fájlokat is szorgalmasan kiszolgálja, és a bejelentkezett vagy dinamikus oldalakon (kosár, pénztár, fiók) jellemzően nem működik. A takarítás és a gyorsítótárazás egymást kiegészíti, nem helyettesíti.
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.