En kunde sendte oss nettsiden sin for hastighetssjekk forrige måned. LCP (Largest Contentful Paint) lå på 6,2 sekunder. Det er ikke bare dårlig — det er kritisk dårlig. Brukere gir opp før siden i det hele tatt er ferdig lastet.
Vi åpnet Lighthouse-rapporten og scrollte ned. Helt nederst: hero-bildet veide 4,1 MB. Det var en JPEG på 4500×3000 piksler, eksportert direkte fra Photoshop med 95 % kvalitet. Ingen kompresjon. Ingen WebP. Ingen responsive variant.
Vi konverterte det til WebP, kjørte gjennom en kompressor, og laget tre størrelser med srcset. Det ene bildet gikk fra 4,1 MB til 180 KB. LCP gikk fra 6,2 sekunder til 1,8 sekunder. Ingen andre endringer ble gjort.
Bilder er der den raskeste hastighets-gevinsten vanligvis ligger.
Hvorfor bilder er den viktigste optimaliseringen
På en moderne nettside er bilder typisk 50–70 % av total sidestørrelse. Mer enn JavaScript. Mer enn CSS. Mer enn skrifttyper.
Det betyr at hvis bildene ikke er optimalisert, vinner du nesten ingenting på å minifisere JavaScript eller komprimere CSS. Du må starte med bildene.
Google bryr seg om dette ekstra mye. Largest Contentful Paint — Googles offisielle ytelses-måling — er som regel et bilde. For 80–90 % av nettsider er det hero-bildet eller et stort feature-bilde over fold. Hvis det er treigt, taper du LCP. Hvis du taper LCP, taper du Core Web Vitals-score. Det er en rangeringsfaktor i Google.
Hvilket format bør du bruke?
Det er tre formater som matters i 2026: JPEG, WebP og AVIF. PNG har sin nisje (transparens), SVG har sin nisje (ikoner og logoer), GIF har ingen nisje lenger.
JPEG er den gamle standarden. Støttes overalt, kompresjonen er grei, men taper i sammenligning med moderne alternativer.
WebP ble lansert av Google i 2010 og fikk full browser-støtte i 2020. Den komprimerer typisk 25–35 % mindre enn JPEG på samme synlige kvalitet. Det er ditt nye standard-format. Hvis du fortsatt bruker JPEG, bytt.
AVIF er nyeste i flokken. Komprimerer typisk 30 % mindre enn WebP — så cirka 50 % mindre enn JPEG. Støttes i Chrome, Firefox, Safari (siden 16) og Edge. Den eneste reelle bekymringen er at Safari 15 og eldre ikke støtter det, men de utgjør under 3 % av norske brukere i 2026.
Best-practice er å bruke en <picture>-tag med AVIF som første kilde og WebP som fallback:
<picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" alt="..." width="1200" height="600"> </picture>
Nettleseren plukker den første kilden den støtter. Moderne nettlesere får AVIF (mindre fil, raskere lasting). Eldre får WebP eller JPEG som fallback.
Hvis det er for mye markup-overhead for hvert bilde, kan du droppe AVIF og bare bruke WebP. Du sparer 25–35 % istedenfor 50 % — fortsatt en kjempegevinst.
Hvor store skal bildene være?
Tre tommelfingerregler for filstørrelse:
Hero-bilder (det første brukeren ser): under 200 KB i WebP. Helst under 150 KB. Dette er bildet som påvirker LCP — det MÅ være lite.
Innholdsbilder (bilder i artikler, produkt-bilder, illustrasjoner): under 100 KB i WebP.
Ikoner og små grafikker: SVG hvis mulig (ofte under 5 KB), ellers under 20 KB.
Hvis et bilde er over 1 MB, er det nesten alltid noe galt. Vanligvis en eksport på «full kvalitet» fra Photoshop som ikke har vært gjennom kompresjon. Eller en altfor stor opprinnelige fil som ikke er skalert ned.
For dimensjoner: hero-bildet i 2x retina-densitet bør være maks 2400 piksler bredt. Innholdsbilder maks 1600 piksler. Mye bredere er bortkastet — skjermen kan ikke vise det uansett.
Responsive bilder med srcset
Det er ikke nok å ha ett optimalisert hero-bilde. Du må ha flere størrelser for forskjellige skjermer. En iPhone trenger ikke 1920 piksler bredt bilde — den kan ikke vise det engang.
<img
src="hero-800.webp"
srcset="
hero-400.webp 400w,
hero-800.webp 800w,
hero-1200.webp 1200w,
hero-2400.webp 2400w
"
sizes="(max-width: 768px) 100vw, 1200px"
alt="..."
width="1200"
height="600"
>
Nettleseren leser sizes-attributtet for å forstå hvor stor bildet vil vises, og plukker den minste filen som er stor nok. På mobil hender det at den henter 400w-versjonen (40 KB) i stedet for 2400w-versjonen (180 KB). Stor effekt.
Hvis du bruker WordPress eller Next.js Image-komponent gjøres dette automatisk. For skreddersydd må du gjøre det selv eller bruke et bildebehandlingsverktøy som Cloudinary eller Imgix.
Lazy loading — bra, men ikke overalt
loading="lazy" på et img-element ber nettleseren om å vente med å laste bildet til brukeren scroller nær det. Det er gull-standard for alt under fold (det som ikke er synlig i første skjermbilde).
<img src="thumbnail.webp" alt="..." loading="lazy" width="300" height="200">
Den klassiske fellen: legge loading="lazy" på hero-bildet. Det er katastrofalt for LCP — nettleseren utsetter da lasting av det bildet som rangeres som Largest Contentful Paint. Effekten er at LCP-en din blir 1–2 sekunder verre.
Regel: hero-bildet eller noe annet over fold = ingen lazy. Resten = lazy.
Width og height-attributter er også viktige. Uten dem reserverer ikke nettleseren plass for bildet før det er lastet, og siden flytter seg når bildet poppes inn. Det heter Cumulative Layout Shift (CLS) og er en annen rangeringsfaktor. Alltid med width og height på img-elementer.
Hvilke verktøy faktisk fungerer?
Det er en jungel av bilde-kompressorer der ute. De fleste fungerer greit. Vi har sett bra resultater fra:
Squoosh (squoosh.app) — Googles eget, browser-basert, gratis. Best for enkle ad-hoc kompresjoner.
TinyPNG og TinyJPG — gratis opp til 20 bilder per måned. Bra for PNG og JPEG, ikke WebP/AVIF.
ImageOptim (Mac) eller Caesium (Windows) — desktop-apps som batch-prosesserer en hel mappe.
Sharp (Node.js-bibliotek) eller ImageMagick (CLI) — for utviklere som vil automatisere. Vi bruker Sharp i alle skreddersydde prosjekter.
Cloudinary, Imgix, Cloudflare Images — tjenester som tar et originalbilde og leverer det optimale formatet automatisk basert på brukerens nettleser. Koster typisk 10–50 USD/måned for SMB-bruk. Verdt det hvis du har mange bilder.
For en standard WordPress-side: bruk pluginen Smush, ShortPixel eller EWWW. De gjør 80 % av jobben uten konfigurasjon. Vi har sett besparelser på 60–80 % på første kjøring.
Bildebudsjettet — hvor mye er for mye?
For en moderne nettside er en grei tommelfingerregel: total bildevekt under 1,5 MB per side. Helst under 1 MB.
Hero-bildet bør bidra med under 200 KB. Resten bør være innholdsbilder og ikoner, hvert under 100 KB.
Total sidevekt (alt: HTML + CSS + JS + bilder + skrifttyper) bør være under 2,5 MB. Helst under 2 MB. Norske SMB-er ligger ofte mellom 3 og 8 MB total sidevekt, og bilder er hovedårsaken.
For å sjekke hvor du står: åpne nettverks-fanen i Chrome DevTools, last siden, og sjekk total size. Eller bruk Lighthouse — den gir en samlet score og lister de største ressursene.
Hva med alt-tekst, selv om det ikke er teknisk optimalisering?
Vi nevner det fordi alt-tekst er en del av bilde-strategien selv om det ikke handler om filstørrelse.
Alt-tekst er kritisk for tilgjengelighet. Skjermlesere leser opp alt-teksten. Uten alt-tekst sier de filnavnet, som er ubrukelig.
Alt-tekst er en SEO-faktor. Google bruker det for å forstå bildet og rangere det i bildesøk. For en lokal tannklinikk-bilderbank kan «tannlege Bergen utfører tannrens» (alt-tekst) gi titalls klikk per måned fra bildesøk.
Alt-tekst er gratis. Du har bildet uansett — å skrive en linje tekst tar 10 sekunder.
Tre regler: beskriv hva bildet viser (ikke hva du vil at folk skal tenke om bildet). Hold det kort (under 125 tegn). Hvis bildet er dekorativt (bakgrunnsmønster, hjørne-ornament), bruk tom alt (alt="") så skjermleseren hopper over det.
Vi har bygget et verktøy for å sjekke alt på en gang
Det er for slitsomt å manuelt sjekke filstørrelse, format og alt-tekst på hvert bilde på en nettside. Så vi har bygget bilde-sjekken. Du limer inn URL-en, og verktøyet:
Henter alle bilder på siden (opptil 50), gjør HEAD-oppslag for filstørrelse, identifiserer format, sjekker alt-tekst og lazy loading, og estimerer hvor mye du kan spare ved å konvertere til WebP.
Det erstatter ikke Lighthouse for full performance-bildet, men det gir deg det spesifikke bildet-bilde-bildet på 30 sekunder. Sortert etter størrelse — de største problemene først.
Den korte handlingslisten
Hvis du har lest så langt og vil komme i gang denne uken:
Kjør bilde-sjekken på forsiden og en av tjenestesidene dine. Du ser umiddelbart hvor problemene ligger.
Hvis hero-bildet er over 500 KB: konverter til WebP, krymp til riktige dimensjoner. Det er 70 % av gevinsten med 30 % av jobben.
Sjekk at alle bilder under fold har loading="lazy". Det er en quick win uten kompromisser.
Sjekk alt-tekster. Hvis du har 20 bilder uten alt, fiks dem på en time.
Hvis du vil at vi tar en gjennomgang og forteller deg konkret hvilke bilder som bremser nettsiden mest, si fra. Vi gjør 15-minutters bilde-revisjoner gratis.
Det er ikke prangende arbeid. Men det er kanskje den raskeste forbedringen du kan gjøre på en treig nettside — og effekten merkes nesten umiddelbart i hastighet, brukeropplevelse og Google-rangering.