WordPress lazy loading: teljes útmutató

A WordPress lazy loading azt jelenti, hogy a képek, iframe-ek és videók csak akkor töltődnek be, amikor a látogató a közelükbe görget. A WordPress 5.5 óta ez alapból bekapcsol a képekre a loading="lazy" attribútummal. A lényeg a helyes beállítás: a hajtás feletti, fő képet soha ne töltsd későn, minden mást igen.

Alapfogalmak

Mielőtt bármit átállítasz, érdemes tisztán látni, miről szól a lusta betöltés. A böngésző alapesetben az oldal összes erőforrását igyekszik letölteni, akkor is, ha a látogató soha nem görget le az oldal aljáig. Egy hosszabb blogbejegyzésnél ez tucatnyi képet jelenthet, amelyek közül az első megjelenéskor jó esetben egy vagy kettő látszik. A lazy loading ezt a pazarlást szünteti meg: a nem látható elemek letöltését elhalasztja addig, amíg tényleg szükség lesz rájuk.

A WordPress környezetben a téma nem csak technikai finomság. A betöltési sorrend közvetlenül hat a Core Web Vitals mutatókra, ezeken keresztül pedig a felhasználói élményre és a keresési teljesítményre. Ha a teljes optimalizálási képet szeretnéd átlátni, a WordPress SEO: teljes útmutató ad hozzá keretet, itt a betöltésre fókuszálunk.

Hajtás feletti és hajtás alatti tartalom

A "hajtás feletti" (angolul above the fold) rész az, amit a látogató görgetés nélkül lát az oldal megnyitásakor. Ez eszközönként eltér: egy asztali monitoron több fér el, mint egy mobilon. A lazy loading egyik alapszabálya, hogy a hajtás feletti elemeket azonnal kell betölteni, a hajtás alattiakat pedig lehet később. Ez a határ nem fix pixelszám, hanem az adott sablontól és képernyőtől függ, ezért a döntést mindig a konkrét elrendezés alapján hozd meg.

Natív és JavaScript alapú lazy loading

Két nagy megközelítés létezik. A natív megoldás a böngészőre bízza a döntést: az img vagy iframe tagen szereplő loading="lazy" attribútum jelzi, hogy az elem várhat. A JavaScript alapú megoldás régebbi: a valódi képcím egy data-src attribútumban ül, és egy szkript figyeli a görgetést (ma jellemzően az Intersection Observer API-val), majd a megfelelő pillanatban kicseréli. A natív változat egyszerűbb és nem igényel külön kódot, a JavaScript alapú viszont több kontrollt ad, például háttérképeknél.

A legfontosabb fogalmak egy helyen

Fogalom	Mit jelent	Miért számít
loading="lazy"	Natív HTML attribútum, késleltetett betöltést kér	Kevesebb kezdeti letöltés
loading="eager"	Azonnali betöltést kér	A fő képnél ezt szeretnéd
fetchpriority="high"	Magas letöltési prioritást jelez a böngészőnek	Gyorsíthatja a legnagyobb kép megjelenését
LCP	Largest Contentful Paint, a legnagyobb látható elem megjelenési ideje	Core Web Vitals mutató
CLS	Cumulative Layout Shift, az elrendezés elcsúszása	Méret nélküli képek rontják
Placeholder	Helykitöltő a betöltés előtt	Stabil elrendezést ad

Mire vonatkozhat a lazy loading

Bejegyzésen belüli képek és galériák.
Beágyazott YouTube vagy Vimeo videók (iframe).
Térképek, közösségi beágyazások.
CSS háttérképek, de ezekhez a natív attribútum nem elég, külön megoldás kell.
Hozzászólásokban megjelenő avatarok.

Fontos tévhit, hogy a lazy loading "mindig gyorsít". Valójában csak a nem látható tartalomnál gyorsít. Ha a látható fő képre is ráteszed, a böngésző később kezdi letölteni, és ezzel lassítod pont azt a mutatót, amelyet javítani szeretnél. Ez a kettősség végig fogja kísérni a cikket.

Hogyan működik?

