Bilder gir nettsider karakter og gjør det mulig å vise produkter, mennesker og prosjekter på en måte tekst alene ikke kan. Samtidig er de ofte blant de tyngste ressursene på siden.

God bildebruk handler derfor om mer enn komprimering. Nettleseren bør få riktig bilde, i riktig størrelse og til riktig tidspunkt.

Visningsstørrelse og filstørrelse er ikke det samme

Et bilde som vises 800 piksler bredt, trenger sjelden en original på 5000 piksler hos alle brukere.

Responsive bilder lar nettleseren velge mellom flere filer. Med attributtene srcset og sizes kan den hente en variant som passer bedre til skjermbredde og pikseltetthet. MDN anbefaler denne tilnærmingen for å unngå å laste større bilder enn situasjonen krever.

Resultatet kan se likt ut på skjermen, men datamengden og lastetiden blir lavere.

Hovedbildet trenger en annen strategi

Bildet øverst på siden kan bli elementet som måles som Largest Contentful Paint, LCP, i Core Web Vitals.

Google anbefaler derfor å unngå utsatt lasting, eller lazy loading, på bilder som sannsynligvis blir LCP-elementet. Hvis hovedbildet oppdages sent, oppleves siden som tregere selv om selve bildefilen ikke er spesielt stor.

For kritiske bilder kan nettleseren også få et prioritetssignal gjennom fetchpriority. Bildene bør derfor ikke lastes etter én felles regel.

Utsatt lasting passer lenger ned på siden

Bilder under første skjermbilde trenger ofte ikke å lastes med én gang. Da kan lazy loading spare båndbredde og redusere konkurransen om nettverket ved første innlasting.

Den samme teknikken kan derimot forsinke innholdet brukeren ser først. Lastestrategien bør derfor følge bildets rolle på siden, ikke være en standardinnstilling for alt.

Oppgi bredde og høyde

Når nettleseren kjenner bildets dimensjoner på forhånd, kan den reservere riktig plass før filen er ferdig lastet.

MDN anbefaler eksplisitte width- og height-attributter. Det reduserer risikoen for at tekst, kort og andre elementer flytter på seg mens siden lastes.

Forskjellen er særlig merkbar på sider med mange produktbilder eller kort. Sluttresultatet kan se identisk ut, mens selve innlastingen oppleves langt roligere.

Filformat alene løser ikke ytelsesproblemet

Moderne formater kan redusere filstørrelsen, og komprimering er viktig. Men web.dev peker på at svak LCP også kan skyldes sen oppdagelse av ressursen, lav prioritet eller forsinket rendering.

Å konvertere alt til WebP er derfor ikke en fullstendig strategi.

Hele kjeden må vurderes: bildets størrelse, når nettleseren oppdager det, hvilken prioritet det får, hvilken variant som velges, og om layouten kjenner dimensjonene på forhånd.

CMS-et bør automatisere de gode valgene

På nettsteder som oppdateres ofte, kan ikke hver redaktør forventes å kjenne detaljene i srcset, LCP og nettleserens lastelogikk.

Et godt publiseringssystem kan generere flere bildestørrelser automatisk og la frontenden velge riktig variant for hovedbilde, kort, galleri og mobilvisning.

Da blir ytelse en del av systemet i stedet for en huskeregel for den som publiserer.

Design og teknikk må planlegges sammen

Bildeoptimalisering er ikke bare et utviklerspørsmål. Utsnitt, sideforhold og motivplassering avgjør hvor godt bildet kan tilpasses ulike skjermer.

Et motiv med viktig innhold helt ute i kanten kan for eksempel fungere dårlig på mobil. Et bilde som bare tåler 16:9-format, kan være vanskelig å bruke i kvadratiske kort.

Derfor bør designfasen ta høyde for flere bruksflater, som hovedbilde, kort, mobil og miniatyr.

Målet er ikke minst mulig fil. Målet er riktig bildekvalitet for situasjonen, levert uten mer data og ventetid enn nødvendig.