Responsive images: teljes útmutató

A responsive images technika lényege, hogy a böngésző mindig a megjelenítési mérethez és a kijelző pixelsűrűségéhez illő képváltozatot töltse le. Ezt a srcset és sizes attribútumokkal, illetve a picture elemmel éred el. Így mobilon kisebb fájl érkezik, gyorsabb lesz a betöltés, jobb lesz az LCP, és a képkeresőben is rendben marad a minőség.

Alapfogalmak

Mielőtt kódot írsz, tisztázd a szókincset. A responsive images témában a legtöbb félreértés abból fakad, hogy valaki összemossa a CSS-pixelt az eszközpixellel, vagy azt hiszi, hogy a sizes attribútum átméretezi a képet. Egyik sem igaz, és ha ezeket rosszul érted, a kódod szintaktikailag helyes lesz, mégis rossz fájlt tölt le a böngésző.

A reszponzív kép nem egyetlen fájl, hanem változatok családja. Ugyanazt a tartalmat több szélességben (és néha több formátumban vagy kivágásban) állítod elő, a HTML-ben leírod, milyen változatok léteznek, és mekkora helyet foglal majd a kép az oldalon. A választás a böngészőé, nem a tiéd. Ez a szemléletváltás a legfontosabb: te információt adsz, a böngésző dönt.

CSS-pixel és eszközpixel

A CSS-pixel az elrendezés mértékegysége. Egy 390 CSS-pixel széles mobil kijelző fizikailag 1170 pixelt is tartalmazhat, ha a pixelsűrűség (device pixel ratio, DPR) 3. Ha a kép 390 CSS-pixel szélesen jelenik meg, éles megjelenéshez nagyjából 1170 pixel széles fájl kell. Ezért nem elég azt kérdezni, „milyen széles a kép a dizájnban”, hanem azt is, milyen sűrűségű kijelzőn nézik.

Felbontásváltás és art direction

Két különböző problémát old meg a technika:

Felbontásváltás (resolution switching): ugyanaz a kép, ugyanaz a kivágás, csak más pixelméretben. Erre a srcset és sizes való.
Art direction: eltérő kivágás vagy kompozíció a kijelzőtől függően. Például egy széles banner mobilon szűkre vágva, hogy a termék ne vesszen el. Erre a picture elem source elemei valók media feltétellel.
Formátumváltás: modern formátum (AVIF, WebP) felkínálása visszaeséssel JPEG-re. Ez is a picture elemmel megy, type attribútummal.

A legfontosabb attribútumok röviden

Attribútum vagy elem	Mit csinál	Gyakori félreértés
srcset (w leíróval)	Felsorolja a változatokat és azok valódi pixelszélességét	A w érték nem a megjelenítési méret, hanem a fájl szélessége
srcset (x leíróval)	Pixelsűrűséghez rendel változatot (1x, 2x)	Csak fix méretű képhez jó, folyékony elrendezéshez nem
sizes	Megmondja, mekkora helyet foglal a kép CSS-pixelben	Nem méretezi át a képet, csak tájékoztat
picture + source	Feltételes forráscsere (media, type)	A media feltétel kötelező döntés, nem javaslat
width, height	Képarányt ad a layout számára	Nem rögzíti a megjelenítési méretet, ha a CSS felülírja

A témakör a tágabb Kép és videó SEO terület része, ahol a technikai teljesítmény és a kereshetőség egymásra épül. A reszponzív képek elsősorban sebességet és felhasználói élményt javítanak, de közvetve a képkeresési megjelenésre is hatnak, mert a jó minőségű, gyorsan betöltődő kép jobban szolgálja a látogatót.

Mit nem old meg a reszponzív kép

Nem pótolja a leíró alternatív szöveget, a jó fájlnevet vagy a megfelelő tömörítést. Ha a legkisebb változatod is 400 kB-os, mert tömörítetlen PNG, a srcset nem ment meg. A responsive images a szállítási rétegre vonatkozik, a tartalmi optimalizálás külön feladat.

Hogyan működik?