A működés megértése segít abban, hogy ne vakon kapcsolgass beállításokat. Amikor a böngésző feldolgozza a HTML-t, minden képtaghez eldönti, mikor kéri le a fájlt. Egy loading="lazy" attribútummal ellátott képnél ezt a kérést addig halasztja, amíg a kép egy bizonyos távolságra nem kerül a látható területtől. Ezt a távolságot a böngésző maga határozza meg, és a hálózati viszonyoktól is függhet, vagyis a kép jellemzően már azelőtt elkezd betöltődni, hogy a látogató odaérne.

Mit csinál a WordPress magja

A WordPress 5.5-ös verziója óta a mag automatikusan hozzáadja a loading="lazy" attribútumot a tartalomban szereplő képekhez, ha azoknak van width és height értéke. Az 5.7-es verzió kiterjesztette ezt az iframe-ekre is. Később a mag megtanulta, hogy az első, valószínűleg hajtás feletti képeket kihagyja a lusta betöltésből, a 6.3-as verziótól pedig a legnagyobb képjelöltre fetchpriority="high" attribútumot is tehet. A pontos viselkedés témától és sablonfelépítéstől függ, ezért mindig ellenőrizd a forráskódban, mi kerül ki valójában.

A betöltés lépései egy bejegyzésnél

A szerver elküldi a HTML-t, benne az img tagekkel és attribútumokkal.
A böngésző elkezdi feldolgozni, és az eager vagy attribútum nélküli képeket azonnal kéri.
A lazy képeknél megjegyzi a helyüket, de nem tölti le őket.
A méretattribútumok alapján lefoglalja a helyüket, így az elrendezés nem ugrál.
Görgetéskor, amikor egy kép a küszöbtávolságon belül kerül, elindul a letöltés.
A kép megjelenik a már lefoglalt helyen.

Miért fontos a width és a height

A méretattribútumok kettős szerepet töltenek be. Egyrészt a WordPress ezek alapján dönt a lazy attribútum hozzáadásáról, másrészt a böngésző ezekből számolja ki a képarányt, mielőtt a fájl megérkezne. Ha hiányoznak, a kép helye nulla magasságú, majd betöltéskor hirtelen kitágul, és lejjebb tolja a szöveget. Ezt hívjuk elrendezés-elcsúszásnak, amely a CLS mutatót rontja. A médiatárból beszúrt képeknél a WordPress általában kiírja a méreteket, a kézzel beillesztett HTML-nél viszont gyakran hiányoznak.

Kidolgozott példa: egy receptoldal

Vegyünk egy szemléltető receptbejegyzést: a tetején egy nagy borítókép, alatta 8 lépésfotó, majd egy beágyazott videó és végül 15 hozzászólás avatarral. Lazy loading nélkül a böngésző az első betöltéskor mind a 24 vizuális elemet lekérné. Helyes beállítással a borítókép eager és magas prioritású, a 8 lépésfotó, a videó és az avatarok lusták. Egy mobilos látogató, aki csak a hozzávalókig görget, így talán 3 vagy 4 képet tölt le a teljes készlet helyett. A számok szemléltetők, de az arány jól mutatja, mekkora különbség lehet egy képekkel teli oldalon.

A szkriptes megoldások működése röviden

A bővítmények egy része nem a natív attribútumra épít, hanem átírja a HTML-t: a src helyére egy apró helykitöltőt tesz, a valódi címet data-src-be rakja, és egy szkript cseréli vissza. Ennek előnye, hogy háttérképeket és régi böngészőket is kezel. Hátránya, hogy ha a szkript hibázik vagy késik, a képek egyáltalán nem jelennek meg, és a keresőrobotok számára is bizonytalanabb lehet a kép felfedezése, ha nincs noscript tartalék.

Fő módszerek

WordPressben többféleképpen kezelheted a lusta betöltést, és a jó választás az oldal típusától függ. Egy egyszerű blognál sokszor elég a mag alapviselkedése, egy nehéz, oldalépítővel készült webshopnál viszont finomhangolás kell. Az alábbiakban végigmegyünk a fő utakon, majd adok egy döntési szabályt, amely alapján választhatsz.

1. A WordPress mag alapbeállítása

