Képek és oldalsebesség: formátumok, méretek, lazy loading

Miért a képek döntik el a betöltési időt

A Google azt írja, hogy a képek gyakran a legnagyobb mértékben járulnak hozzá a teljes oldalmérethez, ami lassúvá és drágává teheti az oldalak betöltését. A Core Web Vitals mutatói közül kettő közvetlenül a képektől függ. A Largest Contentful Paint (LCP) a betöltést méri: a Google azt tanácsolja, hogy a legnagyobb elem az oldal betöltésének kezdetétől számított első 2,5 másodpercen belül jelenjen meg. Sok oldalon ez az elem egy kép, például egy nagy fotó felül. A Cumulative Layout Shift (CLS) a vizuális stabilitást méri, és 0,1 alatt kell maradnia. A lefoglalt hely nélkül érkező képek lejjebb tolják a szöveget, és növelik ezt az értéket.

A helyes formátum

• Fotók: a JPEG mindenhol működik. A WebP és az AVIF hasonló minőség mellett gyakran jóval kisebb.
• Éles szélű vagy átlátszó grafikák: PNG, vagy WebP és AVIF, amelyek szintén lehetnek átlátszók.
• Logók és ikonok: SVG, mert minden méretben éles marad, és általában nagyon kicsi.
• A Google Kereső a src attribútumban a BMP, GIF, JPEG, PNG, WebP, SVG és AVIF formátumú képeket támogatja.

Ha WebP vagy AVIF formátumot kínálsz, egy picture elemben megtarthatsz tartalékként egy JPEG-et. A böngésző az első olyan forrást választja, amelyet ismer.

A helyes méret

Egy 2400 pixel széles kép, amely 600 pixel szélesen jelenik meg, a bájtjai nagy részét elpazarolja. A képeket nagyjából abban a szélességben exportáld, amelyben megjelennek, éles kijelzőkhöz pedig nagyjából a dupláján. Utána tömörítsd őket. Sok képszerkesztő programban a skála közepe körüli minőségi beállítás elég a webes fotókhoz. Mielőtt lecserélnéd az eredetit, nézd meg az eredményt teljes méretben.

srcset és sizes

Egyetlen fájl soha nem illik minden képernyőhöz. A srcset segítségével ugyanannak a képnek több fájlját kínálod fel, és megadod mindegyik szélességét. A sizes segítségével megmondod a böngészőnek, milyen szélesen jelenik meg a kép. A böngésző ezután a legkisebb olyan fájlt választja, amely elég éles.

<img src="/img/sofa-800.jpg"
     srcset="/img/sofa-400.jpg 400w, /img/sofa-800.jpg 800w, /img/sofa-1600.jpg 1600w"
     sizes="(max-width: 700px) 100vw, 700px"
     width="800" height="533"
     alt="…">

Ebben a példában a kép keskeny képernyőn kitölti a képernyőt, szélesebbeken pedig 700 pixel széles. A Google azt javasolja, hogy a src attribútumban mindig legyen tartalék. A három pont helyére valódi alternatív szöveget írj.

Width és height az elrendezés elcsúszása ellen

Width és height nélkül a böngésző nem tudja, mennyi helyre van szüksége egy képnek, amíg a fájl meg nem érkezik. Az alatta lévő szöveg ekkor lejjebb ugrik. A web.dev elrendezés-elcsúszásról szóló útmutatója azt tanácsolja: a képeken és videóelemeken mindig add meg a width és a height attribútumot, a fájl pixelméretével vagy legalább a helyes képaránnyal. A modern böngészők ezekből az értékekből állítják be a kép alapértelmezett képarányát, és lefoglalják a helyet. A CSS-ben a width: 100% és a height: auto rugalmasan tartja a képet. Ha nem tudod megadni az attribútumokat, az útmutató alternatívaként az aspect-ratio CSS-tulajdonságot nevezi meg.

Lazy loading

A loading="lazy" beállítással a böngésző csak akkor tölt be egy képet, amikor az a látható terület közelébe ér. Ez adatforgalmat takarít meg az oldal lejjebb lévő képeinél. A Google a lazy loadingról azt mondja: ne használd olyan tartalomnál, amely valószínűleg azonnal látható, amikor a felhasználó megnyit egy oldalt. A böngésző beépített lazy loadingja képekhez és iframe-ekhez érhető el.

Az LCP-kép

A felül lévő legnagyobb kép, gyakran egy hero kép vagy a fő termékfotó, az oldal legfontosabb fájlja. A web.dev LCP-ről szóló útmutatója azt mondja: az LCP-képet soha ne töltsd be lustán. A fetchpriority="high" jelzés a böngészőnek, hogy korán töltse be. Az útmutató szerint egy-két képnél többön a magas prioritás már nem segít. Azokat a képeket, amelyek címét egy szkriptkönyvtár a data-src attribútumba rejti, vagy amelyek csak CSS-háttérként léteznek, a böngésző későn találja meg. Háttérképhez az útmutató a HTML-ben egy link rel="preload" előtöltést nevez meg. Az AVIF vagy a WebP és egy kisebb fájl szintén rövidíti a betöltési időt.

Hogy megnézd, hogyan teljesítenek az oldalaid, a Google a Search Console Core Web Vitals jelentésére utal. Egyetlen oldalnál a böngésződ teljesítményeszközei megmutatják, melyik elem az LCP-elem, és mely elemek csúsztatják el az elrendezést. Mérj a változtatás előtt és után, hogy tudd, segített-e.

Rövid ellenőrzőlista

• A felül lévő legnagyobb kép normálisan töltődik be, nem lustán?
• Minden img elemnek van width és height értéke, vagy aspect-ratio foglalja le a helyet?
• Minden fájl nagyjából olyan széles, amilyen szélesen megjelenik, és tömörítve van?
• A nagy fotók több szélességben, srcset és sizes használatával érkeznek?
• Vannak olyan JPEG- vagy PNG-fájlok, amelyek lehetnének WebP vagy AVIF formátumúak?

Munka a Do4U-val

A Képellenőrzés beolvas egy oldalt és rajta minden képet. Minden fájlnál megadja a formátumot, a fájlméretet és a pixeleket, a HTML-ből pedig a width és height, loading, fetchpriority, srcset és sizes értékeket, a picture forrásait és a style attribútumokban lévő háttérképeket. A Do4U a HTML alapján megbecsüli a valószínű LCP-képet. Nem méri, mert a valódi LCP-elemet a böngésző határozza meg. A képek táblázatát kapod a megállapításokkal, a teljes súllyal és egy rövid összefoglalóval. A JavaScript által beillesztett képek és a külső CSS-fájlokból származó háttérképek nem szerepelnek benne. Nem használ AI-t, és az ellenőrzés ingyenes, napi korláttal.

A Do4U tippeket ad, te ellenőrzöl és döntesz. Mielőtt módosítanád az oldalt, erősítsd meg az LCP-elemet a böngésződ teljesítményeszközeivel.