Afbeeldingen en laadsnelheid: formaten, maten, lazy loading

Waarom afbeeldingen de laadtijd bepalen

Google schrijft dat afbeeldingen vaak het meest bijdragen aan de totale paginagrootte, waardoor pagina's traag en duur kunnen zijn om te laden. Twee van de Core Web Vitals hangen direct van afbeeldingen af. Largest Contentful Paint (LCP) meet het laden: Google adviseert dat het grootste element binnen de eerste 2,5 seconden nadat de pagina begint te laden verschijnt. Op veel pagina's is dat element een afbeelding, bijvoorbeeld een grote foto bovenaan. Cumulative Layout Shift (CLS) meet de visuele stabiliteit en moet onder 0,1 blijven. Afbeeldingen die binnenkomen zonder gereserveerde ruimte duwen de tekst omlaag en verhogen deze waarde.

Het juiste formaat

• Foto's: JPEG werkt overal. WebP en AVIF zijn vaak duidelijk kleiner bij een vergelijkbare kwaliteit.
• Afbeeldingen met scherpe randen of transparantie: PNG, of WebP en AVIF, die ook transparant kunnen zijn.
• Logo's en iconen: SVG, omdat het op elke grootte scherp blijft en meestal heel klein is.
• Google Zoeken ondersteunt afbeeldingen in het src-attribuut in de formaten BMP, GIF, JPEG, PNG, WebP, SVG en AVIF.

Bied je WebP of AVIF aan, dan kun je een JPEG als terugval houden in een picture-element. De browser kiest de eerste bron die hij begrijpt.

De juiste maat

Een afbeelding die 2400 pixels breed is maar op 600 pixels wordt getoond, verspilt het grootste deel van haar bytes. Exporteer afbeeldingen op ongeveer de breedte waarop ze worden getoond, en voor scherpe schermen op ongeveer twee keer die breedte. Comprimeer ze daarna. In veel beeldprogramma's is een kwaliteitsinstelling rond het midden van de schaal genoeg voor foto's op het web. Bekijk het resultaat op volle grootte voordat je het origineel vervangt.

srcset en sizes

Eén bestand past nooit op elk scherm. Met srcset bied je meerdere bestanden van dezelfde afbeelding aan en geef je de breedte van elk bestand op. Met sizes vertel je de browser hoe breed de afbeelding wordt getoond. De browser kiest dan het kleinste bestand dat scherp genoeg is.

<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="…">

In dit voorbeeld vult de afbeelding op smalle schermen het hele scherm en is ze op bredere schermen 700 pixels breed. Google raadt aan altijd een terugval in het src-attribuut te houden. Schrijf een echte alt-tekst in plaats van de drie puntjes.

Width en height tegen verschuivingen in de lay-out

Zonder width en height weet de browser pas hoeveel ruimte een afbeelding nodig heeft als het bestand binnenkomt. De tekst eronder springt dan omlaag. De gids van web.dev over lay-outverschuivingen adviseert: geef afbeeldingen en video-elementen altijd width- en height-attributen, met de pixelgrootte van het bestand of ten minste de juiste beeldverhouding. Moderne browsers bepalen de standaardbeeldverhouding van een afbeelding uit deze waarden en reserveren de ruimte. In de CSS houden width: 100% en height: auto de afbeelding flexibel. Kun je de attributen niet zetten, dan noemt de gids de CSS-eigenschap aspect-ratio als alternatief.

Lazy loading

Met loading="lazy" laadt de browser een afbeelding pas als die dicht bij het zichtbare gebied komt. Dat bespaart data voor afbeeldingen verder op de pagina. Google zegt over lazy loading: voeg het niet toe aan content die waarschijnlijk direct zichtbaar is als een gebruiker een pagina opent. De ingebouwde lazy loading van de browser is beschikbaar voor afbeeldingen en iframes.

De LCP-afbeelding

De grootste afbeelding bovenaan, vaak een hero-afbeelding of de hoofdfoto van het product, is het belangrijkste bestand van de pagina. De gids van web.dev over LCP zegt: laad je LCP-afbeelding nooit lazy. fetchpriority="high" is een hint aan de browser om haar vroeg te laden. Volgens de gids helpt een hoge prioriteit op meer dan een of twee afbeeldingen niet meer. Afbeeldingen waarvan een scriptbibliotheek het adres in data-src verbergt, of die alleen een CSS-achtergrond zijn, vindt de browser laat. Voor een achtergrondafbeelding noemt de gids een preload met link rel="preload" in de HTML. AVIF of WebP en een kleiner bestand verkorten de laadtijd ook.

Om te zien hoe je pagina's presteren, verwijst Google naar het rapport Core Web Vitals in Search Console. Voor één pagina tonen de prestatietools van je browser welk element het LCP-element is en welke elementen de lay-out verschuiven. Meet voor en na een wijziging, zodat je weet of die heeft geholpen.

Een korte checklist

• Wordt de grootste afbeelding bovenaan normaal geladen, niet lazy?
• Heeft elke img width en height, of is de ruimte gereserveerd met aspect-ratio?
• Is elk bestand ongeveer zo breed als het wordt getoond, en gecomprimeerd?
• Komen grote foto's in meerdere breedtes met srcset en sizes?
• Zijn er JPEG- of PNG-bestanden die WebP of AVIF zouden kunnen zijn?

Werken met Do4U

De Afbeeldingcontrole leest één pagina en elke afbeelding daarop. Voor elk bestand meldt hij het formaat, de bestandsgrootte en de pixels, en uit de HTML width en height, loading, fetchpriority, srcset en sizes, picture-bronnen en achtergrondafbeeldingen in style-attributen. Do4U schat de waarschijnlijke LCP-afbeelding in op basis van de HTML. Het meet die niet, want het echte LCP-element bepaalt de browser. Je krijgt een tabel van de afbeeldingen met de bevindingen, het totale gewicht en een korte samenvatting. Afbeeldingen die JavaScript invoegt en achtergrondafbeeldingen uit externe CSS-bestanden zijn niet meegenomen. Er wordt geen AI gebruikt, en de controle is gratis, met een daglimiet.

Do4U vindt aanwijzingen, jij controleert en beslist. Bevestig het LCP-element met de prestatietools van je browser voordat je de pagina wijzigt.