A lusta betöltés az egyik legolcsóbb sebesség-javítás, amit egy weboldalon be lehet kapcsolni: a böngésző csak akkor tölti le a képet, amikor az közeledik a képernyőhöz. Egy hosszú aloldalon ez tíz-húsz felesleges letöltést spórol meg az első másodpercben, mobilon pedig komoly adatforgalmat. Ezért kapcsolja be alapból szinte minden mai sablon és gyorsító bővítmény.
A baj ott kezdődik, hogy a legtöbb megoldás válogatás nélkül, mindenre ráteszi. Így késleltetve indul az a kép is, amelyik a látogató első benyomását adja, és amelyet a sebességmérő is a legfontosabb elemként mér. Nézzük végig, mikor fordul át a hasznos beállítás kárrá, és pontosan mit kell átállítani.
Mi történik technikailag, amikor lusta betöltést kapcsolsz be?
Röviden: a kép letöltése kikerül az oldal induló sorából, és egy későbbi, görgetéshez kötött pillanatra csúszik. Kétféleképpen szokott megvalósulni, és a kettő nagyon nem ugyanaz.
Az egyik a natív mód, amikor a képen ott van a loading="lazy" attribútum, a src viszont a helyén marad. A böngésző intézi az egészet, JavaScript nélkül. Hivatalosan igazolt: ezt az attribútumot a Chrome, a Firefox, a Safari és az Edge is támogatja, és a Google saját dokumentációja is ezt ajánlja első választásként.
A másik a JavaScript-alapú mód. Ilyenkor a valódi képcím egy saját attribútumba kerül (jellemzően data-src), a src helyén pedig egy pici üres pixel vagy elmosott helyőrző ül. Amikor a kép a nézetbe ér, egy szkript átmásolja a címet a helyére. Ez rugalmasabb, viszont itt tud legrosszabbul elromlani a dolog: ha a szkript nem fut le, nincs kép.
Miért árt, ha a fő kép is lusta betöltésű?
Mert a nyitóképernyő nagy képe általában maga az LCP-elem, vagyis az a tartalom, amelynek megjelenési idejét a Core Web Vitals méri. Ha erre lazy load kerül, a böngésző szándékosan késlelteti azt, amitől a mérés függ.
A késés több lépcsőből áll össze. A böngésző előbb végigolvassa a HTML-t, felépíti az elrendezést, kiszámolja, hogy a kép a nézetben van, és csak utána indítja a letöltést. Közben a képfelderítő mechanizmus, amely normál esetben már a HTML olvasása közben elindítaná a letöltést, ki van iktatva. Saját tapasztalat: WordPress-oldalakon ez tipikusan néhány száz ezredmásodperctől bő egy másodpercig terjedő különbséget jelent, gyenge mobilhálózaton a nagyobb véghez közelebb. Ez sokszor pont annyi, amennyi a mérés zöld és sárga sávja között van.
A hiba azért ennyire gyakori, mert a bekapcsolás automatikus, a kivétel viszont nem. Három szokásos forrás:
- a gyorsító bővítmény minden
imgelemre ráteszi az attribútumot, kivételkezelés nélkül; - a hero kép nem is
img, hanem CSS háttérkép, amit egy szkript cserél be görgetésre; - a képváltó vagy szlider modul saját lusta betöltést használ, és az első diát is késlelteti.
Mikor fordulhat elő, hogy a kép ki sem indexelődik?
Akkor, ha a renderelt HTML-ben nincs valódi képcím a src vagy srcset attribútumban, csak egy saját, nem szabványos attribútumban. Hivatalosan igazolt: a Google dokumentációja szerint a képek felfedezéséhez a képcímnek elérhetőnek kell lennie a HTML-ben (vagy képes webhelytérképben, illetve strukturált adatban), és a lusta betöltésnek úgy kell működnie, hogy a tartalom a renderelés során ténylegesen betöltődjön.
A klasszikus hibás minta így néz ki:
<img class="lazy" src="data:image/gif;base64,R0lGOD..." data-src="/kepek/termek.jpg" alt="Termékfotó">
Ha a szkript valamiért nem fut le a feldolgozáskor (időtúllépés, hibás betöltési sorrend, egy másik szkript elszáll előtte), akkor a feldolgozó annyit lát, hogy az oldalon egy üres pixel van. A szöveges tartalom rendben indexelődik, a kép viszont nem kerül be a Képkeresőbe. Termékoldalon, receptnél, ingatlanhirdetésnél vagy szolgáltatói galériánál ez érezhető veszteség.
A biztonságos változat az, ha a szabványos attribútumok mindig ki vannak töltve, és a lusta betöltést a natív megoldás intézi:
<img src="/kepek/termek-800.jpg" srcset="/kepek/termek-400.jpg 400w, /kepek/termek-800.jpg 800w" sizes="(max-width: 600px) 100vw, 800px" width="800" height="600" loading="lazy" decoding="async" alt="Termékfotó">
Hogyan okoz elrendezés-elmozdulást a késleltetett tartalom?
Úgy, hogy a böngésző nem tudja előre, mekkora helyet hagyjon. Amikor a kép megérkezik, szétnyomja a körülötte lévő szöveget, a látogató pedig épp akkor téveszti el a gombot, amikor kattintana. Ezt méri a CLS.
A javítás mechanikus: minden képnek legyen width és height attribútuma, vagy CSS-ben rögzített képarány. A böngésző ebből kiszámolja a helyet, és üresen tartja a kép érkezéséig. Ugyanez vonatkozik a beágyazott keretekre és a reklámhelyekre is: ha nincs fix magasságuk, ugrálni fog az oldal.
Saját tapasztalat: a legrosszabb ugrálást nem a képek, hanem a késleltetve betöltő sütikezelő sáv, a hírlevél-felugró és a chat-buborék okozza, mert ezek utólag tolják be magukat az oldal tetejére vagy aljára. Ha ilyet késleltetsz, tedd fix pozícióba, hogy ne mozgassa a dokumentum-folyamot.
Mikor elég a natív loading="lazy", és mikor kell fetchpriority="high"?
Egyszerű szabály: ami az első képernyőn látszik, az kap prioritást, ami alatta van, az lazy loadot. A kettő nem keverhető ugyanazon a képen.
A nyitókép helyes formája nagyjából ez:
<img src="/kepek/hero-1600.jpg" width="1600" height="900" fetchpriority="high" decoding="async" alt="Bemutató fotó">
Figyeld meg, hogy itt nincs loading attribútum. Az alapérték (eager) pontosan azt csinálja, amit szeretnél. A fetchpriority="high" pedig azt üzeni a böngészőnek, hogy ezt a letöltést hozza előre a többi elé. Hivatalosan igazolt: ez a Priority Hints szabvány része, a Chromium-alapú böngészők támogatják, a többi böngésző pedig egyszerűen figyelmen kívül hagyja, tehát nem tud kárt okozni.
Ha a nyitókép CSS háttérként jön, a HTML-ben nincs mit jelölni. Ilyenkor a fejlécbe kerülő előtöltés segít:
<link rel="preload" as="image" href="/kepek/hero-1600.avif" fetchpriority="high">
Néhány gyakorlati határ, amit érdemes tartani:
- oldalanként egyetlen kép kapjon magas prioritást, különben a jelzés értelmét veszti;
- szlidernél csak az első dia legyen azonnali, a többi mehet lazyra;
- logó és apró ikonok esetén ne bajlódj a lusta betöltéssel, a nyereség nulla közeli;
- a lábléc képei, a kapcsolódó cikkek bélyegképei és a hosszú galériák a lazy load ideális célpontjai.
Mit kezdj a beágyazott videóval, térképpel és a chat-widgettel?
Ezek a legjobb jelöltek a késleltetésre, mert nagyok, ritkán kellenek azonnal, és sokszor idegen domainről töltenek be egész szkriptcsomagokat.
A beágyazott kereteknél a natív attribútum ugyanúgy működik, mint képnél: <iframe src="..." loading="lazy" width="640" height="360">. Videónál ennél is jobb a kattintásra betöltő minta: alapból csak egy előnézeti kép és egy lejátszás gomb látszik, a tényleges lejátszó pedig kattintásra épül be. Térképnél ugyanez a logika, statikus képpel vagy egyszerű címblokkal helyettesítve.
A chat-widget külön eset. Saját tapasztalat: ezek szinte mindig a legdrágább külső erőforrások az oldalon, és jellemzően a betöltés első pillanatában indulnak. Ha késleltetve indítod (első görgetésre, néhány másodperc után, vagy egy saját, könnyű buborékra kattintva), a mérési eredmény érezhetően javul, a valós beszélgetések száma pedig tapasztalatom szerint nem esik vissza. Ezt viszont mindenképp mérd az adott oldalon, mert erősen függ a közönségtől.
Ami a keresők szempontjából számít: a beágyazott videó tartalma önmagában nem helyettesíti a szöveget. Ha a videó fontos információt hordoz, legyen mellette leírás vagy leirat is a HTML-ben.
Hogyan ellenőrzöd, hogy jól áll-e a lusta betöltés?
Három helyen kell megnézni, és mindhárom mást mutat. A forráskód gyorsnézete önmagában félrevezet, mert nem mutatja a szkriptek utáni állapotot.
1. A renderelt HTML-ben:
- Nyisd meg az oldalt, és a fejlesztői eszközök Elements fülén keresd meg a nyitóképet.
- Nézd meg, van-e rajta
loading="lazy". Ha igen, ez a javítandó pont. - Ellenőrizd, hogy a
srcvalódi képcímet tartalmaz-e, nem üres pixelt vagy csakdata-srcattribútumot. - Nézd meg, van-e
widthésheightértéke. - Kapcsold ki a JavaScriptet, töltsd újra, és nézd meg, mely képek tűnnek el. Ami eltűnik, azt a feldolgozó is kockázatosnak látja.
2. A Képkeresőben:
- Keress rá a domainre képkeresésben, és nézd meg, a fontos képek megjelennek-e.
- Használd a Search Console URL-ellenőrzőjét: a renderelt HTML-ben keresd meg a képcímet.
- Ha sok kép hiányzik, tegyél be képes webhelytérképet, ez segítheti a felfedezést.
3. A mérőeszközben:
- Futtass PageSpeed Insights vagy Lighthouse mérést, és nézd meg, mit jelöl LCP-elemként.
- Ha az LCP-elem egy lazy loadolt kép, a jelentés külön figyelmeztetést is ad rá.
- Nézd meg a CLS értéket és az elmozduló elemeket a Performance fülön.
- A javítás után mérj újra, és ha van rá adat, hasonlítsd össze a Search Console Core Web Vitals jelentésének valós felhasználói adataival is.
Hogyan viselkednek a lazy-loadolt képekkel a kereső- és AI-botok?
Hivatalosan igazolt: a Googlebot rendereli az oldalakat, de nem görget úgy, ahogy egy ember. Ehelyett nagyon magas nézetablakkal dolgozik, így a görgetéshez kötött, natív lusta betöltés általában kiváltódik. Ezért működik jól a natív megoldás, és ezért kockázatosabb a saját szkriptre épülő, egyedi görgetésfigyelés.
Szakmai feltételezés: az AI-asszisztensek mögötti letöltők jelentős része nem rendereli a JavaScriptet, hanem a nyers HTML-lel dolgozik. Ha egy kép csak data-src attribútumban létezik, ezek nagy valószínűséggel egyáltalán nem látják. Ugyanez igaz a görgetésre betöltő szöveges tartalomra is, ami ennél is nagyobb baj: a végtelen görgetéssel megjelenő terméklista vagy hozzászólás-blokk sok bot számára egyszerűen nem létezik.
Ebből következik a gyakorlati elv: a lusta betöltés a képekre való, a szövegre nem. Ami tényleges információt hordoz (leírás, ár helyett szolgáltatás-tartalom, GYIK, paraméterek), az legyen benne a kiszolgált HTML-ben, JavaScript futtatása nélkül is.
Mi az álláspontunk a lusta betöltésről?
Kapcsold be alapértelmezésben, és a hero képen kapcsold ki. Ez a legjobb arány költség és haszon között, amit ezen a területen ismerek. A globális bekapcsolás egy pipa, a kivétel egy attribútum, és a kettő együtt jó eséllyel többet javít a mért sebességen, mint a legtöbb drágább optimalizálás.
Saját tapasztalat: a legtöbb oldalon, ahol a mérés a nyitóképnél panaszkodik, nem hiányzik semmilyen bonyolult beállítás. Egyszerűen rákerült a lazy load arra az egy képre, amelyikre nem lett volna szabad. A javítás perceken belül elvégezhető, viszont sokszor évekig ott marad, mert senki nem nézi meg, mit tesz a gyorsító bővítmény alapból.
Fontos árnyalat: a lusta betöltés helyes beállítása nem garantál jobb helyezést. A sebesség csak egy tényező a sok közül. Amit szinte biztosan javít, az a mért felhasználói élmény és annak esélye, hogy a képeid egyáltalán bekerüljenek a Képkeresőbe. Ez utóbbi pedig már közvetlen forgalmi kérdés.
Források és további olvasnivalók
- Google Search Central: Lazy-loading (Lusta betöltés) dokumentáció
- Google Search Central: Google Képek SEO ajánlások
- Google Search Central: JavaScript SEO alapok
- web.dev: Largest Contentful Paint (LCP) és Cumulative Layout Shift (CLS) útmutatók
- web.dev: Optimize resource loading with the Fetch Priority API
- MDN Web Docs: HTML img elem, loading és fetchpriority attribútumok
- W3C / WHATWG HTML Living Standard: Lazy loading attributes
- Chrome for Developers: Lighthouse és PageSpeed Insights dokumentáció
- Az első képernyőn látszó fő képre soha ne kerüljön loading="lazy", mert ez közvetlenül rontja az LCP-t.
- A JavaScript-alapú lazy load data-src megoldása nélkül a kép valódi src attribútuma hiányzik, így a Képkereső jó eséllyel nem látja.
- Minden képnek adj width és height (vagy CSS aspect-ratio) értéket, különben a felugró tartalom elmozdítja az elrendezést.
- A beágyazott videó, térkép és chat-widget a legjobb jelölt a késleltetésre: ezek viszik a legtöbb erőforrást és a legritkábban kellenek azonnal.
- Ellenőrizni renderelt HTML-ben, a Képkeresőben és mérőeszközben kell, nem a forráskód gyorsnézetében.
Gyakori kérdések
Minden képre rátehetem a loading="lazy" attribútumot?
Nem. Ami az első képernyőn látszik (jellemzően a nyitókép és a logó), az maradjon azonnali betöltésű, mert ez adja az LCP mérését. A hajtás alatti képek, galériák, bélyegképek viszont nyugodtan kaphatják meg.
Honnan tudom, hogy melyik a nyitóképem, ha több nagy kép is van az oldal tetején?
A PageSpeed Insights és a Lighthouse jelentés külön kiírja, melyik elemet mérte LCP-nek. Ezt a mérést végezd el mobil és asztali nézetben is, mert eltérhet a két eredmény.
Ha JavaScript-alapú lazy loadot használ az oldalam, mindenképp le kell cserélni?
Nem feltétlenül, de ellenőrizni kell. Ha a kép valódi címe ott van a szabványos src vagy srcset attribútumban, és JavaScript nélkül is megjelenik, akkor nincs indexelési kockázat. Ha csak data-src van, érdemes átállni a natív megoldásra.
A fetchpriority="high" működik minden böngészőben?
Nem mindegyikben, de nem is okoz gondot ott, ahol nincs támogatás: az ismeretlen attribútumot a böngésző figyelmen kívül hagyja. A Chromium-alapú böngészőkben viszont érezhetően előre tudja hozni a nyitókép letöltését.
Segít a lusta betöltés kikapcsolása a hero képen a keresési helyezésen?
Közvetlen helyezés-javulást senki nem tud ígérni. Amit javít, az a mért betöltési idő és a felhasználói élmény, ami hosszabb távon segítheti a teljesítményt. Az indexelési kockázat megszüntetése ennél jóval kézzelfoghatóbb nyereség.
A beágyazott YouTube-videót és a Google Térképet is lehet késleltetni?
Igen, és ezek a legjobb jelöltek rá. A keretre tehető natív loading="lazy", videónál pedig a kattintásra betöltő megoldás a leghatékonyabb. Adj nekik fix méretet, hogy ne mozdítsák el az elrendezést.
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.