Billeder udgør typisk 50–70% af en websides samlede datavægt. Alligevel behandler de fleste teams billedoptimering som en eftertanke – og det er en fejl, der koster dyrt i loadtid, konverteringer og Google-placeringer.

Google har dokumenteret, at for hver ekstra sekund et mobilsite bruger på at loade, falder konverteringsraten med op til 20%. Billedoptimering er dermed ikke kun et teknisk spørgsmål – det er et forretningskritisk parameter.

Denne guide dækker alle aspekter af emnet: fra formatvalg og komprimering til Core Web Vitals og CDN-infrastruktur.

Hvorfor billedoptimering er kritisk

Core Web Vitals – Googles målestok for brugeroplevelse, som siden 2021 direkte påvirker placeringer i søgeresultaterne – handler i høj grad om billeder. Largest Contentful Paint (LCP) måler, hvornår det primære indhold er synligt, og i de fleste tilfælde er det primære indhold et billede. Et dårligt optimeret hero-billede kan alene ødelægge en LCP-score.

Derudover er den oplevede kvalitet af et site tæt forbundet med loadhastighed. Et hurtigt site føles professionelt og troværdigt – og det er en af de mest undervurderede parametre i webdesign.

Billedformater – hvornår bruger du hvad?

Valget af filformat er den første og vigtigste beslutning. Hvert format har et specifikt formål, og brug af det forkerte kan koste 40–80% unødvendig filstørrelse.

JPEG er stadig arbejdshesten for fotografier og komplekse billeder med mange farvetoner. En kvalitetsindstilling på 75–85 er typisk det søde punkt. Undgå JPEG til billeder med tekst, hårde kanter eller transparens.

PNG er lossless og understøtter transparens. Det er det rette valg til logoer, ikoner og skærmbilleder. Til fotografier er PNG næsten altid et forkert valg – filerne bliver unødvendigt store.

GIF er i praksis forældet til animation. Det understøtter kun 256 farver og producerer store filer. Brug i stedet MP4/WebM – samme visuelle resultat, op til 10 gange mindre filstørrelse.

WebP bør i dag være standardformatet for både fotografier og grafik med transparens. Det leverer typisk 25–35% bedre komprimering end JPEG ved samme visuelle kvalitet og understøtter lossless, lossy og animation.

AVIF er det næste skridt. Baseret på AV1-videocodec’et leverer det 30–50% bedre komprimering end WebP. Browserunderstøttelse er over 90%, og til statiske sites er det i dag næsten altid det rigtige valg.

SVG er vektorgrafik beskrevet i XML. Til logoer, ikoner og illustrationer er SVG overlegen: perfekt skarp på alle skærmstørrelser og mulig at animere og style med CSS. Optimer altid SVG med SVGO, da editorer som Figma eksporterer med masser af unødig metadata.

Tommelfingerregel:

  • Fotografi → AVIF (med WebP og JPEG som fallback)
  • Grafik med transparens → WebP eller PNG
  • Logo/ikon/illustration → SVG
  • Animation → MP4/WebM

Komprimering

Der er to tilgange: lossless, som optimerer filstrukturen uden at røre billed-data (5–20% gevinst), og lossy, som kasserer data øjet statistisk set ikke bemærker (op til 80% gevinst). En kvalitetsindstilling på 75–85 for JPEG og 80–90 for WebP/AVIF er et godt udgangspunkt for de fleste use cases.

Én vigtig tommelfingerregel: arbejd altid i et lossless format og eksportér til det komprimerede format som det allersidste skridt. Gentagen re-komprimering af JPEG-filer øger artefakter for hver runde.

Responsive billeder og korrekte dimensioner

En af de mest udbredte fejl er at servere et 2400px bredt billede til en mobiltelefon med 390px display. Browseren skalerer det ned – men downloaden skete med fuld filstørrelse.

Løsningen er srcset og sizes:

<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, (max-width: 1200px) 80vw, 1200px"
  alt="Beskrivende alt-tekst"
  width="1200"
  height="600"
/>

Definer altid width og height på <img>-elementet. Det sikrer, at browseren kan reservere den korrekte plads i layoutet inden billedet er downloadet – og dermed undgår layout shift (CLS).

Til art direction – hvor mobilversionen er et fundamentalt anderledes billede end desktop-versionen – bruges <picture>-elementet med media-attributter.

Lazy Loading

Lazy loading sikrer, at billeder udenfor viewport ikke loades, før brugeren scroller hen til dem. I moderne browsere kræver det én enkelt attribut:

<img src="billede.jpg" alt="..." loading="lazy" />

Den kritiske undtagelse: billeder above the fold må aldrig have loading="lazy". Det forsinker netop de billeder brugeren ser først og ødelægger LCP-scoren. En praktisk tommelfingerregel er, at de første 2–3 billeder på en side ikke bør have lazy loading.

Core Web Vitals og LCP

Largest Contentful Paint (LCP) måler, hvornår det største synlige element i viewport er renderet – i de fleste tilfælde et billede. Google anbefaler en LCP under 2,5 sekunder.

