A kép a legtöbb weboldalon a legnagyobb letöltendő elem, mégis ezen spórolnak a legtöbben a legkevesebbet. Egy kezeletlen fotó önmagában több adatot mozgat, mint az egész HTML, CSS és JavaScript együtt. Ha ezt rendbe teszed, egyszerre javul a sebesség, a mobilélmény és az is, hogy a keresők meg az AI-rendszerek mit értenek meg a képeidből. Az alábbiakban végigmegyek a formátumválasztáson, a tömörítésen, a méretmegadáson, a lazy-loadon és az alt-szövegen, gyakorlati példákkal.
Melyik képformátumot érdemes választani 2026-ban?
Röviden: fotókhoz kezdd a WebP-vel, és ahol a rendszered engedi, kínáld fel az AVIF-ot is; a logóhoz és a vonalas grafikához maradj SVG-nél. A böngészők túlnyomó többsége évek óta támogatja a WebP-t, ez ma biztonságos alapértelmezés (ez a böngészők hivatalos kompatibilitási adata, nem feltételezés).
A gyakorlatban a WebP azonos vizuális minőség mellett jellemzően 25-35 százalékkal kisebb fájlt ad, mint a régi JPEG. Az AVIF ennél is tovább mehet, gyakran 50 százalék körüli megtakarítással, cserébe lassabban kódolódik és nem minden régi eszközön jelenik meg. Ezért éri meg a <picture> elemmel több forrást felkínálni, és a böngészőre bízni a döntést:
<picture><source srcset="kep.avif" type="image/avif"><source srcset="kep.webp" type="image/webp"><img src="kep.jpg" alt="..." width="1200" height="800"></picture>
A böngésző fentről lefelé az első általa támogatott formátumot tölti le, a végén az <img> a biztonsági tartalék. A logót, ikont, egyszerű ábrát viszont ne rakd raszterbe: az SVG vektoros, bármekkora méretben éles marad, és sokszor pár kilobájt az egész.
Mennyire tömörítsd a képet minőségvesztés nélkül?
Röviden: a fotóknál a 75-82 közötti minőségi érték szinte mindig jó kompromisszum, felette már alig látszik különbség, viszont gyorsan hízik a fájl. Ezt nem szemre kell belőni, hanem meg lehet nézni oldalanként.
Fontos a helyes sorrend. Előbb a valós megjelenített méretre skálázd a képet, és csak utána tömöríts. Az egyik leggyakoribb hiba, hogy egy 4000 pixel széles fényképezőgép-fájlt tölt fel valaki egy 600 pixeles helyre. Ilyenkor a böngésző kicsinyíti, de a teljes adatmennyiséget letöltötte hozzá. Néhány támpont a gyakorlatból (ez saját tapasztalat, nem hivatalos szabvány):
- Tartalmi fotó tartalomtörzsben: hosszabb oldal jellemzően 1200-1600 pixel elég.
- Teljes szélességű borítókép: 1920-2000 pixel felett ritkán van értelme.
- Bélyegkép, avatar: a tényleges megjelenített méret kétszerese a retina kijelzők miatt.
A tömörítéshez használhatsz automatizált eszközt (például squoosh, sharp build közben, vagy a legtöbb CMS-ben egy kép-plugin). A cél nem a legkisebb szám, hanem az a pont, ahol a minőségromlás még nem látszik a te tartalmadon. Textúrás, sok részletes fotónál óvatosabban tömöríts, egyszínű háttérnél bátrabban.
Hogyan előzöd meg a képekkel az elrendezés-ugrálást (CLS)?
Röviden: mindig add meg a kép eredeti width és height attribútumát, vagy CSS-ben az aspect-ratio értéket, hogy a böngésző már betöltés előtt lefoglalja a helyet. Ez a Cumulative Layout Shift, a Core Web Vitals egyik mérőszáma szempontjából az egyik legolcsóbb nyereség.
Ha a képnek nincs megadva mérete, a böngésző nem tudja, mekkora helyet hagyjon neki, ezért 0 magassággal indul, majd amikor megérkezik a kép, hirtelen lelöki a szöveget lejjebb. A látogató épp olvasna vagy egy gombra kattintana, és elugrik alóla a tartalom. Ez idegesítő, és a mérőszámban is látszik.
A megoldás egyszerű. Az <img> tagre írd rá a kép valódi pixelarányát:
<img src="kep.webp" alt="..." width="1200" height="800">
A CSS-ben pedig hagyd rugalmasnak: img { max-width: 100%; height: auto; }. Így a böngésző a 1200x800 arányból már előre kiszámolja a helyet, a kép a konténerhez igazodik, de az arány stabil marad. Reszponzív, méret nélküli konténernél az aspect-ratio: 3 / 2; CSS-tulajdonság ugyanezt éri el. Ez hivatalos, dokumentált viselkedés, nem trükk.
Mikor használj srcset-et és sizes-t?
Röviden: akkor, ha ugyanaz a kép különböző szélességű képernyőkön jelenik meg, tehát gyakorlatilag majdnem mindig. A srcset több méretben kínálja fel ugyanazt a képet, a böngésző pedig a képernyő és az elrendezés alapján a legkisebb elegendőt tölti le.
Egy tipikus tartalmi kép így néz ki:
<img src="kep-800.webp" srcset="kep-480.webp 480w, kep-800.webp 800w, kep-1200.webp 1200w" sizes="(max-width: 600px) 100vw, 800px" alt="..." width="1200" height="800">
A srcset a w értékekkel megmondja, melyik fájl hány pixel széles. A sizes pedig azt írja le, mekkora helyet foglal el a kép a különböző képernyőkön: itt 600 pixel alatt a teljes szélességet, felette 800 pixelt. Ebből a böngésző kiszámolja, melyik forrás elég, és mobilon nem tölti le a nagy asztali változatot. A legtöbb modern CMS és képkönyvtár ezt automatikusan generálja, de érdemes ellenőrizni, hogy a sizes tényleg a te elrendezésedet írja-e le, mert a rossz sizes feleslegesen nagy képet is behúzhat.
Melyik képre kapcsold be a lazy-loadot, és melyikre ne?
Röviden: a hajtás alatti, görgetéssel elérhető képekre kapcsold be a natív lazy-loadot, de a felül látható fő képre semmiképp, mert az rontja a betöltési élményt. A szabály egyszerűbb, mint amilyennek elsőre tűnik.
A natív lazy-load egyetlen attribútum: loading="lazy". Ettől a böngésző csak akkor tölti le a képet, amikor a látogató közel görget hozzá. Ez a hosszú, sok képes oldalakon jelentősen gyorsítja az első betöltést, mert az induláskor nem versenyeznek egymással a lenti képek a sávszélességért.
A kivétel a legnagyobb, felül látható kép, ami sokszor egyben a Largest Contentful Paint eleme is. Ezt ne késleltesd, sőt fordítva: érdemes lehet fetchpriority="high" jelzéssel előrébb sorolni. A gyakorlati ökölszabály (saját tapasztalat):
- Első képernyőn látható fő kép: nincs lazy-load, esetleg magas prioritás.
- Minden más, lejjebb lévő kép:
loading="lazy".
Így a látogató azonnal látja a lényeget, a többi kép pedig szükség szerint tölt be.
Milyen egy jó alt-szöveg, és miért nem dekoráció a kép?
Röviden: a jó alt-szöveg tömören, konkrétan leírja, mit mutat a kép és milyen szerepet tölt be a tartalomban, nem pedig kulcsszavakat halmoz. A kép így információt hordoz, amit a képernyőolvasó, a képkeresés és az AI-rendszerek is fel tudnak dolgozni.
Az alt-szöveg elsődleges célja az akadálymentesség: aki képernyőolvasót használ, ezt hallja a kép helyett. Ha ez jól sikerül, az egyben segíti a gépi megértést is. Egy termékfotónál a alt="kép" vagy a alt="IMG_2043" semmit nem mond, míg a alt="Kék, kézzel festett kerámia kávéscsésze felülnézetből, tányérral" pontosan leírja a valóságot. Néhány elv:
- Írd le, ami a képen van, úgy, ahogy egy telefonban elmesélnéd valakinek, aki nem látja.
- Kerüld a felesleges bevezetést, tehát ne kezdd azzal, hogy "kép erről" vagy "fotó arról".
- Ne tömd tele kulcsszóval: a mesterséges halmozás rontja az élményt, és nem garantál jobb helyezést.
- Ha a kép tisztán dekoratív (például egy elválasztó minta), üres alt jár neki:
alt="", hogy a képernyőolvasó átugorja.
Itt jön a lényeg, amiért a kép bizonyíték, nem dísz. Egy valódi munkafolyamat-fotó, egy saját mérési képernyőkép, egy előtte-utána összevetés olyasmit közöl, amit a szöveg csak állít. A leíró alt-szöveg és a képaláírás segít abban, hogy ez a bizonyíték a keresők és az AI-válaszmotorok számára is értelmezhető legyen. Ez szakmai feltételezés a jelenlegi rendszerek működése alapján, nem garancia, de a jól címkézett, valódi képek jó eséllyel többet érnek, mint a jellegtelen stockfotók.
Milyen sorrendben álljon neki az ember? Egy rövid ellenőrzőlista
Röviden: méretezés, formátum, méretattribútum, srcset, lazy-load, alt. Ha ezt a sorrendet követed, ritkán marad ki fontos lépés.
- Skálázd a képet a valós megjelenített méretre, ne töltsd fel a nyers, több ezer pixeles fájlt.
- Mentsd WebP-be, és ahol tudod, kínálj AVIF-ot is
<picture>elemmel; logóhoz SVG. - Tömöríts 75-82 közötti minőségre, és nézd meg szemre, nem látszik-e romlás.
- Írd rá a
widthésheightattribútumot, vagy adj CSSaspect-ratioértéket a CLS ellen. - Állíts be
srcsetés helyessizesértéket a reszponzív betöltéshez. - A hajtás alatti képekre tegyél
loading="lazy"attribútumot, a fő képre ne. - Írj minden érdemi képnek leíró alt-szöveget, a dekoratívnak üreset.
Egy CMS-ben ennek nagy részét plugin vagy a beépített képkezelő elvégzi, de az alt-szöveg és a fő kép prioritása szinte mindig kézi döntés marad. Ezen a két ponton múlik a legtöbb, mert ezekhez emberi értékelés kell.
Források és további olvasnivalók
- Google Search Central: Image SEO best practices, valamint a Core Web Vitals (LCP, CLS, INP) dokumentáció
- web.dev: Serve images in modern formats, Optimize CLS, Lazy loading images
- MDN Web Docs (Mozilla): a picture, img, srcset, sizes és a loading attribútum leírása
- W3C WAI: Images Tutorial (az alt-szöveg akadálymentességi irányelvei)
- WebP és AVIF hivatalos formátumdokumentáció, valamint a Can I use böngésző-kompatibilitási adatai
- A modern formátum (WebP, gyakran AVIF) jellemzően 25-50 százalékkal kisebb fájlt ad azonos vizuális minőség mellett.
- A képen a width és height attribútum megadása vagy CSS aspect-ratio megelőzi az elrendezés-ugrálást, ami közvetlenül segíti a CLS mérőszámot.
- A srcset és sizes a látogató képernyőjéhez méretezett képet ad, így mobilon nem tölt le felesleges pixeleket.
- A leíró alt-szöveg egyszerre segíti az akadálymentességet, a képkeresést és az AI-rendszerek megértését: a kép így bizonyíték, nem dísz.
- A hajtás alatti képekre való lazy-load gyorsítja az első betöltést, de a fő (LCP) képre kikapcsolva hagyd.
Gyakori kérdések
Cseréljem le az összes régi JPEG képemet WebP-re?
Nem kötelező egyszerre az egészet. A legnagyobb, legtöbbet betöltő képekkel kezdd, ezekből jön a legnagyobb megtakarítás. A legtöbb CMS a feltöltéskor automatikusan generál WebP változatot, így az új képek már jó formátumban készülnek, a régieket pedig fokozatosan lecserélheted.
Az AVIF mindig jobb, mint a WebP?
Fájlméretben gyakran igen, de nem minden esetben éri meg. Az AVIF lassabban kódolódik, és bár a támogatottsága jó, régebbi eszközökön még akadhat gond. Ezért a biztonságos megoldás a picture elemmel több forrást felkínálni, és a böngészőre bízni a választást, WebP vagy JPEG tartalékkal.
Kell minden képhez alt-szöveg?
Minden érdemi, információt hordozó képhez igen, mert ez az akadálymentesség alapja. A tisztán dekoratív képekhez viszont üres alt jár (alt=""), hogy a képernyőolvasó átugorja őket. A rossz megoldás a teljesen hiányzó alt attribútum vagy a kulcsszavakkal telezsúfolt szöveg.
Miért ugrál betöltéskor a tartalom a képek miatt?
Mert a böngésző nem tudja előre, mekkora helyet hagyjon a képnek. Ha megadod az img tagen a width és height attribútumot, vagy CSS-ben az aspect-ratio értéket, a böngésző már betöltés előtt lefoglalja a helyet, és nem löki lejjebb a szöveget. Ez közvetlenül javítja a CLS mérőszámot.
A lazy-load lassítja vagy gyorsítja az oldalt?
A hajtás alatti képeknél gyorsítja, mert azok csak akkor töltődnek, amikor a látogató közel görget hozzájuk. A felül látható fő képnél viszont rontja az élményt, ezért arra ne tegyél lazy-loadot. A gyakorlati szabály: felül lévő fő kép késleltetés nélkül, minden más loading="lazy" attribútummal.
Segít a képoptimalizálás a keresési helyezésben?
A képoptimalizálás elsősorban a sebességet, a mobilélményt és az akadálymentességet javítja, és ezek közvetve segíthetik a láthatóságot. A modern formátum és a stabil betöltés jó eséllyel jobb felhasználói élményt ad, a leíró alt-szöveg pedig segíti a képkeresést. Konkrét helyezést azonban egyik lépés sem garantál.
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.