UX Indeks

Datavisning

Responsive og performante billeder

Billeder er som regel de tungeste elementer på en side — og dermed en hovedårsag til både langsom indlæsning og layout, der hopper, mens siden loader. Løsningen er ikke færre billeder, men bedre håndterede: reservér pladsen, udskyd det, der er under skærmkanten, prioritér hero-billedet, og server moderne formater i den rigtige størrelse. Her er evidensen, best practices og de typiske faldgruber, forankret i Core Web Vitals.

5 min læsning

Definition

Responsive og performante billeder er teknikken, hvor du serverer den rette billedstørrelse og -format til hver enhed (srcset/sizes, <picture>, AVIF/WebP), reserverer pladsen på forhånd for at undgå layout-skift (CLS), og styrer hvornår hvert billede loader (lazy-loading under skærmkanten, høj prioritet på hero-billedet).

Hvorfor det virker

To af Googles Core Web Vitals handler direkte om billeder. Largest Contentful Paint (LCP) — hvor hurtigt det største element (ofte et billede) tegnes — bør ligge på 2,5 sekunder eller mindre, og Cumulative Layout Shift (CLS) — hvor meget layoutet flytter sig — bør være 0,1 eller mindre. Begge måles på 75. percentil af sidevisninger på tværs af mobil og desktop.1

Billeder uden reserveret plads er en klassisk kilde til layout-skift: når billedet loader, skubber det pludselig teksten ned, og brugeren mister sit sted — eller klikker forkert. Sætter du billedets dimensioner (width/height eller aspect-ratio), kan browseren reservere pladsen på forhånd, og CLS holdes nede.51

Hvornår et billede loader er lige så vigtigt som hvor stort det er. Browserens indbyggede lazy-loading (loading="lazy") sparer båndbredde ved først at hente billeder, når de nærmer sig skærmkanten — men det gælder kun billeder under folden. Hero-billedet, der ofte er LCP-elementet, må aldrig lazy-loades; det forsinker bare det, brugeren venter på.25

Moderne formater flytter meget. WebP-billeder er typisk 25-35% mindre end de tilsvarende JPEG- og PNG-filer ved samme oplevede kvalitet — og mindre filer betyder hurtigere LCP direkte. AVIF komprimerer endnu hårdere, men er nyere og understøttes bredt først fra nyere browserversioner, så det serveres bedst med et fallback.4

Hvornår du bruger det — og hvornår ikke

Hvornår du bruger det

  • Sider med mange eller store billeder — produktlister, gallerier, artikler og forsider — hvor billedvægt afgør indlæsningstiden.
  • Når Core Web Vitals betyder noget for SEO og oplevelse: du vil holde LCP under 2,5 s og CLS under 0,1.
  • Responsive layouts, hvor det samme billede vises i vidt forskellige størrelser på mobil og desktop.

Hvornår du bør undgå det

  • Rene ikoner og enkle grafiske elementer, hvor SVG eller en icon-font er lettere og skarpere end et raster-billede.
  • Hero-/above-the-fold-billeder, der aldrig bør lazy-loades — de skal loade med det samme, ikke udskydes.

Best practices

  1. Reservér altid pladsen med dimensioner eller aspect-ratio

    Angiv width og height på <img>, eller reservér pladsen i CSS med aspect-ratio. Så tegner browseren den rigtige boks, før billedet er hentet, og layoutet hopper ikke, når det lander. Det er den enkleste vej til lav CLS.51

  2. Lazy-load det, der er under skærmkanten — men aldrig hero-billedet

    Sæt loading="lazy" på billeder længere nede på siden, så de først hentes, når brugeren nærmer sig dem. Lad billeder i første skærmbillede — især LCP-/hero-billedet — loade som standard (eager). At udskyde hero-billedet forsinker kun det, siden bliver bedømt på.2

  3. Giv hero-billedet høj prioritet med fetchpriority

    Billeder i viewporten starter typisk med lav prioritet og bliver først skubbet op, når layoutet er beregnet. Marker det kritiske hero-/LCP-billede med fetchpriority="high", så browseren begynder at hente det med det samme.2

  4. Server responsive størrelser med srcset og sizes

    Angiv flere billedbredder i srcset og fortæl med sizes, hvor stort billedet vises i layoutet. Så vælger browseren den mindst mulige fil, der stadig ser skarp ud — en mobil henter ikke desktop-versionen. Valget sker under parsing, før CSS og JavaScript, så det er hurtigere end at bytte billede med script.3

  5. Brug <picture> til art direction, srcset til ren størrelse

    Skal du vise et andet beskåret motiv på mobil end på desktop, så brug <picture> med <source media="…">. Handler det kun om at levere samme billede i forskellige størrelser, er srcset/sizes nok. Bland ikke media-betingelser i begge — vælg det ene.3

  6. Vælg moderne formater med fallback

    Server AVIF eller WebP frem for JPEG/PNG, hvor det kan lade sig gøre — WebP alene sparer typisk 25-35% filstørrelse. Brug <picture> med flere <source>-formater, så ældre browsere falder tilbage på et <img> med JPEG/PNG.43

  7. Skriv altid meningsfuld alt-tekst

    Alt-teksten er obligatorisk for tilgængelighed: skærmlæsere læser den op, og den vises, hvis billedet ikke loader. Beskriv indholdet konkret — undgå "billede" eller filnavnet. Rent dekorative billeder gives en tom alt="".5

