Slik komprimerer du bilder til nettsiden uten kvalitetstap

Du komprimerer bilder riktig ved først å skalere dem ned til omtrent dobbel visningsbredde, deretter lagre dem som WebP eller AVIF med tapsbasert kvalitet rundt 75–80, og til slutt fjerne metadata. Toppbildet skal ikke lastes utsatt. Gjort i denne rekkefølgen blir filene ofte mange ganger mindre uten at forskjellen synes.

Hvor små bør bildene på nettsiden være?

Vår tommelfingerregel er under 200 KB for et toppbilde i full bredde og under 100 KB for vanlige innholdsbilder. Pikselbredden bør være omtrent det dobbelte av bredden bildet faktisk vises i. Et bilde rett fra mobilen eller speilrefleksen er gjerne 3–8 MB og 4000–6000 piksler bredt, altså mange ganger mer enn noen skjerm trenger.

Grensen som betyr noe for Google, er tid og ikke kilobyte. Ifølge Googles dokumentasjon om Largest Contentful Paint bør det største synlige elementet på siden lastes innen 2,5 sekunder. Alt over 4 sekunder regnes som dårlig. Målingen gjøres på den 75. persentilen av ekte besøk, så siden må være rask for tre av fire besøkende og ikke bare på kontorets fibernett. På de fleste bedriftssider er det største elementet toppbildet. Derfor er bildene som regel det billigste stedet å hente fart.

Regn ut riktig pikselbredde

• Toppbilde i full bredde: 1920–2400 piksler bredt holder for nesten alle skjermer.
• Bilde i innholdskolonnen (typisk 700–800 piksler visningsbredde): 1400–1600 piksler.
• Kort, miniatyrer og ansattbilder: 600–800 piksler.
• Logoer og ikoner: bruk SVG og ikke punktgrafikk. Se også guiden vår om å lage logo.

Den doble bredden dekker skjermer med høy pikseltetthet, som mobiler og nyere bærbare. Går du over det, blir fila tyngre uten at noen ser forskjell. Bruker siden responsiv webdesign med srcset, lager publiseringsløsningen mindre utgaver automatisk, slik at mobilen henter en liten fil og en stor skjerm henter en større.

Hvilket bildeformat bør du velge?

Bruk WebP som standard for fotografier og AVIF der publiseringsløsningen og serveren støtter det. Bruk SVG for logoer og ikoner. JPEG og PNG trenger du nesten bare som reserve eller originalfil. Ifølge Googles egen WebP-dokumentasjon er WebP med tap 25–34 % mindre enn tilsvarende JPEG ved samme målte kvalitet, og tapsfri WebP er 26 % mindre enn PNG.

Bildeformater for nettsider i 2026

• Format | Passer til | Styrke | Svakhet
• WebP | Fotografier, produktbilder, bilder med gjennomsiktig bakgrunn | 25–34 % mindre enn JPEG, støttes i alle moderne nettlesere | Gevinsten blir mindre hvis fila allerede er hardt komprimert
• AVIF | Fotografier og toppbilder der hver kilobyte teller | Opptil 50 % mindre enn JPEG ifølge WordPress | Krever at serveren støtter formatet, og koding går tregere
• JPEG | Reserveformat og originalfiler | Fungerer overalt | Tyngst av de tapsbaserte formatene
• PNG | Skjermbilder med skarp tekst, grafikk som må være tapsfri | Ingen kvalitetstap | Svært tunge filer for fotografier
• SVG | Logoer, ikoner og enkle illustrasjoner | Skarp i alle størrelser, ofte bare noen få KB | Passer ikke til fotografier

Om AVIF skriver WordPress-teamet i kunngjøringen for versjon 6.5 at formatet kan gi filer som er opptil 50 % mindre enn JPEG med samme kvalitet. Formatet støttes i alle store nettlesere. Forbeholdet er at webhotellet må støtte det. Du sjekker det i WordPress under Verktøy → Nettstedshelse → Info → Mediehåndtering. Står ikke AVIF på listen over støttede formater, er det et spørsmål til webhotellet og ikke til deg.

Slik komprimerer du bilder: steg for steg

Rekkefølgen er viktig: beskjær, skaler, konverter, komprimer og fjern metadata. Hvis du komprimerer før du skalerer, kaster du bort kvalitet på piksler som uansett forsvinner.

