# Optimér billeder til nettet uden at miste kvalitet

[Canonical HTML page](https://gradiently.design/da/guide/lighthouse-image-performance)

Billeder er som regel det tungeste på en side og grunden til, at Lighthouse brokker sig. Her er en fremgangsmåde, der virker: de rette pixelstørrelser, det rette format, responsiv markup og indlæsningstip, uden synligt tab.

## The short version

- Når du skal optimere billeder til web, eksporterer du hvert billede i den størrelse, det vises i, cirka fordoblet til skærme med høj tæthed, i stedet for at uploade originalen.
- AVIF og WebP giver meget mindre filer end JPEG og PNG ved nogenlunde samme synlige kvalitet, og alle nuværende browsere understøtter WebP.
- Attributterne srcset og sizes lader browseren hente det mindste billede, der stadig ser skarpt ud på den enkelte skærm.
- Brug lazy loading på billeder under folden med loading="lazy", men indlæs det store heltebillede med det samme og med fetchpriority="high", fordi det som regel afgør Largest Contentful Paint.
- Angiv altid width og height på billeder, så browseren reserverer plads, og layoutet ikke hopper, mens de indlæses.

Hvis du vil **optimere billeder til web** uden synligt tab, skal du gøre fem ting: eksportere hvert billede i den pixelstørrelse, det vises i (cirka det dobbelte til skarpe skærme), vælge et moderne format som AVIF eller WebP, komprimere til en moderat kvalitet og sammenligne med øjet, levere flere størrelser med `srcset` og lazy loade alt under folden. De trin fjerner det meste af billedadvarslerne i Lighthouse og skærer ofte sidens vægt kraftigt ned, for originalen direkte fra et kamera eller et designprogram er mange gange større, end skærmen har brug for.

## Trin 1: eksportér i den størrelse, du viser

Et billede, der vises 800 pixels bredt, behøver ikke være 4.000 pixels bredt. Lighthouse markerer for store billeder, fordi de overskydende pixels bliver hentet, afkodet og smidt væk. Mål, hvor bredt billedet højst fylder i dit layout, og eksportér så cirka dobbelt så bredt til telefoner og bærbare med høj tæthed. Mere end det dobbelte ser sjældent skarpere ud og koster altid bytes.

| Billede | Vist i | Eksportbredde |
| --- | --- | --- |
| Heltebillede i fuld bredde | Op til 1920 px | 1920 px samt mindre versioner |
| Artikelbillede | Omkring 720 px | 1440 px |
| Miniature på kort | Omkring 360 px | 720 px |
| Avatar | 48 px | 96 px |
| Open Graph-billede | Uden for siden | Præcis 1200×630 |

Typiske mål. Et heltebillede i fuld bredde er undtagelsen fra fordoblingen: 1920 px dækker de fleste skærme, og meget store skærme får et lidt blødt billede til en fornuftig pris.

- Hjemmesidens heltebillede 1920×1080: 1920 × 1080
- Blogbanner 1200×600: 1200 × 600
- Linkvisning 1200×630: 1200 × 630

Tre almindelige webbilledstørrelser tegnet i målestok. Design i den endelige størrelse, så intet beskæres eller skaleres efter eksport.

## Trin 2: vælg det rette format

Formatet betyder mere end noget komprimeringsreglage. AVIF giver som regel den mindste fil, WebP kommer tæt på og understøttes overalt i dag, og JPEG og PNG er stadig de sikre reserver. [WebP eller PNG](https://gradiently.design/da/guide/webp-images) og [PNG eller JPG](https://gradiently.design/da/guide/png-vs-jpeg) går i dybden med hvert par.

| Format | Bedst til | Bemærkninger |
| --- | --- | --- |
| AVIF | Fotos, farveforløb, store heltebilleder | Mindste filer; langsommere at kode |
| WebP | Næsten alt | Med og uden tab, gennemsigtighed, bred understøttelse |
| JPEG | Fotos, som reserve | Ingen gennemsigtighed; giver bånd i bløde farveforløb |
| PNG | Skærmbilleder, flad grafik, gennemsigtighed | Uden tab og stor til fotos |
| SVG | Logoer, ikoner, illustrationer | Vektor, lille når den er enkel; se [SVG eller PNG](https://gradiently.design/da/guide/svg-vs-png) |

Vælg efter indhold, ikke efter vane. Bløde farveforløb er det sværeste tilfælde for JPEG, og det er her, WebP og AVIF hjælper mest.

> **Farveforløb komprimeres dårligt** Bløde farveovergange viser komprimeringen som synlige trin. Læg lidt korn på, før du eksporterer, som beskrevet i [bånddannelse i farveforløb](https://gradiently.design/da/guide/gradient-banding), så kan koderen arbejde hårdere, uden at nogen ser det. Endnu bedre: tegn webforløb i CSS.

Et forløb til et heltebillede på cirka 70 bytes: `linear-gradient(160deg, #0f172a 0%, #1e3a8a 50%, #0ea5e9 100%)`

Dette forløb koster som CSS mindre end en enkelt linje af siden. Eksporteret som et billede på 1920×1080 ville det samme veje mange kilobytes. Se [ydeevne for CSS-forløb](https://gradiently.design/da/guide/css-gradient-performance).

## Trin 3: komprimér, og kig så

Formater med tab har en kvalitetsindstilling, og den rette værdi afhænger af billedet. Start omkring 75 til 80 for WebP og omkring 50 til 60 for AVIF, eksportér, og sammenlign med originalen ved 100 % zoom. Sænk værdien, indtil du kan se en forskel, og gå så ét trin op igen. Ansigter, fin tekst og farveforløb kræver mere kvalitet end travle landskaber. [Billedkomprimering](https://gradiently.design/da/guide/image-compression) forklarer, hvad koderen smider væk.

Fjern også metadata som kameraoplysninger og indlejrede miniaturer, mens du er i gang. De fleste eksportværktøjer gør det med ét afkrydsningsfelt, og det sparer bytes, ingen ser.

## Trin 4: responsiv markup med srcset og sizes

Når du har eksporteret flere bredder, lader du browseren vælge. `srcset` opregner filerne og deres bredder; `sizes` fortæller browseren, hvor bredt billedet kommer til at fylde. Browseren henter så den mindste fil, der er skarp nok til den skærm.

```html
<picture>
  <source type="image/avif"
    srcset="/img/hero-960.avif 960w, /img/hero-1440.avif 1440w, /img/hero-1920.avif 1920w"
    sizes="100vw" />
  <source type="image/webp"
    srcset="/img/hero-960.webp 960w, /img/hero-1440.webp 1440w, /img/hero-1920.webp 1920w"
    sizes="100vw" />
  <img src="/img/hero-1920.jpg" alt="Morning light over the harbour"
    width="1920" height="1080" fetchpriority="high" decoding="async" />
</picture>
```

Browseren bruger den første kilde, den understøtter. img-elementet er både reserven og stedet for alt, width, height og indlæsningstip.

For et billede inde i en kolonne beskriver du layoutet i `sizes`, for eksempel `sizes="(min-width: 1024px) 720px, 100vw"`. Forkert `sizes` er den hyppigste grund til, at en responsiv opsætning stadig henter den store fil.

## Trin 5: de indlæsningstip, der tæller

```html
<!-- Below the fold: let the browser wait -->
<img src="/img/team-720.webp" alt="The team at the spring workshop"
  width="720" height="480" loading="lazy" decoding="async" />

<!-- The hero: fetch first, never lazy -->
<img src="/img/hero-1920.webp" alt="Morning light over the harbour"
  width="1920" height="1080" fetchpriority="high" />
```

Width og height lader browseren reservere plads ud fra billedformatet, så intet flytter sig, mens billederne ankommer. CSS kan stadig gøre billedet flydende med max-width: 100% og height: auto.

### Almindelige fejl

- `loading="lazy"` på heltebilledet
- Ingen width og height, så siden hopper
- Én kæmpefil til alle skærme
- En JPEG af et fladt logo eller skærmbillede
- Farveforløb som baggrund gemt som billeder

### I stedet

- Heltebilledet indlæses med det samme med `fetchpriority="high"`
- Angiv begge attributter på hvert img
- `srcset` med tre eller fire bredder
- SVG eller PNG til flad grafik
- CSS-forløb, med korn om nødvendigt

De tip hænger direkte sammen med Core Web Vitals. Heltebilledet er ofte det element, der udgør Largest Contentful Paint, som [web.dev](https://web.dev/articles/lcp) foreslår bør tegnes inden for 2,5 sekunder, og manglende mål er en klassisk årsag til layoutskift. Hvis dit heltebillede er en video i stedet for et billede, gælder den samme tankegang i [videobaggrunde til hjemmesider](https://gradiently.design/da/guide/video-background-website).

## En tjekliste før du udgiver

1. **Mål pladsen** Find den største viste bredde for hvert billede i dit layout.
2. **Eksportér i de rette størrelser** En til to gange pladsens bredde, plus mindre versioner til telefoner.
3. **Vælg formatet** AVIF eller WebP til fotos og farveforløb, SVG til logoer, PNG kun når det vinder.
4. **Komprimér med øjet** Sænk kvaliteten, til du ser en ændring, og hæv den så ét trin.
5. **Skriv markup** `srcset`, `sizes`, `width`, `height`, `alt` og lazy loading under folden.
6. **Test det** Kør Lighthouse i et inkognitovindue, og tjek billedrevisionerne og LCP-elementet.

Meget af det her bliver lettere, når billedet allerede er lavet i sin endelige størrelse. I Gradiently designer du én gang, og Pro ændrer størrelsen til alle formater i ét trin og eksporterer derefter PNG, JPG eller SVG i præcise mål op til 4K, så heltebilledet, banneret og [Open Graph-billedet](https://gradiently.design/da/guide/open-graph-tags) hver især starter i den størrelse, siden viser.

## FAQ

### Hvordan optimerer jeg billeder til web uden at miste kvalitet?

Eksportér i den viste størrelse, brug AVIF eller WebP, sænk kun kvalitetsindstillingen, indtil du kan se en forskel, og lever flere størrelser med srcset. Det meste synlige tab kommer af hård komprimering, ikke af ændring af størrelsen.

### Hvad er det bedste billedformat til hjemmesider?

WebP er det sikre moderne valg, og AVIF er som regel endnu mindre. Brug SVG til logoer og ikoner, og behold JPEG eller PNG som reserver.

### Skal jeg lazy loade alle billeder?

Nej. Lazy load billeder under folden, men indlæs det store heltebillede med det samme, for en forsinkelse gør Largest Contentful Paint langsommere.

### Hvor store skal billeder på en hjemmeside være?

Cirka dobbelt så brede som den bredde, de vises i, til skarpe skærme med høj tæthed. Et heltebillede i fuld bredde på 1920 px dækker de fleste skærme.

### Hvorfor siger Lighthouse, at mine billeder ikke har den rette størrelse?

Filen har flere pixels end den plads, den fylder på siden. Eksportér en mindre version, og brug srcset og sizes, så browseren vælger den rigtige.
