Egy átlagos WordPress-oldalon a bővítmények többsége nem kérdezi meg, hol van rájuk szükség. Az űrlapbővítmény a stíluslapját és a scriptjét a főoldalra, a blogcikkekre és az adatvédelmi tájékoztatóra is betölti, holott űrlap csak a Kapcsolat oldalon van. Ugyanez a helyzet a csúszkákkal, a galériákkal, a webshop kosárscriptjeivel és a közösségi megosztógombokkal. Ebben a cikkben végigmegyünk azon, hogyan derítsd ki, melyik fájl hol felesleges, hogyan kapcsold ki oldalanként, és mit kell utána ellenőrizned, hogy semmi ne törjön el.
A cikkben háromféle jelölést használunk. Hivatalosan igazolt az, ami a WordPress, a Google vagy az adott eszköz dokumentációjában szerepel. Saját tapasztalat az, amit WordPress-oldalak karbantartása közben rendszeresen látunk. Szakmai feltételezés az, ami logikusan következik, de általános érvénnyel nincs bizonyítva.
Miért tölt be egy bővítmény minden oldalon olyan fájlt, amire csak egy helyen van szükség?
Azért, mert a WordPress a bővítményekre bízza, hol töltik be a CSS- és JavaScript-fájljaikat, és a fejlesztők gyakran a biztonságosabb utat választják, vagyis mindenhol betöltenek. Így a bővítmény akkor is működik, ha a felhasználó egy widgetbe, egy oldalépítő blokkjába vagy egy felugró ablakba teszi be az űrlapot.
Hivatalosan igazolt: a WordPress fejlesztői dokumentációja szerint a fájlokat a wp_enqueue_script() és a wp_enqueue_style() függvénnyel kell regisztrálni, és a dokumentáció azt javasolja, hogy a bővítmény csak ott töltse be őket, ahol tényleg kellenek. Ez ajánlás, nem kötelező szabály, ezért sok bővítmény nem tartja be.
Saját tapasztalat: a leggyakoribb mindenhol betöltődő fájlok ezekből a körökből jönnek.
- Űrlapbővítmények stíluslapja, validáló scriptje és a reCAPTCHA scriptje.
- Csúszka- és karusszelbővítmények, amelyeket csak a főoldalon használsz.
- Webshop-scriptek (kosár, kosárfrissítés, termékgaléria) a blogcikkeken és a szöveges oldalakon.
- Galéria, lightbox és videó-beágyazó bővítmények.
- Közösségi megosztógombok, értékelő csillagok, ikonkészletek.
Mennyit számít a felesleges CSS és JavaScript a betöltési sebességben?
Ritkán ez az egyetlen oka a lassúságnak, de a renderelést blokkoló CSS és a sok JavaScript késleltetheti az oldal első megjelenését, és lassíthatja a kattintásokra adott választ. Minél több bővítmény tölt be mindenhol, annál nagyobb a hatás.
Hivatalosan igazolt: a Lighthouse külön auditban jelzi a nem használt CSS-t és a nem használt JavaScriptet, valamint a renderelést blokkoló erőforrásokat. A Google Search Central szerint a Core Web Vitals mutatók (LCP, INP, CLS) az oldalélmény részei, de a Google azt is leírja, hogy a jó mutatók önmagukban nem garantálnak jobb helyezést, a tartalom relevanciája továbbra is elsődleges.
Szakmai feltételezés: az AI-keresők és válaszmotorok robotjai jellemzően a HTML-t olvassák, a CSS- és JS-fájlokat ritkábban futtatják. A felesleges fájlok kivétele ezért elsősorban a látogatóidnak segít, az AI-idézettségre legfeljebb közvetve hat, például azzal, hogy egy gyorsabb oldalon a látogató tovább marad.
Hogyan térképezd fel a Chrome DevTools Coverage paneljével, mi felesleges egy oldalon?
A Coverage panel betöltés közben rögzíti, hogy egy CSS- vagy JS-fájlból mennyi kód futott le ténylegesen. Fájlonként megmutatja a teljes méretet és a nem használt részt, így pár perc alatt látod, melyik bővítmény fájlja nem csinál semmit az adott oldalon.
- Nyisd meg az oldalt inkognitóablakban, kijelentkezve. Bejelentkezve az adminsáv és a szerkesztői eszközök saját fájlokat töltenek be, amelyek eltorzítják a képet.
- Nyisd meg a fejlesztői eszközöket (F12, macOS-en Cmd+Option+I).
- Nyomd meg a Ctrl+Shift+P (macOS-en Cmd+Shift+P) billentyűkombinációt, írd be, hogy
Coverage, és válaszd a Show Coverage lehetőséget. - A Coverage panelen kattints az újratöltés ikonra. Így a rögzítés már az oldal betöltésétől indul.
- Rendezd a listát a nem használt bájtok szerint, és a szűrőmezőbe írd be, hogy
wp-content/plugins. Ekkor csak a bővítmények fájljait látod, a mappanévből pedig kiderül, melyik bővítményhez tartoznak. - Rögzítés közben használd is az oldalt. Nyisd le a menüt, görgess végig, kattints egy fülre vagy harmonikára. A számok közben frissülnek.
Ezt ne csak egy oldalon végezd el, hanem sablononként. Elég egy példányt megnézni minden típusból, például a főoldalt, egy blogcikket, egy szöveges oldalt, a Kapcsolat oldalt, egy termékoldalt és egy kategóriaoldalt. Az eredményt írd fel egy egyszerű táblázatba, amelyben soronként szerepel a fájl, a bővítmény neve, és hogy melyik oldaltípuson van rá ténylegesen szükség.
Fontos korlát (hivatalosan igazolt): a Coverage csak azt jelzi, mi nem futott le ebben a munkamenetben. Egy űrlap validáló kódja csak beküldéskor fut, egy felugró ablak scriptje csak a megjelenésekor. Ezért a Kapcsolat oldalon 70 százalékban nem használt űrlapscript attól még kell. A jó jelölt az a fájl, amelyik olyan oldalon 95-100 százalékban kihasználatlan, ahol az adott funkció egyáltalán nem szerepel.
A kikapcsoláshoz a fájl WordPress-beli azonosítójára, a handle-re is szükséged lesz. A forráskódban a stíluslapok link tagjének id attribútuma a handle-t tartalmazza egy -css végződéssel, például contact-form-7-css. Az újabb WordPress-verziók a scripteknél is kiírják ezt egy -js végződéssel. Az Asset CleanUp és a Perfmatters ezt a listát készen mutatja, így eszközzel nem kell keresgélned.
Hogyan kapcsold ki oldalanként Asset CleanUp vagy Perfmatters jellegű eszközzel?
Mindkét eszköz kilistázza, milyen CSS- és JS-fájlok töltődnek be egy adott oldalon, bővítményenként csoportosítva, és fájlonként beállíthatod, hol ne töltődjön be. A menük neve verziónként változhat, ezért az alábbiak a működési logikát írják le, nem a pontos gombfeliratokat.
Asset CleanUp
Hivatalosan igazolt: az Asset CleanUp a bejegyzés szerkesztőfelületén vagy a nyilvános oldal alján mutatja a CSS és JS kezelőt. Egy fájlt kikapcsolhatsz csak az adott oldalon, az egész oldalon, vagy egy bejegyzéstípus összes elemén, és megadhatsz kivételt is (kikapcsolva mindenhol, kivéve ezen az oldalon). Van tesztmódja, amelyben a változtatásokat csak a bejelentkezett adminisztrátor látja, a látogatók a régi állapotot kapják.
Perfmatters
Hivatalosan igazolt: a Perfmatters Script Managerét a beállításokban kell bekapcsolni, utána a nyilvános oldalon az adminsávból nyitható meg. Fájlonként vagy bővítményenként kapcsolhatsz ki mindent az adott URL-en vagy az egész oldalon, kivételekkel bejegyzéstípusra vagy konkrét URL-re. Ennek is van tesztmódja. Az úgynevezett MU módban teljes bővítményeket is letilthatsz egy-egy oldalon, ez erősebb beavatkozás, ezért csak alapos teszteléssel használd.
Melyik logikát válaszd?
Saját tapasztalat: az űrlap- és csúszkabővítményeknél a kikapcsolás mindenhol, kivétel ahol kell megoldás jobban bevált, mint oldalanként egyesével tiltani. Az új blogcikkeken így automatikusan nem töltődik be a felesleges fájl. Ennek az ára, hogy ha valaki később új oldalra tesz űrlapot, az ott nem fog működni, amíg a kivételt fel nem veszed. Ezt írd le a karbantartási jegyzetbe, és szólj róla annak, aki tartalmat szerkeszt.
Mikor érdemes eszköz helyett kódból kikapcsolni?
Akkor, ha csak néhány egyértelmű esetről van szó, és van gyerektémád vagy kódrészlet-kezelő bővítményed. Így eggyel kevesebb bővítmény fut, a szabály pedig a kódban dokumentálva van.
Hivatalosan igazolt: a Contact Form 7 dokumentációja leírja, hogy két szűrővel kikapcsolható a fájljai automatikus betöltése, és utána csak a szükséges sablonban kell visszahívni őket.
add_filter( 'wpcf7_load_js', '__return_false' );add_filter( 'wpcf7_load_css', '__return_false' );
Az űrlapot tartalmazó sablonban pedig ezt a hívást kell elhelyezni.
if ( function_exists( 'wpcf7_enqueue_scripts' ) ) { wpcf7_enqueue_scripts(); }
Más bővítményeknél az általános megoldás a wp_dequeue_style() és a wp_dequeue_script(). A példában a handle-nevek kitaláltak, a sajátodat a fent leírt módon keresd meg.
add_action( 'wp_enqueue_scripts', function () { if ( ! is_page( 'kapcsolat' ) ) { wp_dequeue_style( 'pelda-urlap' ); wp_dequeue_script( 'pelda-urlap' ); } }, 100 );
A 100-as prioritás azért kell, hogy a te kódod a bővítmény után fusson le. Ha korábban fut, nincs még mit kivenni, és a szabály hatástalan marad.
Mely oldaltípusokat kell végigkattintani kikapcsolás után?
Minden olyan oldaltípust, amelyen az érintett bővítmény funkciója akár csak egy widgetben, láblécben vagy felugró ablakban megjelenhet. A legtöbb hiba nem ott jön elő, ahol a funkciót elsőre keresnéd.
- Főoldal. Csúszka, kiemelt blokkok, animációk, beágyazott videó.
- Kapcsolat és ajánlatkérő oldal. Küldj be egy valódi tesztüzenetet, és nézd meg, hogy megérkezik-e a levél. A reCAPTCHA vagy más spamszűrő is legyen működőképes.
- Bármelyik oldal lábléce és oldalsávja. A hírlevél-feliratkozó űrlap gyakran minden oldalon ott van, ezért egy oldalanként kikapcsolt űrlapscript itt törik el először.
- Felugró ablakok. Időzített, görgetésre vagy kilépési szándékra induló popupok, mert ezek sokszor űrlapot tartalmaznak.
- Blogcikk, kategória- és archívumoldal, keresési találati oldal, 404-es oldal. Ezek gyakran más sablont használnak, mint a szöveges oldalak.
- Webshop. Termékoldal (változatválasztó, galéria), kategóriaoldal, kosár, pénztár, Fiókom oldal. A pénztárban végezz teljes tesztrendelést, és ellenőrizd, hogy a fejlécben a kosár ikonja frissül-e.
- Mobilnézet. A mobilmenü, a lenyíló elemek és a ragadós fejléc külön scripttel működhetnek.
- Sütisáv és mérés. A hozzájárulási sáv megjelenik-e, és a hozzájárulás után elindulnak-e a mérőkódok. A Google Tag Assistant vagy a GA4 DebugView segít ellenőrizni, hogy a konverziós események továbbra is beérkeznek-e.
- Bejelentkezett és kijelentkezett állapot. Ha vannak tagok vagy vásárlói fiókok, mindkét állapotban nézd meg.
Minden oldalon nyisd meg a fejlesztői eszközök Console fülét is. Egy Uncaught ReferenceError típusú hiba, például jQuery is not defined, azt jelzi, hogy kivettél egy fájlt, amelyre egy másik még épít.
Saját tapasztalat: a leggyakoribb utólagos panasz az, hogy nem érkeznek meg a láblécből küldött feliratkozások, vagy elakad a pénztár. Ezek napokig rejtve maradhatnak, mert az oldal ránézésre hibátlannak látszik.
Hogyan lehet gyorsan visszaállni, ha valami elromlott?
Úgy, hogy már a kikapcsolás előtt felkészülsz a visszavonásra. A tesztmód, a változásnapló és egy friss mentés együtt percekre rövidítheti a visszaállást.
- Tesztmód először. Minden szabályt tesztmódban állíts be, ellenőrizd az előző lista szerint, és csak utána élesítsd.
- Egyszerre egy változtatás. Ha egy körben tíz fájlt kapcsolsz ki, hiba esetén nem fogod tudni, melyik okozta.
- Változásnapló. Írd fel, mikor, melyik fájlt, melyik oldalon kapcsoltad ki. Ha hiba jön, ebből látod, mit kell visszavonni.
- Gyorsítótár ürítése. Minden változtatás és minden visszavonás után ürítsd a cache-bővítmény, a tárhely és a CDN gyorsítótárát, különben a régi vagy a hibás állapotot látod.
- Vészhelyzeti kikapcsolás. Ha az admin sem érhető el, FTP-n vagy a tárhely fájlkezelőjében nevezd át a bővítmény mappáját a
wp-content/pluginskönyvtárban. A WordPress dokumentációja szerint így a bővítmény kikapcsol (hivatalosan igazolt). - Beállítások mentése. Mindkét eszköz engedi a beállítások exportját. Szakmai feltételezés: a szabályok az adatbázisban maradnak, így a bővítmény visszakapcsolásakor újra életbe lépnek, ezért vészhelyzet után előbb javítsd a hibás szabályt, és csak utána aktiváld újra.
Mit érdemes elkerülni a kikapcsolás során?
A legnagyobb kockázatot a közös függőségek kivétele és a több optimalizálás egyidejű bekapcsolása jelenti. Ezeknél a hiba helye nehezen azonosítható.
- A jQuery kikapcsolása mindenhol. Sok téma és bővítmény erre épül, és a hiba gyakran csak egy ritkán használt funkciónál jön elő.
- Kikapcsolás és fájlösszevonás egyszerre. Ha a CSS- és JS-fájlok összevonását, késleltetését is most kapcsolod be, egy hiba okát szinte lehetetlen visszakövetni. Előbb a kikapcsolás menjen, utána a többi.
- Döntés kizárólag a PageSpeed-pontszám alapján. A pontszám laborban mért becslés. A valós látogatói adatokat a Search Console Core Web Vitals jelentése mutatja.
- Frissítések utáni ellenőrzés kihagyása. Saját tapasztalat: egy bővítményfrissítés után megváltozhat a fájlok neve vagy handle-je, ilyenkor a régi szabály hatástalan lesz, vagy új fájl jelenik meg mindenhol. Nagyobb frissítések után futtasd le újra a Coverage-mérést a fő sablonokon.
Ha a folyamatot sablononként végzed, és minden lépés után tesztelsz, a nem használt CSS és JavaScript kikapcsolása jó eséllyel érezhetően könnyebb oldalakat ad. Gyorsabb betöltést vagy jobb helyezést viszont semmilyen beállítás nem garantál, ezért a hatást mindig méréssel ellenőrizd.
Források és további olvasnivalók
- Chrome for Developers, Chrome DevTools dokumentáció (Coverage panel)
- Chrome for Developers, Lighthouse auditok (nem használt CSS és JavaScript, renderelést blokkoló erőforrások)
- Google Search Central, Core Web Vitals és oldalélmény dokumentáció
- web.dev, Core Web Vitals (LCP, INP, CLS)
- WordPress Developer Resources, wp_enqueue_script, wp_dequeue_script, wp_dequeue_style
- WordPress.org dokumentáció, bővítmények kézi kikapcsolása
- Contact Form 7 hivatalos dokumentáció, a JavaScript és a stíluslap betöltése csak ott, ahol szükséges
- Asset CleanUp és Perfmatters hivatalos dokumentációja
- Az űrlap-, csúszka- és webshop-bővítmények gyakran minden oldalon betöltik a CSS- és JS-fájljaikat, akkor is, ha csak egy oldalon használod őket.
- A Coverage panel csak azt mutatja meg, mi nem futott le az adott munkamenetben, ezért a piros sáv még nem jelenti, hogy a fájl biztonságosan kivehető.
- Kikapcsolás előtt használd az eszköz tesztmódját, és egyszerre csak egy szabályt változtass, mert így hiba esetén pontosan tudod, mit kell visszavonni.
- A legtöbb hiba a láblécben vagy felugró ablakban lévő űrlapokon, a pénztárban és a mobil menüben jön elő, ezért ezeket mindig külön teszteld.
- A sebességjavulás segítheti a felhasználói élményt és a Core Web Vitals mutatókat, de helyezést nem garantál.
Gyakori kérdések
Mit mutat a Chrome DevTools Coverage panelje?
Fájlonként megmutatja, hogy egy CSS- vagy JavaScript-fájlból mennyi kód futott le az aktuális munkamenetben, és mennyi maradt kihasználatlanul. A Ctrl+Shift+P (macOS-en Cmd+Shift+P) parancspalettából nyitható meg a Show Coverage paranccsal.
Ha a Coverage pirosnak jelöl egy fájlt, nyugodtan kikapcsolhatom?
Nem feltétlenül. A panel csak azt jelzi, mi nem futott le a mérés alatt, az űrlap beküldésekor vagy egy felugró ablak megjelenésekor futó kódot is nem használtnak mutathatja. Azt a fájlt érdemes kivenni, amelyik olyan oldalon szinte teljesen kihasználatlan, ahol az adott funkció egyáltalán nem szerepel.
Asset CleanUp vagy Perfmatters, melyiket válasszam?
Mindkettő képes fájlonként és oldalanként kikapcsolni a CSS-t és a JavaScriptet, és mindkettőnek van tesztmódja. A választás inkább azon múlik, milyen egyéb optimalizálási funkciókra van szükséged, és melyik felülete kényelmesebb neked. Egy oldalon csak az egyiket használd, hogy a szabályok ne ütközzenek.
Mit tegyek, ha a kikapcsolás után nem érem el az admin felületet?
FTP-n vagy a tárhely fájlkezelőjében nevezd át az optimalizáló bővítmény mappáját a wp-content/plugins könyvtárban, így a WordPress kikapcsolja. Utána ürítsd a gyorsítótárat, javítsd a hibás szabályt, és csak ezután kapcsold vissza a bővítményt.
Javítja a helyezésemet a felesleges fájlok kikapcsolása?
Közvetlenül nem garantál jobb helyezést. A gyorsabb betöltés segítheti a Core Web Vitals mutatókat és a felhasználói élményt, a Google szerint viszont az oldalélmény csak egy a sok jel közül, és a tartalom relevanciája továbbra is elsődleges.
Milyen gyakran kell újra ellenőrizni a beállításokat?
Minden nagyobb bővítmény- vagy témafrissítés után, és amikor új funkciót (űrlapot, csúszkát, popupot) teszel egy oldalra. Frissítés után megváltozhat a fájlok neve, így a régi szabály hatástalanná válhat.
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.