• 1. Ta vare på originalen. Lagre den høyoppløste fila i en egen mappe og jobb alltid på en kopi. Du kan ikke hente tilbake kvalitet fra en komprimert fil.
• 2. Beskjær til riktig utsnitt og format (for eksempel 16:9 for toppbilder) før du gjør noe annet.
• 3. Skaler til riktig pikselbredde, altså omtrent dobbel visningsbredde (se tabellen over). Dette steget alene står ofte for den største besparelsen.
• 4. Eksporter til WebP eller AVIF. Gratisverktøyet Squoosh, som WordPress selv anbefaler, viser før og etter side om side i nettleseren.
• 5. Still inn kvaliteten. Start rundt 75–80 for WebP og senk til du ser forskjell ved 100 % zoom, og gå så ett hakk opp. AVIF-skalaen kan ikke sammenlignes med JPEG-skalaen, så vurder med øynene og ikke ut fra tallet.
• 6. Fjern metadata (EXIF). Mobilbilder har ofte GPS-posisjon, kameramodell og tidspunkt lagret i fila. Det er dødvekt for nettsiden og kan i verste fall avsløre for eksempel en hjemmeadresse.
• 7. Gi fila et beskrivende filnavn med små bokstaver og bindestrek, for eksempel «rorlegger-bad-bergen.webp» i stedet for «IMG_4821.webp».
• 8. Last opp og skriv alternativ tekst som beskriver innholdet i bildet.
• 9. Mål resultatet i PageSpeed Insights og sjekk at LCP-elementet har blitt raskere.

Den alternative teksten i steg 8 er ikke valgfri for alle. Kravene til universell utforming bygger på WCAG, og suksesskriterium 1.1.1 krever tekstalternativ til meningsbærende bilder. Rent dekorative bilder skal ha tom alt-tekst. Mer om hvilke punkter som gjelder, finner du i oversikten over wcag krav.

Hvordan komprimerer du bilder i WordPress og andre publiseringsløsninger?

I WordPress skjer en del automatisk, men ikke nok. Det du laster opp, avgjør fortsatt hvor tung siden blir. Ifølge WordPress' utviklerdokumentasjon blir bilder med bredde eller høyde over 2560 piksler skalert ned, og den nedskalerte versjonen blir brukt som største tilgjengelige størrelse. Grensen kan endres med filteret big_image_size_threshold.

Fallgruven med 2560-grensen

Det mange overser, er at originalen ikke slettes. WordPress lagrer den ved siden av den skalerte versjonen og lager i tillegg en serie mindre størrelser. Last du opp et bilde på 8 MB, blir altså 8 MB liggende på serveren i tillegg til alle kopiene. Over hundrevis av bilder fyller det lagringsplassen på webhotellet og gjør sikkerhetskopiene tregere. Vi anbefaler derfor å skalere bildene før opplasting, også i WordPress. Det er en fast del av god wordpress vedlikehold.

Ikke komprimer to ganger

WordPress komprimerer selv de størrelsene den lager, med en standard kvalitet på 82. Legger du på en optimaliseringsutvidelse med høy komprimering, og har du i tillegg komprimert hardt før opplasting, får du tre runder med tap. Resultatet blir ofte blokkete himmel og uskarpe kanter rundt tekst. Velg ett sted der komprimeringen skjer. Det vi ser oftest, er at én god utvidelse som også lager WebP eller AVIF, er enklest å holde i orden over tid. Dette henger tett sammen med teknisk WordPress-søkemotoroptimalisering.

Wix, Squarespace og andre nettsidebyggere

Byggere som Wix tar seg i stor grad av skalering og formatvalg når bildet vises. Jobben din er da hovedsakelig å velge riktig utsnitt, ikke laste opp originaler på mange megabyte og skrive alt-tekst. Har du en wix nettside, bør du likevel måle med PageSpeed Insights. Bakgrunnsvideoer og bildegallerier er typiske syndere som plattformen ikke rydder opp i for deg.

Hvorfor betyr bildestørrelsen noe for Google og AI-svar?

Tunge bilder gir treg LCP, og LCP er ett av Googles tre Core Web Vitals-mål for brukeropplevelse. Men problemet er ofte ikke selve fila. En analyse fra Chrome-teamet viser at et typisk nettsted med dårlig LCP venter 1,3 sekunder fra HTML-en kommer til toppbildet i det hele tatt blir etterspurt. Det er mer enn halve tidsbudsjettet på 2,5 sekunder, brukt før nedlastingen har begynt.

Derfor holder det ikke å gjøre bildet lite. Toppbildet må også oppdages tidlig. Det skal ikke ha loading="lazy", det bør ligge i HTML-en og ikke lastes inn via et skript eller som CSS-bakgrunn, og det kan gjerne få fetchpriority="high". Googles veiledning om å optimalisere LCP går gjennom hvordan du finner flaskehalsen i PageSpeed Insights.

