Billeder og hastighed: formater, størrelser, lazy loading

Derfor afgør billeder indlæsningstiden

Google skriver, at billeder ofte er den største del af en sides samlede størrelse, hvilket kan gøre sider langsomme og dyre at indlæse. To af Core Web Vitals afhænger direkte af billeder. Largest Contentful Paint (LCP) måler indlæsningen: Google anbefaler, at det største element vises inden for de første 2,5 sekunder, efter at siden begynder at indlæse. På mange sider er dette element et billede, for eksempel et stort foto øverst. Cumulative Layout Shift (CLS) måler den visuelle stabilitet og bør holde sig under 0,1. Billeder, der kommer uden reserveret plads, skubber teksten ned og hæver denne værdi.

Det rigtige format

• Fotos: JPEG virker overalt. WebP og AVIF er ofte tydeligt mindre ved en lignende kvalitet.
• Grafik med skarpe kanter eller gennemsigtighed: PNG eller WebP og AVIF, som også kan være gennemsigtige.
• Logoer og ikoner: SVG, fordi det forbliver skarpt i alle størrelser og som regel er meget lille.
• Google Søgning understøtter billeder i src-attributten i formaterne BMP, GIF, JPEG, PNG, WebP, SVG og AVIF.

Hvis du tilbyder WebP eller AVIF, kan du beholde en JPEG som reserve i et picture-element. Browseren vælger den første kilde, den forstår.

Den rigtige størrelse

Et billede, der er 2400 pixel bredt, men vises i 600 pixel, spilder de fleste af sine bytes. Eksportér billeder i omtrent den bredde, de vises i, og til skarpe skærme i omtrent den dobbelte bredde. Komprimér dem derefter. I mange billedprogrammer er en kvalitetsindstilling omkring midten af skalaen nok til fotos på nettet. Tjek resultatet i fuld størrelse, før du erstatter originalen.

srcset og sizes

Én fil passer aldrig til alle skærme. Med srcset tilbyder du flere filer af det samme billede og angiver bredden på hver fil. Med sizes fortæller du browseren, hvor bredt billedet vises. Browseren vælger så den mindste fil, der er skarp nok.

<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 dette eksempel fylder billedet skærmen på smalle skærme og er 700 pixel bredt på bredere skærme. Google anbefaler altid at beholde en reserve i src-attributten. Skriv en rigtig alt-tekst i stedet for de tre prikker.

width og height mod layoutskift

Uden width og height ved browseren ikke, hvor meget plads et billede skal bruge, før filen kommer. Teksten under det hopper så ned. Guiden om layoutskift på web.dev anbefaler: Angiv altid width- og height-attributter på billeder og videoelementer med filens størrelse i pixel eller i det mindste det korrekte billedformat. Moderne browsere sætter billedets standardformat ud fra disse værdier og reserverer pladsen. I CSS holder width: 100% og height: auto billedet fleksibelt. Hvis du ikke kan angive attributterne, nævner guiden CSS-egenskaben aspect-ratio som alternativ.

Lazy loading

Med loading="lazy" indlæser browseren først et billede, når det kommer tæt på det synlige område. Det sparer data for billeder længere nede på siden. Google siger om lazy loading: Tilføj det ikke til indhold, der sandsynligvis er synligt med det samme, når en bruger åbner en side. Browserens indbyggede lazy loading findes til billeder og iframes.

LCP-billedet

Det største billede øverst, ofte et heltebillede eller det vigtigste produktfoto, er sidens vigtigste fil. Guiden om LCP på web.dev siger: Brug aldrig lazy loading på dit LCP-billede. fetchpriority="high" er et hint til browseren om at indlæse det tidligt. Ifølge guiden hjælper en høj prioritet på mere end et eller to billeder ikke længere. Billeder, hvis adresse et scriptbibliotek gemmer i data-src, eller som kun er en CSS-baggrund, finder browseren sent. Til et baggrundsbillede nævner guiden en preload med link rel="preload" i HTML'en. AVIF eller WebP og en mindre fil forkorter også indlæsningstiden.

For at se, hvordan dine sider klarer sig, henviser Google til rapporten Core Web Vitals i Search Console. For en enkelt side viser browserens værktøjer til ydeevne, hvilket element der er LCP-elementet, og hvilke elementer der flytter layoutet. Mål før og efter en ændring, så du ved, om den hjalp.

En kort tjekliste

• Indlæses det største billede øverst normalt og ikke med lazy loading?
• Har hvert img width og height, eller er pladsen reserveret med aspect-ratio?
• Er hver fil omtrent lige så bred, som den vises, og komprimeret?
• Kommer store fotos i flere bredder med srcset og sizes?
• Er der JPEG- eller PNG-filer, der kunne være WebP eller AVIF?

Arbejd med Do4U

Billedtjek læser én side og hvert billede på den. For hver fil angiver det formatet, filstørrelsen og pixelmålene og fra HTML'en width og height, loading, fetchpriority, srcset og sizes, picture-kilder og baggrundsbilleder i style-attributter. Do4U gætter det sandsynlige LCP-billede ud fra HTML'en. Det måler det ikke, fordi det rigtige LCP-element afgøres af browseren. Du får en tabel over billederne med fundene, den samlede vægt og en kort opsummering. Billeder, som JavaScript indsætter, og baggrundsbilleder fra eksterne CSS-filer er ikke med. Der bruges ingen AI, og tjekket er gratis med en daglig grænse.

Do4U finder hints, du tjekker og beslutter. Bekræft LCP-elementet med browserens værktøjer til ydeevne, før du ændrer siden.