Bilder och laddningstid: format, storlekar, lazy loading

Varför bilderna avgör laddningstiden

Google skriver att bilder ofta är det som bidrar mest till sidans totala storlek, vilket kan göra sidor långsamma och dyra att ladda. Två av Core Web Vitals beror direkt på bilder. Largest Contentful Paint (LCP) mäter laddningen: Google råder att det största elementet ska visas inom de första 2,5 sekunderna efter att sidan har börjat laddas. På många sidor är det elementet en bild, till exempel ett stort foto högst upp. Cumulative Layout Shift (CLS) mäter den visuella stabiliteten och bör ligga under 0,1. Bilder som kommer utan reserverat utrymme trycker ned texten och höjer det värdet.

Rätt format

• Foton: JPEG fungerar överallt. WebP och AVIF är ofta klart mindre vid liknande kvalitet.
• Grafik med skarpa kanter eller transparens: PNG, eller WebP och AVIF, som också kan vara transparenta.
• Logotyper och ikoner: SVG, eftersom det förblir skarpt i alla storlekar och oftast är mycket litet.
• Google Sök stöder bilder i src-attributet i formaten BMP, GIF, JPEG, PNG, WebP, SVG och AVIF.

Om du erbjuder WebP eller AVIF kan du behålla en JPEG som reserv i ett picture-element. Webbläsaren väljer den första källa som den förstår.

Rätt storlek

En bild som är 2 400 pixlar bred men visas med 600 pixlar slösar bort de flesta av sina byte. Exportera bilder med ungefär den bredd som de visas i, och för skarpa skärmar med ungefär dubbla bredden. Komprimera dem sedan. I många bildprogram räcker en kvalitetsinställning kring mitten av skalan för foton på webben. Kontrollera resultatet i full storlek innan du ersätter originalet.

srcset och sizes

En enda fil passar aldrig alla skärmar. Med srcset erbjuder du flera filer av samma bild och anger bredden på varje fil. Med sizes talar du om för webbläsaren hur bred bilden kommer att visas. Webbläsaren väljer då den minsta fil som är tillräckligt skarp.

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

I det här exemplet fyller bilden skärmen på smala skärmar och är 700 pixlar bred på bredare. Google rekommenderar att du alltid behåller en reserv i src-attributet. Skriv en riktig alternativtext i stället för de tre punkterna.

Width och height mot layoutförskjutningar

Utan width och height vet webbläsaren inte hur mycket utrymme en bild behöver förrän filen kommer. Texten under hoppar då nedåt. Guiden från web.dev om layoutförskjutningar råder: ange alltid attributen width och height på bilder och videoelement, med filens storlek i pixlar eller åtminstone rätt bildförhållande. Moderna webbläsare sätter bildens standardbildförhållande utifrån dessa värden och reserverar utrymmet. I CSS håller width: 100% och height: auto bilden flexibel. Om du inte kan sätta attributen nämner guiden CSS-egenskapen aspect-ratio som alternativ.

Lazy loading

Med loading="lazy" laddar webbläsaren en bild först när den kommer nära det synliga området. Det sparar data för bilder längre ned på sidan. Google säger om lazy loading: lägg inte till det på innehåll som sannolikt syns direkt när en användare öppnar en sida. Webbläsarens inbyggda lazy loading finns för bilder och iframes.

LCP-bilden

Den största bilden högst upp, ofta en hero-bild eller produktens huvudfoto, är sidans viktigaste fil. Guiden från web.dev om LCP säger: använd aldrig lazy loading på din LCP-bild. fetchpriority="high" är en ledtråd till webbläsaren att ladda den tidigt. Enligt guiden hjälper hög prioritet på fler än en eller två bilder inte längre. Bilder vars adress ett skriptbibliotek gömmer i data-src, eller som bara är en CSS-bakgrund, hittar webbläsaren sent. För en bakgrundsbild nämner guiden en förladdning med link rel="preload" i HTML-koden. AVIF eller WebP och en mindre fil förkortar också laddningstiden.

För att se hur dina sidor presterar hänvisar Google till rapporten Core Web Vitals i Search Console. För en enskild sida visar webbläsarens prestandaverktyg vilket element som är LCP-elementet och vilka element som förskjuter layouten. Mät före och efter en ändring, så att du vet om den hjälpte.

En kort checklista

• Laddas den största bilden högst upp normalt, inte med lazy loading?
• Har varje img width och height, eller är utrymmet reserverat med aspect-ratio?
• Är varje fil ungefär lika bred som den visas, och komprimerad?
• Finns stora foton i flera bredder med srcset och sizes?
• Finns det JPEG- eller PNG-filer som skulle kunna vara WebP eller AVIF?

Arbeta med Do4U

Bildkontroll läser en sida och varje bild på den. För varje fil rapporterar den format, filstorlek och pixlar, och från HTML-koden width och height, loading, fetchpriority, srcset och sizes, picture-källor och bakgrundsbilder i style-attribut. Do4U gissar den troliga LCP-bilden utifrån HTML-koden. Den mäter den inte, eftersom det verkliga LCP-elementet avgörs av webbläsaren. Du får en tabell över bilderna med fynden, den totala vikten och en kort sammanfattning. Bilder som JavaScript infogar och bakgrundsbilder från externa CSS-filer ingår inte. Ingen AI används, och kontrollen är gratis, med en daglig gräns.

Do4U hittar tips, du kontrollerar och bestämmer. Bekräfta LCP-elementet med webbläsarens prestandaverktyg innan du ändrar sidan.