A legegyszerűbb módszer, ha nem csinálsz semmit, és hagyod, hogy a mag dolgozzon. Friss WordPress és egy rendesen megírt, a mag képfüggvényeit használó téma esetén ez már jó kiindulópont. Hátránya, hogy a mag heurisztikája nem látja a tényleges képernyőt, ezért például egy egyedi fejléckép vagy oldalépítős hero blokk esetén tévedhet.

2. Szabályozás kóddal

Ha fejlesztői kontrollt szeretnél, a WordPress szűrőket kínál. A wp_lazy_loading_enabled szűrővel teljesen kikapcsolhatod vagy kontextus szerint szabályozhatod a lusta betöltést. Egy adott képnél pedig a wp_get_attachment_image függvénynek átadhatod a loading attribútumot eager értékkel, illetve a fetchpriority attribútumot. Kódot mindig gyerektémába vagy saját bővítménybe tegyél, ne a szülőtéma fájljaiba, különben a következő frissítés felülírja.

3. Teljesítménybővítmények

A gyorsítótárazó és optimalizáló bővítmények többsége tartalmaz lazy loading funkciót, gyakran kibővítve: háttérképek, iframe-ek helyettesítése előnézeti képpel, az első néhány kép kizárása. A konkrét lehetőségek bővítményenként és verziónként eltérnek, ezért a beállítási képernyőn nézd meg, mit kínál a te eszközöd. Arra figyelj, hogy egyszerre csak egy réteg kezelje a lusta betöltést.

4. Videók: helyettesítő előnézet

A beágyazott videók különösen nehezek, mert az iframe nem csak magát a lejátszót, hanem sok szkriptet is betölt. Erre a "facade" (homlokzat) megoldás a legjobb: a valódi lejátszó helyén csak egy előnézeti kép és egy lejátszás gomb látszik, és a tényleges iframe kattintásra töltődik be. Ez jóval többet spórol, mint a puszta loading="lazy" az iframe-en.

Összehasonlítás

Módszer	Előny	Hátrány	Kinek ajánlott
Mag alapbeállítás	Nulla munka, nincs extra kód	Kevés kontroll	Egyszerű blogok
Kódos szabályozás	Pontos, képszintű döntések	Fejlesztői tudás kell	Egyedi témák
Bővítmény	Háttérképek, kizárások kezelése	Ütközhet más réteggel	Oldalépítős oldalak
Videó homlokzat	Nagy megtakarítás	Egy plusz kattintás	Videós tartalmak

Döntési szabály

Ha a fő kép a sablon része és a mag jól kezeli: maradj az alapbeállításnál.
Ha a forráskódban a hero képen loading="lazy" szerepel: kódból vagy bővítményből zárd ki, és adj neki fetchpriority="high" értéket.
Ha CSS háttérkép a fő látvány: ne lusta betöltéssel kezeld, hanem előtöltéssel.
Ha két vagy több videó van az oldalon: használj homlokzatot.
Ha már van optimalizáló bővítményed: annak a lazy funkcióját használd, ne telepíts mellé másikat.

A képek alt szövege és fájlneve a lusta betöltéstől függetlenül fontos, ezeket az SEO bővítményed is ellenőrizheti. A beállítás részleteiről a Yoast SEO: teljes útmutató és a Rank Math: teljes útmutató ír bővebben.

Gyakori hibák

A lazy loading az egyik olyan optimalizálás, amelyet könnyű rosszul csinálni úgy, hogy közben semmi nem tűnik hibásnak. Az oldal betölt, a képek megjelennek, mégis rosszabbak lesznek a mutatók. Az alábbi hibák a leggyakoribbak, mindegyikhez megmutatom, hogyan ismered fel és javítod.

Lusta betöltés a fő képen

Ez a klasszikus hiba. A hero kép vagy a kiemelt kép loading="lazy" attribútumot kap, ezért a böngésző csak a renderelés későbbi szakaszában kéri le. Mivel jellemzően ez a legnagyobb látható elem, az LCP ideje megnő. Felismerés: nyisd meg a forráskódot, keresd meg az első nagy képet, és nézd meg az attribútumait. Javítás: eager vagy attribútum nélküli betöltés és fetchpriority="high".