A böngésző a HTML feldolgozásakor, még a CSS letöltése előtt elkezdi keresni a letöltendő erőforrásokat. Ez a preload scanner. Ebben a pillanatban még nem tudja, milyen széles lesz a képed, mert az elrendezés nincs kiszámolva. Pontosan ezért létezik a sizes attribútum: a HTML-ben előre megmondod neki, mekkora lesz a kép, hogy ne kelljen a layoutra várnia.

Ha ezt megérted, minden más logikus lesz. A böngésző három adatból számol: a sizes által megadott szélességből, a kijelző pixelsűrűségéből és a srcset-ben felsorolt változatokból.

A kiválasztás lépései

A böngésző végigmegy a sizes listáján, és az első olyan média feltételt választja, amely teljesül. Ha egyik sem, az utolsó, feltétel nélküli értéket használja.
Az így kapott CSS-szélességet megszorozza a DPR-rel. Ez a szükséges fizikai szélesség.
A srcset w értékeiből kiszámolja, melyik változat fedi le ezt az igényt.
Kiválaszt egy jelöltet. A specifikáció itt mozgásteret hagy: a böngésző figyelembe vehet gyorsítótárat, adatforgalom-takarékos módot vagy hálózati állapotot.
Letölti a fájlt, és a CSS szerinti méretben jeleníti meg.

Kidolgozott példa

Vegyünk egy blogcikk fő képét. A dizájn szerint 800 CSS-pixel fölötti nézetablaknál a kép 720 CSS-pixel széles, alatta a teljes szélesség, mínusz 32 pixel margó. Előállítasz négy változatot: 480, 800, 1200 és 1600 pixel szélességben.

A HTML (szöveggel leírva, hogy olvasható maradjon): az img elem src attribútuma a 800-as fájlra mutat visszaesésként, a srcset tartalmazza a négy fájlt rendre 480w, 800w, 1200w és 1600w leíróval, a sizes értéke pedig „(min-width: 800px) 720px, calc(100vw - 32px)”. Mellé width="1600" és height="900", hogy a képarány ismert legyen.

Nézzük, mi történik (szemléltető számítás):

Eszköz	Nézetablak	DPR	sizes eredménye	Szükséges szélesség	Várható változat
Kis mobil	360 px	2	328 px	656 px	800w
Nagy mobil	430 px	3	398 px	1194 px	1200w
Tablet álló	768 px	2	736 px	1472 px	1600w
Laptop	1366 px	1	720 px	720 px	800w
Retina laptop	1440 px	2	720 px	1440 px	1600w

Figyeld meg: a laptop kapja a kisebb fájlt, mint a nagy mobil. Ez nem hiba, hanem a rendszer célja. A pixelsűrűség legalább annyit számít, mint a képernyő mérete.

Mi történik a picture elemmel

A picture elemnél a böngésző a source elemeket sorban vizsgálja. Az első olyan source nyer, amelynek media feltétele teljesül és type formátumát támogatja. Ha egyik sem, az img elem srcset vagy src értékét használja. Az img elem mindig kötelező, mert ő jelenik meg ténylegesen; a source csak a fájlforrást cseréli. Ezért az alt szöveget, a width és height attribútumot és a lazy loadingot is az img elemre teszed.

Határeset: átméretezett ablak

Ha a felhasználó asztali gépen kisebbre veszi, majd nagyobbra húzza az ablakot, a böngésző letölthet nagyobb változatot. Visszafelé jellemzően nem tölt le kisebbet, ha a nagyobb már a gyorsítótárban van, mert az felesleges forgalom lenne. Ezért teszteléskor mindig friss lapon, tiszta gyorsítótárral nézd, melyik fájl érkezik.

Fő módszerek

Négy fő megoldás közül választasz, és a legtöbb weboldalon ezek kombinációja kell. A döntést ne ízlésre bízd, hanem arra, hogy mit változtat a kép a különböző kijelzőkön: csak a méretet, a kivágást vagy a formátumot.

1. srcset x leíróval fix méretű képhez