Tre tiltag gør den største forskel for LCP-scoren:

Preload fortæller browseren om at downloade billedet tidligt, inden HTML er fuldt parseret:

<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

fetchpriority="high" på selve <img>-elementet signalerer, at dette billede skal prioriteres over andre ressourcer:

<img src="hero.webp" fetchpriority="high" alt="..." width="1200" height="600">

Undgå loading="lazy" på LCP-billedet. Det er en overraskende hyppig fejl, der alene kan flytte LCP fra “Good” til “Needs improvement”.

Disse tre tiltag kombineret kan på mange sites flytte LCP-scoren markant – uden at ændre et eneste billede.

CDN, Image CDN’er og praktiske værktøjer

CDN og Image CDN’er

Et traditionelt CDN serverer filer fra servere tæt på brugeren og reducerer latency. Et Image CDN går skridtet videre: det transformerer, skalerer, konverterer og komprimerer billeder on-the-fly via URL-parametre. Man uploader ét master-billede, og CDN’et serverer det korrekte format og den korrekte størrelse til den specifikke bruger og enhed.

En URL hos imgix kan eksempelvis se sådan ud:

https://eksempel.imgix.net/hero.jpg?w=800&fm=webp&q=80&auto=compress

De mest udbredte løsninger er Cloudinary, imgix og Cloudflare Images. For større projekter er et Image CDN en af de bedste investeringer, der kan foretages – det eliminerer behovet for manuelt at generere og vedligeholde billedvarianter i codebasen.

Praktiske værktøjer

Squoosh (squoosh.app) – Googles browser-baserede komprimeringsværktøj. Fremragende til at sammenligne formater og kvalitetsindstillinger side om side. Uundværligt til at kalibrere pipeline-indstillinger.

ImageOptim (Mac) – Simpelt GUI-værktøj til lossless og lossy komprimering af JPEG, PNG og SVG. Velegnet til ad-hoc optimering.

SVGO – Kommandolinjeværktøj specifikt til SVG-optimering. Fjerner unødig metadata, kommentarer og redundant markup.

Sharp – Node.js-bibliotek til programmatisk billedprocessering. Bruges i stort set alle moderne Node-baserede build-pipelines og er rygraden i frameworks som Next.js.

PageSpeed Insights / Lighthouse – Googles audit-værktøj viser specifikt, hvilke billeder der er unødigt store, mangler moderne formater eller blokerer rendering. Et naturligt udgangspunkt for audit af eksisterende sites.

WebPageTest – Mere detaljeret end Lighthouse. Viser en filmstrip af, hvornår hvert element loader, og identificerer præcist, hvilket billede der er LCP-kandidat.

Den komplette tjekliste

Format og komprimering

  •  Fotografier eksporteret som AVIF (med WebP og JPEG som fallback)
  •  Grafik med transparens som WebP eller PNG
  •  Logoer og ikoner som SVG, optimeret med SVGO
  •  Animationer som MP4/WebM, ikke GIF
  •  JPEG komprimeret til kvalitet 75–85
  •  WebP/AVIF komprimeret til kvalitet 80–90
  •  EXIF-data strippet

Responsive billeder

  •  srcset og sizes defineret på alle billeder
  •  width og height attributter sat på alle <img>-elementer
  •  Art direction håndteret med <picture> hvor relevant
  •  Ingen billeder serveret større end de vises

Loading og performance

  •  loading="lazy" på alle billeder nedenfor the fold
  •  fetchpriority="high" på LCP-billedet
  •  <link rel="preload"> på LCP-billedet
  •  Ingen lazy loading på above-the-fold billeder

Infrastruktur

  •  Billeder serveres via CDN
  •  Caching-headers er sat korrekt (lang TTL for hashed filnavne)
  •  Lighthouse/PageSpeed score auditeret og valideret

Opsummering

Billedoptimering er ikke glamourøst arbejde – men det er noget af det, der har den mest direkte og målbare effekt på brugeroplevelse og forretningsresultater. Start med tjeklisten, sæt en baseline med Lighthouse, og lad tallene styre prioriteringen.

Bonustip: Metadata, SEO og tilgængelighed

Billeder kommunikerer ikke kun til brugeren – de kommunikerer til søgemaskiner og skærmlæsere. En god alt-tekst beskriver billedets indhold og kontekst (“Kvinde redigerer kode på laptop på café”) frem for at være generisk (“billede”). Dekorative billeder bør have en tom alt-attribut (alt=""), ikke en manglende. Filnavne læses af Googles crawler – billedoptimering-guide.jpg er semantisk meningsfuldt; IMG_4823.jpg er det ikke. Brug bindestreger som separator. EXIF-data (GPS, kameramodel m.m.) bør strippes ved eksport – af hensyn til privatlivsbeskyttelse og filstørrelse.


Daniel Nielsen

Nordjyde bosat i København. Specialist i online medier ansat i online marketing bureau i dagtimerne og musik- og fotonørd i fritiden.

Alle forfatters artikler