# Optimera bilder för webben utan att tappa kvalitet
[Canonical HTML page](https://gradiently.design/sv/guide/lighthouse-image-performance)
Bilder är oftast det tyngsta på en sida och orsaken till att Lighthouse klagar. Här är en metod som fungerar: rätt pixelstorlek, rätt format, responsiv kod och laddningstips, utan synlig förlust.
## The short version
- För att optimera bilder för webben exporterar du varje bild i den storlek den visas, ungefär dubbelt så stor för skärmar med hög pixeltäthet, i stället för att ladda upp originalet.
- AVIF och WebP ger mycket mindre filer än JPEG och PNG med liknande bildkvalitet, och alla aktuella webbläsare stöder WebP.
- Attributen srcset och sizes låter webbläsaren hämta den minsta bild som ändå ser skarp ut på respektive skärm.
- Ladda bilder under vecket med loading="lazy", men ladda den stora huvudbilden direkt med fetchpriority="high", eftersom den oftast avgör Largest Contentful Paint.
- Ange alltid width och height på bilder så att webbläsaren reserverar plats och layouten inte hoppar medan de laddas.
För att **optimera bilder för webben** utan synlig förlust gör du fem saker: exportera varje bild i den pixelstorlek den visas (ungefär dubbelt så stor för skarpa skärmar), välj ett modernt format som AVIF eller WebP, komprimera till måttlig kvalitet och jämför med blotta ögat, servera flera storlekar med `srcset` och ladda allt under vecket med lazy loading. De stegen löser det mesta av Lighthouses bildvarningar och minskar oftast sidans vikt rejält, eftersom originalfotot direkt från kameran eller designverktyget är många gånger större än skärmen behöver.
## Steg 1: exportera i den storlek du visar
En bild som visas 800 pixlar bred behöver inte vara 4 000 pixlar bred. Lighthouse flaggar för stora bilder eftersom de extra pixlarna laddas ner, avkodas och slängs. Mät hur bred bilden är i din layout som störst och exportera sedan i ungefär dubbla bredden för telefoner och laptops med hög pixeltäthet. Mer än dubbelt blir sällan skarpare och kostar alltid byte.
| Bild | Visas i | Exportbredd |
| --- | --- | --- |
| Hero i full bredd | Upp till 1920 px | 1920 px, plus mindre versioner |
| Artikelbild | Cirka 720 px | 1440 px |
| Miniatyr på kort | Cirka 360 px | 720 px |
| Avatar | 48 px | 96 px |
| Open Graph-bild | Utanför sajten | Exakt 1200×630 |
Vanliga mål. En hero i full bredd är undantaget från regeln om dubbel storlek: 1920 px täcker de flesta skärmar, och mycket stora skärmar får en något mjukare bild till rimlig kostnad.
- Webbhero 1920×1080: 1920 × 1080
- Bloggbanner 1200×600: 1200 × 600
- Länkförhandsvisning 1200×630: 1200 × 630
Tre vanliga webbbildstorlekar ritade i skala. Designa i slutstorleken så att inget beskärs eller skalas efter exporten.
## Steg 2: välj rätt format
Formatet betyder mer än något kompressionsreglage. AVIF ger oftast minsta filen, WebP kommer nära och stöds överallt i aktuella webbläsare, och JPEG och PNG är de säkra reservalternativen. [WebP eller PNG](https://gradiently.design/sv/guide/webp-images) och [PNG eller JPG](https://gradiently.design/sv/guide/png-vs-jpeg) går djupare in på varje par.
| Format | Bäst för | Anmärkningar |
| --- | --- | --- |
| AVIF | Foton, gradienter, stora heroes | Minsta filerna, långsammare att koda |
| WebP | Nästan allt | Förlustfri och förlustbehäftad, transparens, brett stöd |
| JPEG | Foton, som reserv | Ingen transparens, ger band i mjuka gradienter |
| PNG | Skärmbilder, platt grafik, transparens | Förlustfri men stor för foton |
| SVG | Logotyper, ikoner, illustrationer | Vektor, pytteliten när den är enkel, se [SVG eller PNG](https://gradiently.design/sv/guide/svg-vs-png) |
Välj efter innehåll, inte vana. Mjuka gradienter är det svåraste fallet för JPEG, och där hjälper WebP och AVIF mest.
> **Gradienter komprimeras dåligt** Mjuka färgövergångar visar kompressionen som synliga steg. Lägg på lite korn före exporten, som beskrivs i [bandning i gradienter](https://gradiently.design/sv/guide/gradient-banding), så kan kodaren jobba hårdare utan att någon ser det. Ännu bättre: rita webbgradienter i CSS.
En hero-gradient på ungefär 70 byte: `linear-gradient(160deg, #0f172a 0%, #1e3a8a 50%, #0ea5e9 100%)`
Den här gradienten kostar som CSS mindre än en enda rad på sidan. Exporterad som en bild på 1920×1080 skulle samma sak väga många kilobyte. Se [prestanda för CSS-gradienter](https://gradiently.design/sv/guide/css-gradient-performance).
## Steg 3: komprimera, och titta sedan
Förlustbehäftade format har en kvalitetsinställning, och rätt värde beror på bilden. Börja runt 75 till 80 för WebP och runt 50 till 60 för AVIF, exportera och jämför med originalet i 100 % zoom. Sänk tills du ser skillnad och gå sedan upp ett steg igen. Ansikten, liten text och gradienter behöver högre kvalitet än livliga landskap. [Bildkomprimering](https://gradiently.design/sv/guide/image-compression) förklarar vad kodaren kastar bort.
Ta bort metadata som kameradetaljer och inbäddade miniatyrer samtidigt. De flesta exportverktyg gör det med en enda ruta, och det tar bort byte som ingen ser.
## Steg 4: responsiv kod med srcset och sizes
När du exporterat flera bredder låter du webbläsaren välja. `srcset` listar filerna och deras bredder, och `sizes` talar om hur bred bilden kommer att visas. Webbläsaren hämtar då den minsta fil som är tillräckligt skarp för den skärmen.
```html
```
Webbläsaren använder den första källan den stöder. Elementet img är både reserv och platsen för alt, width, height och laddningstips.
För en bild i en kolumn beskriver du layouten i `sizes`, till exempel `sizes="(min-width: 1024px) 720px, 100vw"`. Fel `sizes` är den vanligaste orsaken till att en responsiv uppsättning ändå hämtar den stora filen.
## Steg 5: laddningstips som spelar roll
```html
```
Med width och height kan webbläsaren reservera plats utifrån bildförhållandet, så att inget flyttar sig när bilderna kommer. CSS kan ändå göra bilden flytande med max-width: 100% och height: auto.
### Vanliga misstag
- `loading="lazy"` på hero-bilden
- Ingen width och height, så sidan hoppar
- En enda jättefil för alla skärmar
- En JPEG av en platt logotyp eller skärmbild
- Gradientbakgrunder sparade som bilder
### Gör så här i stället
- Hero laddas direkt med `fetchpriority="high"`
- Sätt båda attributen på varje img
- `srcset` med tre eller fyra bredder
- SVG eller PNG för platt grafik
- CSS-gradienter, med korn vid behov
De här tipsen hör direkt ihop med Core Web Vitals. Hero-bilden är ofta elementet för Largest Contentful Paint, som [web.dev](https://web.dev/articles/lcp) menar bör renderas inom 2,5 sekunder, och saknade mått är en klassisk orsak till layoutskift. Om din hero är en video i stället för en bild gäller samma tänk i [videobakgrunder för webbplatser](https://gradiently.design/sv/guide/video-background-website).
## En checklista före publicering
1. **Mät platsen** Ta reda på största visade bredd för varje bild i din layout.
2. **Exportera i rätt storlekar** En till två gånger platsens bredd, plus mindre versioner för telefoner.
3. **Välj format** AVIF eller WebP för foton och gradienter, SVG för logotyper, PNG bara när det vinner.
4. **Komprimera med ögat** Sänk kvaliteten tills du ser en skillnad och höj den sedan ett steg.
5. **Skriv koden** `srcset`, `sizes`, `width`, `height`, `alt` och lazy loading under vecket.
6. **Testa** Kör Lighthouse i ett inkognitofönster och kontrollera bildgranskningarna och LCP-elementet.
Mycket av det här blir enklare när bilden görs i slutstorleken från början. I Gradiently designar du en gång och Pro ändrar storlek till alla format i ett steg, och exporterar sedan PNG, JPG eller SVG i exakta mått upp till 4K, så att hero, banner och [Open Graph-bild](https://gradiently.design/sv/guide/open-graph-tags) alla utgår från den storlek sidan visar.
## FAQ
### Hur optimerar jag bilder för webben utan att tappa kvalitet?
Exportera i visad storlek, använd AVIF eller WebP, sänk kvalitetsinställningen bara tills du ser en skillnad och servera flera storlekar med srcset. Det mesta av den synliga förlusten kommer från hård komprimering, inte från storleksändring.
### Vilket är det bästa bildformatet för webbplatser?
WebP är det säkra moderna standardvalet och AVIF är oftast ännu mindre. Använd SVG för logotyper och ikoner och behåll JPEG eller PNG som reserv.
### Ska jag lazy loada alla bilder?
Nej. Lazy loada bilder under vecket, men ladda den stora hero-bilden direkt, eftersom en fördröjning gör Largest Contentful Paint långsammare.
### Vilken storlek ska bilder på en webbplats ha?
Ungefär dubbla bredden mot den de visas i, för skarpa skärmar med hög pixeltäthet. En hero i full bredd på 1920 px täcker de flesta skärmar.
### Varför säger Lighthouse att mina bilder inte har rätt storlek?
Filen har fler pixlar än den yta den fyller på sidan. Exportera en mindre version och använd srcset och sizes så att webbläsaren väljer rätt.
```
Med width och height kan webbläsaren reservera plats utifrån bildförhållandet, så att inget flyttar sig när bilderna kommer. CSS kan ändå göra bilden flytande med max-width: 100% och height: auto.
### Vanliga misstag
- `loading="lazy"` på hero-bilden
- Ingen width och height, så sidan hoppar
- En enda jättefil för alla skärmar
- En JPEG av en platt logotyp eller skärmbild
- Gradientbakgrunder sparade som bilder
### Gör så här i stället
- Hero laddas direkt med `fetchpriority="high"`
- Sätt båda attributen på varje img
- `srcset` med tre eller fyra bredder
- SVG eller PNG för platt grafik
- CSS-gradienter, med korn vid behov
De här tipsen hör direkt ihop med Core Web Vitals. Hero-bilden är ofta elementet för Largest Contentful Paint, som [web.dev](https://web.dev/articles/lcp) menar bör renderas inom 2,5 sekunder, och saknade mått är en klassisk orsak till layoutskift. Om din hero är en video i stället för en bild gäller samma tänk i [videobakgrunder för webbplatser](https://gradiently.design/sv/guide/video-background-website).
## En checklista före publicering
1. **Mät platsen** Ta reda på största visade bredd för varje bild i din layout.
2. **Exportera i rätt storlekar** En till två gånger platsens bredd, plus mindre versioner för telefoner.
3. **Välj format** AVIF eller WebP för foton och gradienter, SVG för logotyper, PNG bara när det vinner.
4. **Komprimera med ögat** Sänk kvaliteten tills du ser en skillnad och höj den sedan ett steg.
5. **Skriv koden** `srcset`, `sizes`, `width`, `height`, `alt` och lazy loading under vecket.
6. **Testa** Kör Lighthouse i ett inkognitofönster och kontrollera bildgranskningarna och LCP-elementet.
Mycket av det här blir enklare när bilden görs i slutstorleken från början. I Gradiently designar du en gång och Pro ändrar storlek till alla format i ett steg, och exporterar sedan PNG, JPG eller SVG i exakta mått upp till 4K, så att hero, banner och [Open Graph-bild](https://gradiently.design/sv/guide/open-graph-tags) alla utgår från den storlek sidan visar.
## FAQ
### Hur optimerar jag bilder för webben utan att tappa kvalitet?
Exportera i visad storlek, använd AVIF eller WebP, sänk kvalitetsinställningen bara tills du ser en skillnad och servera flera storlekar med srcset. Det mesta av den synliga förlusten kommer från hård komprimering, inte från storleksändring.
### Vilket är det bästa bildformatet för webbplatser?
WebP är det säkra moderna standardvalet och AVIF är oftast ännu mindre. Använd SVG för logotyper och ikoner och behåll JPEG eller PNG som reserv.
### Ska jag lazy loada alla bilder?
Nej. Lazy loada bilder under vecket, men ladda den stora hero-bilden direkt, eftersom en fördröjning gör Largest Contentful Paint långsammare.
### Vilken storlek ska bilder på en webbplats ha?
Ungefär dubbla bredden mot den de visas i, för skarpa skärmar med hög pixeltäthet. En hero i full bredd på 1920 px täcker de flesta skärmar.
### Varför säger Lighthouse att mina bilder inte har rätt storlek?
Filen har fler pixlar än den yta den fyller på sidan. Exportera en mindre version och använd srcset och sizes så att webbläsaren väljer rätt.