Logóknál, ikonoknál, avatároknál, ahol a kép minden kijelzőn ugyanakkora CSS-méretű, elég az x leíró. Egy 48 pixeles avatarhoz 48, 96 és 144 pixeles fájlt adsz 1x, 2x, 3x jelöléssel. Nincs szükség sizes attribútumra. Egyszerű, és nem tudod elrontani a méretszámítást.

2. srcset w leíróval és sizes attribútummal

Ez a leggyakoribb eset: tartalmi képek, termékfotók, hero képek, amelyek szélessége a nézetablakkal együtt változik. A sizes értékét a valódi CSS-ből vezeted le, nem becslésből. Ha a rácsod 1200 pixel fölött három oszlopos, 768 és 1200 között kettő, alatta egy, akkor a sizes is három ágat kap.

3. picture elem art directionre

Akkor használd, ha a kép tartalma nem működik minden képarányban. Egy 3:1-es asztali bannernél mobilon apró lesz a szereplő; ilyenkor egy 4:5 arányú, szorosabb kivágást adsz meg külön source-ban, media feltétellel. Fontos: ilyenkor a source elemre is tehetsz width és height attribútumot, hogy a böngésző a helyes képaránnyal foglalja le a helyet.

4. picture elem formátumváltásra

Modern formátumot kínálsz fel a type attribútummal, például először AVIF, aztán WebP, végül az img-ben JPEG. A formátumokról bővebben a WebP: teljes útmutató ír. Ha a szervered vagy CDN-ed tartalomegyeztetéssel (Accept fejléc alapján) maga szolgálja ki a jobb formátumot, a picture formátumváltás elhagyható, és egyszerűbb marad a HTML.

Döntési szabály

Ezt a sorrendet követheted minden új képtípusnál:

Változik a kép CSS-mérete a nézetablakkal? Ha nem, x leíró. Ha igen, menj tovább.
Működik ugyanaz a kivágás mobilon is? Ha igen, w leíró és sizes. Ha nem, picture media feltétellel.
Kiszolgálja a szerver automatikusan a modern formátumot? Ha igen, kész. Ha nem, picture type attribútummal.
Az oldal tetején, első képernyőn látszik? Ha igen, ne legyen lazy, és fontold meg a fetchpriority="high" értéket. Ha nem, loading="lazy".

Hány változatot készíts

Nincs egyetlen helyes szám. Gyakorlati irányelv: a lépések között akkora legyen a különbség, hogy érdemi bájtmegtakarítást hozzon, de ne annyi, hogy egy eszköz feleslegesen dupla méretet kapjon. Tartalmi képnél 4-6 változat (például 400, 640, 960, 1280, 1600, 2000 pixel) a legtöbb elrendezést lefedi. Ennél több változat a build idejét és a tárhelyet növeli, a nyereség pedig csökken. Saját oldaladon érdemes megnézni, hogy a fájlméretek között legalább 20-30 százalék különbség legyen; ez szemléltető ökölszabály, nem szabvány.

Képszolgáltatás automatizálása

Kézzel senki nem állít elő hat változatot minden képből. Használj build lépést, a CMS beépített képméretezőjét vagy képkiszolgáló CDN-t, amely URL-paraméter alapján generál méretet. Bármelyiket választod, ellenőrizd, hogy a generált srcset valóban létező fájlokra mutat, és a w értékek egyeznek a fájlok tényleges szélességével.

Gyakori hibák

A reszponzív képek alattomos tulajdonsága, hogy a hibás beállítás is „működik”: megjelenik a kép, semmi nem törik el. Csak éppen rossz fájl jön le. Ezért kell tudatosan keresni a hibákat.

Hiányzó vagy alapértelmezett sizes

Ha w leírót használsz, de sizes nélkül, a böngésző 100vw-t feltételez. Egy kétoszlopos rácsban, ahol a kép valójában a képernyő fele, ez kétszeres szélességű, nagyjából négyszeres pixelszámú fájlt jelenthet. Ez a leggyakoribb és legdrágább hiba.

A sizes nem követi a CSS-t