Dupla lusta betöltés

Ha a mag natív attribútuma mellett egy bővítmény is átírja a képeket szkriptes módszerrel, a kettő ütközhet. Előfordulhat, hogy a kép két feltételre is vár, vagy a helykitöltő beragad. Tipikus tünet, hogy egyes képek csak villanással, késve vagy egyáltalán nem jelennek meg. Javítás: egy réteg maradjon aktív, a többit kapcsold ki.

Hiányzó méretek és elcsúszó elrendezés

Kézzel beillesztett HTML, oldalépítős modulok vagy külső forrásból érkező képek esetén gyakran hiányzik a width és height. Lusta betöltéssel a probléma felerősödik, mert a kép a görgetés közben érkezik meg, és a szöveg a látogató szeme előtt ugrik. Javítás: adj meg méreteket, vagy CSS-ben aspect-ratio értéket.

Háttérképek figyelmen kívül hagyása

A natív attribútum csak img és iframe tagen működik. A CSS háttérként betöltött képekre nem hat, így azok vagy mind azonnal betöltődnek, vagy egy szkriptes megoldás kezeli őket. Gyakori ellenpélda: valaki büszkén jelenti, hogy bekapcsolta a lazy loadingot, miközben az oldal fő látványa egy háttérkép, amely ettől semmit nem változott.

Túl kicsi elemek, túl sok szkript

Egy apró ikonnál vagy logónál a lusta betöltés nem hoz érdemi megtakarítást, a szkriptes megoldás viszont futásidőt igényel. Ha egy bővítmény minden apró képet szkripttel kezel, könnyen többet veszítesz a JavaScript futtatásán, mint amennyit nyersz.

Tévhit: a Google nem látja a lusta képeket

A natív loading="lazy" attribútummal betöltött képeket a Google dokumentációja szerint a renderelés során képes felfedezni, a gond inkább a görgetéshez vagy kattintáshoz kötött, szkriptes megoldásoknál lehet. Ha szkriptes módszert használsz, legyen a valódi képcím a HTML-ben is elérhető, például noscript tartalékkal. A képek indexelése egyébként a teljes technikai SEO része, a All in One SEO: teljes útmutató a beállítások oldaláról is érinti.

Ellenőrzőlista a hibák kiszűréséhez

Az első látható nagy képen nincs loading="lazy".
A fő képen van fetchpriority="high", de csak egyetlen képen.
Minden img tagnek van width és height értéke.
Csak egy eszköz kezeli a lusta betöltést.
A háttérképek kezelése tudatos döntés, nem véletlen.
A videók homlokzattal vagy legalább lusta iframe-mel töltődnek.
Mobilon is ellenőrizted, mert ott a hajtás határa máshol van.

Mérés

Lazy loading beállítása mérés nélkül találgatás. A jó hír, hogy a hatás jól mérhető ingyenes eszközökkel, és egy egyszerű munkafolyamattal követheted, hogy egy változtatás segített vagy ártott. A kulcs, hogy ugyanazokat az oldalakat ugyanúgy mérd előtte és utána.

Mit mérj

Három mutató a legfontosabb. Az LCP megmutatja, hogy a fő kép időben megjelenik-e, ezt ronthatja a túlzott lusta betöltés. A CLS jelzi, hogy a később érkező képek tolják-e az elrendezést. A harmadik az első betöltéskor letöltött adatmennyiség és a kérések száma, amely a megtakarítást mutatja. Ha csak az utóbbit figyeled, könnyen azt hiszed, hogy minden rendben, miközben az LCP romlott.

Laboratóriumi és terepi adatok

A laboratóriumi mérés (például a Lighthouse vagy a PageSpeed Insights laborrésze) egy szimulált környezetben fut, gyorsan ad visszajelzést, és alkalmas a változtatás azonnali ellenőrzésére. A terepi adat valódi látogatóktól származik, ezt a PageSpeed Insights terepi része és a Search Console Core Web Vitals jelentése mutatja, de csak elegendő forgalom mellett, és lassabban frissül. Mindkettő kell: a labor a gyors visszajelzéshez, a terep a valós hatáshoz.