Typiske fejl

  • Billeder uden dimensioner

    Uden width/height eller aspect-ratio kender browseren ikke pladsen, før billedet loader — og så hopper layoutet. Det er den hyppigste kilde til dårlig CLS.

  • Lazy-loading på hero-billedet

    At sætte loading="lazy" på alt — inklusive above-the-fold-billedet — forsinker netop det element, LCP måles på. Lazy-loading hører kun til under skærmkanten.

  • Ét kæmpe billede til alle enheder

    Samme fulde desktop-fil serveret til en telefon spilder båndbredde og gør LCP langsommere. Uden srcset/sizes henter mobilen langt flere pixels, end skærmen kan vise.

  • Manglende eller intetsigende alt-tekst

    Alt="" på et informativt billede — eller alt="img_1234" — efterlader skærmlæser-brugere uden indhold og svækker tilgængeligheden.

Eksempler i praksis

Google Flights (ofte fremhævet)

Google Flights bruges ofte som eksempel på at prioritere hero-billedet: ved at markere det kritiske billede med fetchpriority="high" begynder browseren at hente det tidligere, og LCP forbedres — uden at ændre HTML-strukturen.

Netflix (ofte fremhævet)

Netflix fremhæves ofte i diskussionen om moderne formater: virksomheden har testet AVIF og rapporteret markante filstørrelses-reduktioner mod JPEG og WebP ved samme kvalitet — en illustration af, hvad formatvalg alene kan betyde for billedtunge sider.

Ofte stillede spørgsmål

Hvordan undgår jeg, at billeder får siden til at hoppe?

Sæt altid billedets dimensioner — width og height på <img> eller aspect-ratio i CSS. Så reserverer browseren pladsen, før billedet loader, og du holder Cumulative Layout Shift (CLS) under den anbefalede grænse på 0,1.

Skal jeg lazy-loade alle billeder?

Nej. Brug loading="lazy" på billeder under skærmkanten, men lad billeder i første skærmbillede — især hero-/LCP-billedet — loade med det samme. At lazy-loade above-the-fold-billeder forsinker kun det, brugeren venter på.

Hvad gør fetchpriority="high"?

Det fortæller browseren, at et billede er kritisk og skal hentes tidligt. Billeder i viewporten starter ellers med lav prioritet, indtil layoutet er beregnet — fetchpriority="high" på hero-/LCP-billedet fjerner den forsinkelse.

srcset eller <picture> — hvad skal jeg bruge?

Brug srcset/sizes, når det er samme billede i forskellige størrelser (resolution switching). Brug <picture> med <source media="…">, når du vil vise et andet motiv eller beskæring på forskellige skærme (art direction), eller når du serverer flere formater med fallback.

Er AVIF og WebP bedre end JPEG?

Ja, som regel. WebP er typisk 25-35% mindre end JPEG/PNG ved samme oplevede kvalitet, og AVIF komprimerer endnu hårdere. AVIF er nyere og bør serveres med et WebP- eller JPEG-fallback via <picture>, så ældre browsere også får et billede.

Kilder

  1. Web Vitalsweb.dev (Google) · god LCP ≤ 2,5 s; god CLS ≤ 0,1; 75. percentil (mobil + desktop)
  2. Browser-level image lazy loading for the webweb.dev (Google) · lazy-load ikke in-viewport/LCP-billeder; overvej fetchpriority="high"
  3. Responsive imagesMDN Web Docs · srcset/sizes til resolution switching; <picture> til art direction
  4. Use WebP imagesweb.dev (Google) · WebP typisk 25-35% mindre end JPEG/PNG
  5. The Image Embed element (<img>)MDN Web Docs · alt påkrævet for tilgængelighed; loading="lazy" til offscreen; angiv width/height

Relaterede mønstre

Udforsk videre

Alle mønstre →
Handel

Produktgalleri, lightbox & zoom

Et produktgalleri, der viser nok billeder, flere vinkler, skala og zoom — uden auto-roterende karrusel og med tastaturvenlig lightbox.

Se mønster →
Datavisning

Skeleton-loading

Vis layout-pladsholdere mens indholdet hentes.

Se mønster →
Datavisning

Blok-layout

Komponér siden af stablede fuldbredde-blokke — hero, billede+tekst, citat, CTA — med tydeligt hierarki og en skanbar rækkefølge, der guider øjet nedad.

Se mønster →