Valaki egyszer beírta, hogy „(max-width: 600px) 100vw, 50vw”, aztán a dizájn megváltozott, a sizes nem. Ez a hiba hónapokig rejtve marad. Megoldás: a sizes értékét a komponens mellett tartsd, ugyanott, ahol a rács töréspontjait.

Hamis w értékek

A srcset-ben 1200w szerepel, de a fájl valójában 1000 pixel széles, mert a feltöltött eredeti kisebb volt, és a rendszer nem nagyított. A böngésző rossz számításból dolgozik. Ellenőrizd, hogy a generátor nem hirdet olyan méretet, amelyet nem tudott előállítani.

Lazy loading a hero képen

Az első képernyőn látható fő képre tett loading="lazy" késlelteti a letöltést, ami ronthatja a Largest Contentful Paint értéket. A hero kép legyen azonnal betöltődő, a hajtás alattiak legyenek lazy betöltésűek.

Hiányzó width és height

Méretek nélkül a böngésző nem tud helyet foglalni, és a kép betöltésekor elcsúszik a tartalom. Ez rontja a Cumulative Layout Shift értéket. Add meg a valódi képarányt, a CSS-ben pedig legyen width: 100% és height: auto.

Gyakori tévhitek

„A sizes átméretezi a képet.” Nem. A megjelenítési méretet a CSS adja. A sizes csak a letöltési döntéshez kell.
„A böngésző mindig a legkisebb elégséges változatot választja.” Nem garantált. A specifikáció a választást a böngészőre bízza.
„A picture jobb, mint a srcset.” Más a feladatuk. Art direction nélkül a picture csak bonyolítja a kódot.
„A Google a legkisebb változatot indexeli.” Erre nincs megbízható általános szabály, ezért az src visszaesési értéke legyen jó minőségű, közepes vagy nagy méretű változat, ne apró bélyegkép.

Ellenpélda: túlbuzgó optimalizálás

Egy webshop minden termékképhez tíz változatot generált 100 pixeles lépésekben, és mindegyiket picture elembe csomagolta három formátummal. A HTML képenként harminc forrást tartalmazott, a terméklista oldal mérete jelentősen nőtt, a gyorsítótár-találati arány pedig romlott, mert túl sok különböző fájl létezett. (Szemléltető eset.) A tanulság: kevesebb, jól elosztott változat gyakran jobban teljesít.

Képkeresési oldalhatások

Ha az art direction miatt mobilon csak egy szűk kivágás érkezik, győződj meg róla, hogy a képkeresőnek szánt fő változat elérhető marad. Az alternatív szöveg az img elemen legyen, ne hiányozzon; ennek megírásához az Alt text: teljes útmutató ad részletes szempontokat.

Mérés

Amit nem mérsz, abban csak reménykedsz. A reszponzív képek hatását három szinten nézd: melyik fájl jön le valójában, mennyi a megtakarítás, és hogyan változnak a felhasználói metrikák.

Böngészős ellenőrzés lépésről lépésre

Nyisd meg a fejlesztői eszközöket, a Network fület, és szűrj a képekre.
Kapcsold ki a gyorsítótárat, és válassz eszközemulációt adott DPR-rel.
Töltsd újra az oldalt, és nézd meg a letöltött fájl nevét és méretét.
Az Elements panelen vidd az egeret az img fölé: a böngésző megmutatja a megjelenített és a természetes méretet.
Ha a természetes szélesség jóval nagyobb, mint a megjelenített szélesség szorozva a DPR-rel, túl nagy fájl érkezik. Ha kisebb, elmosódott lesz a kép.
Ismételd három nézetablakkal: kis mobil, tablet, asztali.

Laboradatok

A Lighthouse és a PageSpeed Insights jelezheti, ha egy kép jelentősen nagyobb a szükségesnél, vagy ha modern formátummal megtakarítás érhető el. Ezeket a jelzéseket kiindulópontnak vedd, ne végső ítéletnek: a laborteszt egyetlen eszközprofilt szimulál.

Terepadatok

