Egy WordPress-oldal indulásánál a legtöbb látható késleltetést általában nem a képek és nem is a scriptek okozzák, hanem a fejlécbe sorakoztatott stíluslapok. A PageSpeed Insights ezt „Renderelést blokkoló erőforrások” néven jelzi, és sok oldalnál pont ez az a tétel, ahol a legtöbb ezredmásodperc nyerhető vissza úgy, hogy a dizájnhoz egy ujjal sem nyúlsz hozzá. Cserébe ez az a beavatkozás is, amivel a legkönnyebb eltörni a mobil menüt vagy a sütibannert, ha utána nem teszteled végig rendesen az oldalt.
Mit jelent az, hogy egy stíluslap blokkolja a renderelést?
Rövid válasz: a böngésző addig nem rajzol ki semmit a képernyőre, amíg a <head>-ben hivatkozott összes stíluslapot le nem töltötte és fel nem dolgozta, mert bármelyik CSS-szabály megváltoztathatja bármelyik elem kinézetét.
A folyamat így néz ki. A böngésző megkapja a HTML-t, elkezdi belőle felépíteni a DOM-ot, és közben minden <link rel='stylesheet'> sornál letöltést indít. A stíluslapokból épül fel a CSSOM, és a rajzolás csak akkor indulhat el, amikor a DOM és a CSSOM összeállt egy render fává. Ha nem így működne, először formázatlan szöveget látnál, aztán egy villanással átrendeződne az egész oldal. A böngészőgyártók inkább a rövid várakozást választották, mint a látványos ugrálást.
Hivatalosan igazolt: a CSS alapértelmezés szerint renderelést blokkoló erőforrás, ezt a Chrome fejlesztői dokumentációja és a web.dev teljesítmény-anyagai egyértelműen kimondják. Ez nem WordPress-sajátosság, minden weboldalra igaz.
A gond ott kezdődik, hogy egy átlagos magyar kisvállalkozói WordPress-oldalon nem egy stíluslap van a fejlécben, hanem tizenöt és huszonöt között. Ott a téma alap-CSS-e, a gyereksablon, az oldalépítő (Elementor, Divi, WPBakery) több fájlja, a sütibanner, az űrlap-bővítmény, a galéria, a slider, a betűkészlet és az ikonkészlet. Mindegyik külön HTTP-kérés, és mobilhálózaton mindegyiknél számít a kapcsolatfelépítés és a kör-idő is, nem csak a fájlméret.
Miért látszik fehér képernyő az első másodpercekben?
Rövid válasz: a fehér képernyő az az időszak, amikor a HTML már megérkezett, de a böngésző még a stíluslapokra vár, ezért még egyetlen pixelt sem rajzolt ki.
Ennek az időpontnak a neve First Contentful Paint (FCP): az első pillanat, amikor bármilyen szöveg vagy kép megjelenik. Ha a fejlécben húsz stíluslap van, és közülük a leglassabb egy külső szerverről érkezik, akkor az FCP a leglassabb lánchoz igazodik, nem az átlaghoz. Mobilon, ahol egy új kapcsolat felépítése önmagában is több száz ezredmásodperc, ez gyorsan másfél-két másodpercre hízik.
Saját tapasztalat: a leggyakoribb tettes nem a téma fő stíluslapja, hanem három visszatérő szereplő. Az első a külső forrásból hívott betűkészlet, a második a teljes ikonkészlet, amiből az oldal három ikont használ, a harmadik pedig az oldalépítő olyan modul-CSS-e, ami minden aloldalon betöltődik akkor is, ha az adott modul csak a főoldalon szerepel.
Hogyan kapcsolódik mindez az LCP-hez?
Rövid válasz: az LCP soha nem lehet korábbi, mint az FCP, ezért minden ezredmásodperc, amit a blokkoló CSS elvesz az első rajzolástól, közvetlenül átcsúszik az LCP-be is.
Az LCP (Largest Contentful Paint) azt méri, mikor jelenik meg a látómezőben a legnagyobb tartalmi elem: jellemzően a fejlécben lévő nagy kép, a címsor vagy a hős-blokk szövege. Hivatalosan igazolt: a Google a Core Web Vitals mérőszámok között tartja számon, és a jónak tekintett küszöb 2,5 másodperc a látogatók 75 százalékánál, mezei (field) adaton mérve.
Van egy csendesebb csapda is. Ha a hős-kép nem img elemként szerepel, hanem CSS háttérképként, akkor a böngésző csak a stíluslap feldolgozása után tudja meg, hogy azt a képet egyáltalán le kell töltenie. Így a blokkoló CSS kétszer büntet: előbb késlelteti a rajzolást, majd késve indítja el az LCP-elem letöltését is. Ilyenkor a kritikus CSS kiemelése mellett az is sokat segíthet, ha az LCP-kép rendes img elem lesz, vagy <link rel='preload'> hivatkozást kap.
Hogyan olvasd a PageSpeed Insights „Renderelést blokkoló erőforrások” pontját?
Rövid válasz: a jelentésben szereplő becsült megtakarítás felső határ, nem ígéret, viszont a fájllista pontos, és abból derül ki, melyik bővítmény tölt CSS-t olyan oldalra, ahol nincs is rá szükség.
- Nyisd meg a jelentést az adott URL-re, és maradj a Mobil fülön. Az asztali érték szinte mindig szebb, és éppen ezért félrevezető.
- Görgess a Diagnosztika blokkig, és nyisd le a „Renderelést blokkoló erőforrások” sort.
- Nézd végig a fájlneveket. A
/wp-content/plugins/...útvonal megmondja, melyik bővítmény, a/wp-content/themes/...pedig azt, hogy a téma a felelős. - A méret oszlop mellett figyeld a becsült megtakarítást is. Egy 6 KB-os, de külső szerverről érkező fájl gyakran többet árt, mint egy 60 KB-os, helyben tárolt.
- Vesd össze a „Nem használt CSS csökkentése” tétellel. Ami mindkét listában szerepel, az az első számú célpont.
- Futtasd le ugyanezt legalább öt sablontípuson: főoldal, szolgáltatás- vagy termékoldal, blogbejegyzés, kapcsolat oldal, és ha van, egy kosár vagy pénztár oldal.
A pontosabb képhez a Chrome DevTools Coverage füle a legjobb eszköz. Betöltöd az oldalt, és soronként látod, hogy az adott CSS-fájlból hány százalék nem futott le. Nem hibátlan: a csak interakcióra megjelenő elemek szabályait használatlannak mutatja. Ez a torzítás viszont pont az, amit a következő szakaszban érdemes komolyan venni.
Mi a kritikus CSS, és hogyan emeld ki?
Rövid válasz: a kritikus CSS az a minimális szabályhalmaz, ami az első képernyő helyes megjelenítéséhez kell. Ezt közvetlenül a HTML-be ágyazod, a teljes stíluslapot pedig úgy hivatkozod, hogy ne blokkolja a rajzolást.
A megvalósítás két lépésből áll. Először a <head>-be kerül egy <style> blokk a kiemelt szabályokkal. Másodszor a teljes stíluslap hivatkozása átalakul úgy, hogy a böngésző alacsony prioritással, a rajzolás blokkolása nélkül töltse le, majd betöltés után kapcsolja élesre: <link rel='stylesheet' href='teljes.css' media='print' onload="this.media='all'">. Mellé kell egy <noscript> ág is a hagyományos hivatkozással, hogy JavaScript nélkül se maradjon formázatlan az oldal.
A trükk lényege, hogy a media='print' értékű stíluslapot a böngésző nem tekinti a képernyős megjelenítéshez szükségesnek, ezért nem vár rá. Amint megérkezett, az onload átállítja all értékre, és a szabályok életbe lépnek.
WordPressen ezt ritkán kell kézzel megírni. A gyorsítótárazó és optimalizáló bővítmények (WP Rocket, LiteSpeed Cache, FlyingPress, Autoptimize, Perfmatters) mind kínálnak kritikus CSS generálást és halasztást. A különbség abban van, hogy a generálás sablononként történik-e, vagy az egész oldalra egyetlen közös készlet készül. Saját tapasztalat: az egyetlen, közös kritikus CSS a legtöbb esetben rosszabb, mint a semmi, mert a főoldal hős-blokkjára optimalizált készlet a blogbejegyzésen és a kapcsolat oldalon látható ugrálást okoz.
Mekkora legyen a kritikus CSS?
Szakmai feltételezés: a 10 és 15 KB közötti tömörítetlen méret jó irány. A gyakran emlegetett 14 KB-os határ a TCP kezdeti torlódási ablakából ered, vagyis abból, hogy mennyi adat fér az első adatcserébe. Ez modern kapcsolatokon és HTTP/2, HTTP/3 mellett már nem ilyen éles szabály, de hüvelykujj-szabálynak használható. Ha a kritikus CSS 40 KB fölé nő, akkor jó eséllyel nem kritikus CSS-t készítettél, hanem lemásoltad a teljes stíluslapot.
Hogyan zárd ki a nem használt téma- és bővítmény-stíluslapokat oldaltípusonként?
Rövid válasz: WordPressben a stíluslapokat a wp_enqueue_style regisztrálja, és ugyanezeket a wp_dequeue_style feltételesen le is tudja venni, így egy stíluslap csak ott töltődik be, ahol tényleg kell.
A kézi módszer váza egy gyereksablon functions.php fájljában így néz ki: add_action('wp_enqueue_scripts', function () { if (!is_page('kapcsolat')) { wp_dequeue_style('urlap-bovitmeny-css'); } }, 100);. A záró 100 prioritás azért fontos, mert a bővítmények jellemzően az alapértelmezett 10-es prioritáson regisztrálnak, és csak utána lehet őket levenni.
A stíluslap azonosítóját (handle) többféleképpen derítheted ki. Megkeresheted a bővítmény kódjában a wp_enqueue_style hívást, vagy ideiglenesen kiíratod a sorban álló elemeket a $wp_styles->queue tömbből. Ha nem akarsz kódot írni, az eszközkezelő bővítmények (Perfmatters, Asset CleanUp) ugyanezt kattintós felületen kínálják, oldalanként és sablontípusonként.
Tipikus, nagy hozamú célpontok:
- Kapcsolati űrlap CSS és JS minden oldalon, holott az űrlap egyetlen aloldalon van.
- Galéria- vagy lightbox-stíluslap olyan bejegyzéseken, ahol nincs galéria.
- WooCommerce alap-stíluslapjai a blogon, a kapcsolat oldalon és a landing oldalakon.
- Teljes ikonkészlet három ikon miatt. Gyakran kiváltható beágyazott SVG-vel.
- Slider-CSS, amire csak a főoldalnak van szüksége.
- Emoji- és blokk-könyvtár stílusok olyan oldalakon, ahol egyiket sem használod.
A dequeue akkor biztonságos, ha a függőségeket is végignézed. Ha egy másik stíluslap a levett fájlra épül (például annak változóira vagy alap-osztályaira), akkor a kizárással nem egy fájlt takarítasz meg, hanem elrontasz egy másikat.
Miért nem elég a főoldalon tesztelni?
Rövid válasz: mert az automata unused CSS funkciók sablononként és URL-enként tanulnak, és ami a főoldalon hibátlan, az a termékoldalon, a keresési találati oldalon vagy a 404-esen hiányzó stílusként jelenik meg. Ez a saját nézőpontom, és a gyakorlatban ez okozza a legtöbb bosszúságot.
A mechanizmus egyszerű: a bővítmény lerendereli az oldalt, összegyűjti a ténylegesen használt szelektorokat, és kidobja a többit. A baj azzal van, ami a statikus HTML-ben nincs benne:
- Interakcióra megjelenő elemek. A kinyitott mobil menü, a legördülő almenü, a modális ablak, a tab és az akkordeon nyitott állapota, a „vissza a tetejére” gomb.
- Állapot-osztályok. Az
.is-active,.open,.errortípusú osztályok, amik csak JavaScript hatására kerülnek fel. - Soha be nem járt oldalak. 404, keresési találat, üres kosár, pénztár, köszönőoldal, szerzői archívum, lapozott archívum (
/page/2/). - Bejelentkezett nézet. Az admin sáv és a szerkesztés-linkek stílusai.
Saját tapasztalat: a hibák gyakorisági sorrendje elég állandó. Első helyen a mobil menü áll, ami vagy nem nyílik ki, vagy kinyílik, de átlátszó és elcsúszott. Másodikon a sütibanner, ami formázatlanul, teljes szélességben ül a tartalom tetején. Harmadikon az űrlap hibaüzenete, negyediken pedig a slider, ami egy pillanatra egymás alatti képekként villan fel, majd összeugrik. Ez utóbbi nemcsak csúnya, hanem a CLS értékét is rontja.
Szakmai feltételezés: ahogy a témák és oldalépítők egyre több CSS-t generálnak futásidőben, dinamikus osztálynevekkel, az automata kizárás kockázata nőni fog. A kézzel karbantartott kivétel-lista (safelist) unalmasabb, de tartósabb megoldás, mert nem esik szét a következő téma-frissítéskor.
Mit kell mindig visszaellenőrizni a beállítás után?
Rövid válasz: minden sablontípuson, mobilon és asztali gépen, kijelentkezve, privát ablakban és ürített gyorsítótárral kell végigmenni az alábbi listán. Ha ezt kihagyod, a hibát nem te fogod észrevenni, hanem az ügyfél vagy a látogató.
- Mobil menü: kinyílik, bezárható, hosszú menünél görgethető, és nyitva nem csúszik el mögötte a háttér.
- Elrejtett elemek felvillanása: akkordeon, tab, modális ablak, feliratkozó popup. Ezek betöltéskor ne villanjanak fel nyitott állapotban.
- Űrlapok: alapállapot, kötelező mező hibaüzenete, sikeres beküldés utáni visszajelzés, a spamvédelmi doboz megjelenése.
- Sütibanner: kijelentkezve és privát ablakban is megjelenik, a gombok formázottak, a részletes beállítások ablaka használható.
- Webshop: kosár, pénztár, mennyiségválasztó, variáció-legördülő, a kosárba tétel visszajelzése.
- Betűkészlet: a szöveg nem ugrik meg és nem méreteződik át látványosan a betűtípus megérkezésekor.
- Elrendezés-elmozdulás: a Lighthouse CLS értéke nem lett rosszabb a kiindulásnál.
- Ritka oldalak: 404, keresési találat, lapozott archívum, kategória, szerzői oldal.
- Bejelentkezett nézet: az admin sávval együtt sem csúszik el a fejléc.
- Több böngésző: Chrome mellett Safari és iOS is, mert a halasztott betöltés viselkedése nem mindenhol azonos.
A teszteléshez a legmegbízhatóbb a privát ablak, a DevTools „Disable cache” kapcsolója bekapcsolva, és a szerveroldali gyorsítótár ürítése minden módosítás után. Enélkül könnyen a saját, régi verziódat nézed, és jónak hiszed.
Milyen sorrendben érdemes nekiállni?
- Készíts teljes mentést (fájlok és adatbázis), és ha van rá mód, dolgozz staging másolaton.
- Mérj kiindulási állapotot: PageSpeed Insights mobilon, öt sablontípuson, és jegyezd fel az FCP, LCP és a blokkoló fájlok listáját.
- Takaríts először. A nem használt bővítmény kikapcsolása és az ikonkészlet leváltása kockázat nélküli nyereség, kritikus CSS nélkül is.
- Jöhet a feltételes kizárás, sablontípusonként, egyesével, minden lépés után ellenőrizve.
- Ezután kapcsold be a kritikus CSS-t és a halasztást, lehetőleg sablononként generálva.
- Menj végig a fenti ellenőrzőlistán.
- Mérj újra, majd nézd meg a valós felhasználói adatot is. Hivatalosan igazolt: a Search Console Core Web Vitals jelentése és a CrUX adatai 28 napos csúszó ablakon alapulnak, tehát a laborérték azonnal változik, a mezei adat viszont csak hetek múlva követi le.
Mit várhatsz ettől reálisan?
Rövid válasz: gyorsabb első megjelenést és jobb LCP-t igen, garantált helyezés-javulást nem. A sebesség a rangsorolásnak csak az egyik, viszonylag kis súlyú összetevője.
A Google hivatalos közlése szerint az oldalélmény jelzései akkor számítanak igazán, amikor több, tartalmilag hasonlóan jó találat versenyez. Ha a tartalom gyenge, attól még nem lesz jobb helyezés, hogy fél másodperccel korábban jelenik meg. A gyakorlati haszon inkább ott jelentkezik, hogy a mobilos látogató nem lép vissza az első két másodpercben, és az űrlapig is eljut.
Szakmai feltételezés: a válaszmotorok és az AI-crawlerek jellemzően nem futtatnak teljes körű renderelést és CSS-feldolgozást, ezért a blokkoló stíluslap önmagában valószínűleg nem akadályozza, hogy idézzenek az oldaladról. A lassú oldal viszont azt a forgalmat rontja, ami az idézés után ténylegesen megérkezik, és ez a szempont bőven elég indok a rendbetételre.
Források és további olvasnivalók
- Google Search Central dokumentáció (oldalélmény, Core Web Vitals, Lighthouse-útmutatók)
- web.dev teljesítmény-anyagok (renderelést blokkoló erőforrások, kritikus renderelési útvonal, LCP, CLS)
- Chrome for Developers dokumentáció és a DevTools Coverage eszköz leírása
- Chrome User Experience Report (CrUX) dokumentáció
- W3C specifikációk: CSS Object Model, Resource Hints, Preload
- WordPress Developer Resources:
wp_enqueue_style,wp_dequeue_style,wp_enqueue_scripts - MDN Web Docs: a
linkelem, amediaattribútum és a stíluslapok betöltési viselkedése
- A böngésző alapértelmezés szerint egyetlen pixelt sem rajzol ki, amíg a fejlécben hivatkozott összes CSS-fájl meg nem érkezett és fel nem dolgozódott.
- A fehér képernyő hossza az FCP, és mivel az LCP soha nem lehet korábbi az FCP-nél, a blokkoló CSS közvetlenül húzza fel a Core Web Vitals értékét.
- A kritikus CSS az első képernyőhöz szükséges minimális szabályhalmaz, amit inline beágyazol, a többit pedig halasztva töltöd be.
- Az automata unused CSS kapcsolók sablontípusonként tanulnak, ezért ami a főoldalon hibátlan, az a termék-, kosár- vagy 404-es oldalon eltörhet.
- Beállítás után kötelező visszanézni a mobil menüt, az elrejtett elemek felvillanását, az űrlapok hibaállapotát és a sütibannert, kijelentkezve is.
Gyakori kérdések
Elég, ha csak bekapcsolom a gyorsítótárazó bővítményben a kritikus CSS funkciót?
Bekapcsolni egy kattintás, de a munka nagyobb része utána jön. A generált kritikus CSS sablontípusonként eltér, és a csak interakcióra megjelenő elemek szabályai gyakran kimaradnak belőle. Kapcsold be, majd menj végig legalább öt sablontípuson mobilon és asztali gépen, kijelentkezve.
Miért látszik jónak a főoldalam, miközben a termékoldalon szétesik a dizájn?
Mert a nem használt CSS eltávolítása oldalanként vagy sablononként tanul. A főoldalon jelen lévő szelektorokat megtartja, a termékoldal sajátos elemeit (variáció-választó, kosár-visszajelzés, értékelés) viszont kidobhatja, ha a tanulás során nem járta be azt a nézetet. Ilyenkor sablontípusonként kell kivételt felvenni.
Mennyit javul ettől az LCP?
Ez oldalanként nagyon eltér, ezért számot felelősen nem lehet ígérni. Az irány viszont kiszámítható: az LCP nem lehet korábbi az FCP-nél, így amennyit a blokkoló CSS-ből visszanyersz, az jó eséllyel megjelenik az LCP-ben is. A valós hatást a Search Console 28 napos mezei adatán érdemes visszanézni, nem csak a labormérésen.
Mi a különbség a kritikus CSS és a nem használt CSS eltávolítása között?
A kritikus CSS azt mondja meg, mi kell azonnal az első képernyőhöz, a többit halasztja, de nem dobja el. A nem használt CSS eltávolítása ténylegesen kivágja azokat a szabályokat, amikről a bővítmény úgy dönt, hogy az adott oldalon nem kellenek. Az első visszafordítható és lényegesen kisebb kockázatú, a második hoz többet, de többet is tud törni.
Elronthatja ez a sütibannert vagy az adatkezelési megfelelést?
A formázás elromolhat, és ez gyakorlati probléma: ha a banner olvashatatlan vagy a gombok nem látszanak, a hozzájárulás kérése sérülhet. Ezért szerepel az ellenőrzőlistán külön tételként, privát ablakban, kijelentkezve tesztelve. A banner stíluslapját érdemes a kivétel-listára tenni, és nem halasztani.
Kell hozzá fejlesztő, vagy megoldható bővítménnyel?
A takarítás nagy része (felesleges bővítmények, ikonkészlet, oldaltípusonkénti kizárás) megoldható kattintós eszközkezelő bővítménnyel. A finomhangoláshoz, a függőségek átnézéséhez és a gyereksablonos feltételes kizáráshoz viszont jellemzően kell valaki, aki PHP-t is olvas. Mentés és staging környezet mindkét esetben indokolt.
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.