Mérési munkafolyamat

Válassz ki 3 vagy 4 jellemző oldalt: kezdőlap, egy hosszú bejegyzés, egy kategóriaoldal, és ha van, egy termékoldal.
Mérd le mindegyiket mobil és asztali nézetben, jegyezd fel az LCP, CLS értékét és a kérések számát.
Nézd meg a PageSpeed Insightsban, melyik elem az LCP elem, és van-e rajta lusta betöltés.
Végezd el a változtatást, majd ürítsd a gyorsítótárat.
Mérd újra ugyanazokat az oldalakat, többször, mert a laborérték is ingadozik.
Néhány hét múlva nézd meg a terepi adatokat a Search Console-ban.

Ellenőrzés a böngészőben

A böngésző fejlesztői eszközeinek Hálózat (Network) fülén szűrj a képekre, és töltsd újra az oldalt görgetés nélkül. Ha helyes a beállítás, csak a hajtás feletti képek jelennek meg a listában. Ezután görgess lassan lefelé, és figyeld, ahogy újabb kérések érkeznek. Ha a fő kép a lista végén, későn jelenik meg, az gyanús. A Teljesítmény (Performance) fülön az LCP jelölő is megmutatja, melyik elem és mikor számít.

Szemléltető mérési napló

Oldal	Állapot	LCP elem	Kérések első betöltéskor	Megjegyzés
Hosszú bejegyzés	Előtte	Kiemelt kép, lazy	Sok	Fő kép késik
Hosszú bejegyzés	Utána	Kiemelt kép, eager, high	Kevesebb	Fő kép korán érkezik
Kategóriaoldal	Előtte	Első bélyegkép	Minden bélyegkép	Nincs lazy a rácson
Kategóriaoldal	Utána	Első bélyegkép, eager	Csak az első sor	Többi lusta

A táblázat egy kitöltési minta, nem valós mérés. Érdemes ilyen formában vezetni a saját naplódat, mert így hónapok múlva is látod, melyik változtatás mit okozott, és egy téma- vagy bővítményfrissítés utáni visszaesést is gyorsan észreveszel.

Határeset: amikor a mérés félrevezet

Ha az oldalad tetején süti- vagy hírlevél-felugró van, az LCP elem akár ez a felugró szövege is lehet, és a képbetöltés módosítása látszólag semmit nem változtat. Ilyenkor először azonosítsd, mi az LCP elem valójában, és csak utána optimalizálj. Hasonló csapda, ha a mérés gyorsítótárazott, bejelentkezett állapotban fut: kijelentkezve, privát ablakban mérj.

Kapcsolódó részletes útmutatók

A lusta betöltés csak egy darab a WordPress oldal teljesítményének és láthatóságának kirakósában. A képek alt szövege, a strukturált adatok, az oldaltérkép és a technikai beállítások együtt határozzák meg, hogyan teljesít az oldalad a keresőben. Ha a betöltést rendbe tetted, a következő lépés, hogy a SEO eszközeidet és alapjaidat is áttekintsd.

Az alábbi útmutatók segítenek ebben. Az általános áttekintéssel érdemes kezdeni, majd azt az SEO bővítményt választani, amelyet az oldaladon használsz, vagy amelyet bevezetni tervezel. Mindhárom bővítmény más felületet és logikát kínál, ezért a saját eszközödhöz tartozó leírás lesz a leghasznosabb.

Javasolt olvasási sorrend

Kezdd a teljes WordPress SEO áttekintéssel, hogy lásd, hol a helye a betöltésoptimalizálásnak.
Ezután nézd meg a saját SEO bővítményed útmutatóját.
Végül térj vissza a mérési munkafolyamathoz, és ellenőrizd az eredményt.

Útmutatók

Bármelyik irányba indulsz tovább, a lazy loadingnál megismert elv általánosan is igaz: előbb mérj, aztán egyszerre csak egy dolgot változtass, és mérj újra. Így pontosan látod, melyik beállítás hozott eredményt, és melyiket érdemes visszavonni.