Bilder og sidehastighet: formater, størrelser, lazy loading

Derfor avgjør bilder lastetiden

Google skriver at bilder ofte er den største delen av en sides samlede størrelse, noe som kan gjøre sider trege og dyre å laste. To av Core Web Vitals avhenger direkte av bilder. Largest Contentful Paint (LCP) måler lastingen: Google anbefaler at det største elementet vises innen de første 2,5 sekundene etter at siden begynner å laste. På mange sider er dette elementet et bilde, for eksempel et stort foto øverst. Cumulative Layout Shift (CLS) måler den visuelle stabiliteten og bør holde seg under 0,1. Bilder som kommer uten reservert plass, skyver teksten ned og øker denne verdien.

Riktig format

• Fotografier: JPEG fungerer overalt. WebP og AVIF er ofte tydelig mindre ved lignende kvalitet.
• Grafikk med skarpe kanter eller gjennomsiktighet: PNG, eller WebP og AVIF, som også kan være gjennomsiktige.
• Logoer og ikoner: SVG, fordi det holder seg skarpt i alle størrelser og som regel er svært lite.
• Google Søk støtter bilder i src-attributtet i formatene BMP, GIF, JPEG, PNG, WebP, SVG og AVIF.

Hvis du tilbyr WebP eller AVIF, kan du beholde en JPEG som reserve i et picture-element. Nettleseren velger den første kilden den forstår.

Riktig størrelse

Et bilde som er 2400 piksler bredt, men vises i 600 piksler, sløser bort de fleste bytene sine. Eksporter bilder i omtrent bredden de vises i, og for skarpe skjermer i omtrent dobbel bredde. Komprimer dem deretter. I mange bildeprogrammer er en kvalitetsinnstilling rundt midten av skalaen nok for fotografier på nett. Sjekk resultatet i full størrelse før du erstatter originalen.

srcset og sizes

Én fil passer aldri til alle skjermer. Med srcset tilbyr du flere filer av det samme bildet og oppgir bredden på hver fil. Med sizes forteller du nettleseren hvor bredt bildet vises. Nettleseren velger da den minste filen som 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 eksempelet fyller bildet skjermen på smale skjermer og er 700 piksler bredt på bredere skjermer. Google anbefaler alltid å beholde en reserve i src-attributtet. Skriv en ekte alt-tekst i stedet for de tre prikkene.

width og height mot layoutforskyvninger

Uten width og height vet ikke nettleseren hvor mye plass et bilde trenger før filen kommer. Teksten under hopper da ned. Veiledningen om layoutforskyvninger på web.dev anbefaler: Ta alltid med width- og height-attributter på bilder og videoelementer, med filens størrelse i piksler eller i det minste riktig sideforhold. Moderne nettlesere setter bildets standard sideforhold ut fra disse verdiene og reserverer plassen. I CSS holder width: 100% og height: auto bildet fleksibelt. Hvis du ikke kan angi attributtene, nevner veiledningen CSS-egenskapen aspect-ratio som alternativ.

Lazy loading

Med loading="lazy" laster nettleseren et bilde først når det kommer nær det synlige området. Det sparer data for bilder lenger ned på siden. Google sier om lazy loading: Ikke legg det til innhold som sannsynligvis er synlig med en gang når en bruker åpner en side. Nettleserens innebygde lazy loading finnes for bilder og iframes.

LCP-bildet

Det største bildet øverst, ofte et toppbilde eller hovedbildet av produktet, er sidens viktigste fil. Veiledningen om LCP på web.dev sier: Bruk aldri lazy loading på LCP-bildet ditt. fetchpriority="high" er et hint til nettleseren om å laste det tidlig. Ifølge veiledningen hjelper høy prioritet på mer enn ett eller to bilder ikke lenger. Bilder der et skriptbibliotek skjuler adressen i data-src, eller som bare er en CSS-bakgrunn, finner nettleseren sent. For et bakgrunnsbilde nevner veiledningen en forhåndslasting med link rel="preload" i HTML-en. AVIF eller WebP og en mindre fil forkorter også lastetiden.

For å se hvordan sidene dine presterer, viser Google til rapporten Core Web Vitals i Search Console. For én enkelt side viser ytelsesverktøyene i nettleseren hvilket element som er LCP-elementet, og hvilke elementer som forskyver layouten. Mål før og etter en endring, slik at du vet om den hjalp.

En kort sjekkliste

• Lastes det største bildet øverst normalt, ikke med lazy loading?
• Har hvert img width og height, eller er plassen reservert med aspect-ratio?
• Er hver fil omtrent like bred som den vises, og komprimert?
• Kommer store fotografier i flere bredder med srcset og sizes?
• Finnes det JPEG- eller PNG-filer som kunne vært WebP eller AVIF?

Arbeid med Do4U

Bildesjekk leser én side og hvert bilde på den. For hver fil oppgir den formatet, filstørrelsen og pikslene, og fra HTML-en width og height, loading, fetchpriority, srcset og sizes, picture-kilder og bakgrunnsbilder i style-attributter. Do4U gjetter det sannsynlige LCP-bildet ut fra HTML-en. Den måler det ikke, fordi det faktiske LCP-elementet avgjøres av nettleseren. Du får en tabell over bildene med funnene, den samlede vekten og et kort sammendrag. Bilder som JavaScript setter inn, og bakgrunnsbilder fra eksterne CSS-filer er ikke med. Det brukes ingen KI, og sjekken er gratis, med en daglig grense.

Do4U finner tips, du sjekker og bestemmer. Bekreft LCP-elementet med ytelsesverktøyene i nettleseren før du endrer siden.