A valódi felhasználók élményét a Core Web Vitals terepadatai mutatják, például a Search Console vonatkozó jelentésében vagy a Chrome felhasználói adatain alapuló eszközökben. Az LCP elemre figyelj különösen: ha az oldalaid nagy részén kép az LCP elem, a reszponzív képek javítása itt fog látszani. Ne felejtsd el, hogy a terepadatok késleltetve frissülnek, így a változás hatását hetek alatt látod.

Mérőtábla saját használatra

Mit nézel	Hol	Jó jel	Rossz jel
Letöltött fájl szélessége	Network fül	Közel a megjelenített × DPR értékhez	Kétszer vagy többször nagyobb
Képbájtok oldalanként	Network összesítő	Mobilon érezhetően kevesebb, mint asztalin	Mobilon és asztalin azonos
LCP	Terepadatok, labor	Javuló trend a változtatás után	Romlás, főleg mobilon
CLS	Terepadatok, labor	Képeknél nincs elcsúszás	Képbetöltéskor ugrik a tartalom
Képi találatok	Search Console, képkeresés szűrő	Stabil vagy növekvő	Hirtelen esés átállás után

Ellenőrzőlista élesítés előtt

Minden w leírós srcset mellett van sizes, és az a CSS-ből származik.
A w értékek a fájlok valódi szélességét jelzik.
Az src visszaesés jó minőségű változat.
Minden img-en van width, height és alt.
A hero kép nem lazy betöltésű.
Art direction esetén minden source-hoz helyes képarány tartozik.
A képek szerepelnek a feltérképezhető forrásokban, szükség esetén az Image sitemap: teljes útmutató szerint.
Három nézetablakon és két DPR-en ellenőrizted a letöltött fájlt.

Előtte-utána összehasonlítás

Mielőtt élesítesz, rögzítsd a kiinduló állapotot: néhány reprezentatív sablon (főoldal, kategória, cikk, termék) képbájtjait mobilon és asztalin, valamint az LCP értéket. Élesítés után ugyanazon a módon mérj újra. Így konkrét, saját adatod lesz arról, mennyit hozott a változtatás, és nem általános ígéretekre hagyatkozol.

Kapcsolódó részletes útmutatók

A reszponzív képek a képoptimalizálás egyik rétegét adják. A teljes eredményhez a tartalmi, formátumbeli és feltérképezési oldalt is rendbe kell tenni. Az alábbi útmutatók ezeket a területeket bontják ki részletesen, és jól kiegészítik az itt leírt technikai lépéseket.

Mit hol érdemes folytatni

Ha a képeid általános keresőoptimalizálásával kezdesz, az átfogó képes útmutató a legjobb belépő. Ha a fájlméret a fő gondod, a formátumokról szóló anyag segít. Ha a kereshetőség és a feltérképezés érdekel, az alternatív szövegről és a képes oldaltérképről szóló útmutatók a következő lépések.

Kép és videó SEO: a teljes témakör áttekintése, innen minden részterület elérhető.
Kép SEO: teljes útmutató: fájlnevek, környező szöveg, strukturált adatok és a képkeresési megjelenés alapjai.
Alt text: teljes útmutató: hogyan írj leíró, akadálymentes alternatív szöveget, és mikor maradjon üres.
Image sitemap: teljes útmutató: mikor és hogyan segíti a képek felfedezését az oldaltérkép.
WebP: teljes útmutató: modern formátumra váltás, visszaesési stratégia és minőségbeállítás.

Javasolt sorrend

Tömörítés és formátum rendbetétele, mert ez minden változat méretét csökkenti.
Reszponzív változatok és helyes sizes értékek bevezetése sablononként.
Alternatív szövegek és környező tartalom átnézése.
Feltérképezhetőség ellenőrzése, szükség esetén képes oldaltérképpel.
Mérés előtte és utána, majd a leggyengébb sablon javítása.

Ezzel a sorrenddel elkerülöd, hogy kétszer kelljen ugyanazokat a képváltozatokat legenerálnod, és minden lépés hatását külön is látni fogod a mérésekben.