For synlighet i AI-svar, som AI Overviews i Google, er det ingen egen bildeinnstilling. Men raske sider med beskrivende filnavn, gode alt-tekster og tydelig struktur er lettere for både søkemotorer og språkmodeller å lese og sitere. Mer om helheten finner du i tipsene våre om søkemotoroptimalisering.

Etter Lighthouse-optimalisering (bildekomprimering, caching, opprydding i skript) forbedres ytelsesscore hos Box sine kunder typisk fra under 55 til over 80.

Hva koster det å få bildene optimalisert?

Gjør du det selv, koster det i praksis bare tid. Squoosh og de innebygde funksjonene i WordPress er gratis, og mange optimaliseringsutvidelser har gratisnivåer med en grense på antall bilder per måned. Prisene på betalte nivåer endres jevnlig, så sjekk dem hos leverandøren før du velger.

Tre måter å løse det på

• Løsning | Passer for | Kostnad | Ulempe
• Manuelt før opplasting (Squoosh eller bildeprogram) | Små nettsider med få nye bilder i måneden | Gratis, bare tid | Avhenger av at alle som publiserer, husker det
• Optimaliseringsutvidelse i WordPress | Blogger og nettsider med jevnlig publisering | Gratisnivå eller abonnement, varierer per leverandør | Ny avhengighet som må vedlikeholdes, og fare for dobbel komprimering
• Teknisk gjennomgang fra byrå | Sider med dårlig ytelsesscore eller mange bilder | Fastpris eller timepris, avklar på forhånd | Koster mer i starten, men løser også caching og skript

I tekniske gjennomganger hos Box er uoptimaliserte bilder blant de tre vanligste funnene, sammen med feil i canonical-tagger og treg lasting på mobil. Alle tre er normalt løst på under en arbeidsdag. Vurderer du hva en større oppgradering koster, kan du se oversikten over hva en nettside koster.

Hvilke feil gjør bildene tunge eller stygge?

Den dyreste feilen er å laste toppbildet utsatt. Deretter kommer feil pikselstørrelse og dobbel komprimering. Dette er det vi ser oftest:

• Toppbildet har loading="lazy" fordi en utvidelse har slått det på for alle bilder. Konsekvens: LCP blir merkbart forsinket. Løsning: unnta de første bildene på siden.
• Bildet skaleres ned med CSS i stedet for på forhånd. Konsekvens: mobilen laster ned 4000 piksler for å vise 400. Løsning: skaler fila og bruk srcset.
• Skjermbilder med tekst blir lagret som tapsbasert JPEG. Konsekvens: uskarp og flekkete tekst. Løsning: tapsfri WebP eller PNG.
• Tekst ligger inne i bildet. Konsekvens: den kan ikke leses av skjermlesere eller søkemotorer, og den blir uleselig på mobil. Løsning: legg teksten i HTML over bildet.
• Metadata blir liggende i fila. Konsekvens: unødvendig vekt og mulig GPS-posisjon fra mobilbilder. Løsning: fjern EXIF ved eksport.
• Ingen måler etterpå. Konsekvens: ingen vet om endringen virket. Løsning: følg rutinene i guiden om å sjekke nettsider.

Om metadata og personvern: Bilder av ansatte og kunder er personopplysninger etter GDPR, uansett hvor små filene er. Komprimering endrer ikke behovet for samtykke eller annet behandlingsgrunnlag. Sørg for at personvernerklæringen dekker bildene du publiserer.

Når er komprimering ikke riktig løsning?

Komprimering hjelper ikke hvis flaskehalsen ligger på serveren eller i skriptene. Er tiden før første byte høy, eller blokkerer tunge skript visningen, blir siden treg uansett hvor små bildene er. Bildekomprimering passer heller ikke alltid for disse:

• Fotografer, arkitekter og andre som selger på bildekvalitet: bruk mildere komprimering og høyere oppløsning, og godta litt tyngre sider.
• Filer som skal lastes ned og trykkes, for eksempel pressebilder og produktark: tilby originalen som egen nedlasting.
• Sider der problemet er en bakgrunnsvideo, en chatteknapp eller sporingsskript: der bør du rydde, ikke komprimere.
• Utdaterte nettsider på en treg plattform: da kan det lønne seg mer å vurdere en redesign av nettsiden enn å optimalisere bilde for bilde.

Vårt råd er å måle før du bruker tid. Viser PageSpeed Insights at LCP-elementet er et bilde, og at nedlastingen tar mesteparten av tiden, er komprimering riktig sted å starte. Peker diagnosen på serveren, hjelper det mer å se på drift av nettsiden.

Vil du at noen skal se over ytelsen, bildene og det tekniske under panseret samtidig, kan du lese mer om hvordan vi jobber med nettsider for bedrifter.