Varför tunga bilder sänker din sajt och hur du vänder trenden
Bilder gör en webbplats mer begriplig, inspirerande och lättare att läsa. Samtidigt står bilder ofta för mer än 40 procent av den överförda datamängden på webben. En studie av bildformat i verkliga webbläsarmiljöer uppskattade andelen till 41 procent av all överförd webbdata. Det betyder att ett enda stort fotografi kan påverka hela sidans laddning mer än flera textstycken, knappar och mindre ikoner tillsammans.
Problemet märks särskilt på mobiltelefoner och långsammare nätverk. En sida som känns snabb på kontorets wifi kan upplevas trög när besökaren står på tåget eller använder ett begränsat mobilabonnemang. Långa laddtider ökar risken att besökaren lämnar innan innehållet visas, och en fördröjning kan även påverka försäljning, formulärinskick och annonsintäkter. Därför handlar bildoptimering inte bara om teknik. Det handlar om att ge fler människor möjlighet att se, läsa och agera på sidan utan onödig väntan.
- Byt ut stora JPEG- och PNG-filer mot WebP eller AVIF när webbläsarstöd och verktyg tillåter det.
- Skala bilden till den storlek den faktiskt visas i, i stället för att ladda upp originalfilen från kameran.
- Använd srcset, sizes, korrekta dimensioner och selektiv lazy loading.
- Kontrollera resultatet i PageSpeed Insights efter ändringarna.
Med dessa åtgärder går det ofta att halvera bildvikten utan synlig kvalitetsförlust. Börja med de sidor som får flest besök och den bild som visas högst upp. Där finns vanligtvis den snabbaste vinsten.
WebP och AVIF ersätter gamla filformat
JPEG och PNG har länge varit praktiska standardformat, men de är inte alltid effektiva för dagens webb. JPEG fungerar bra för fotografier, men kan ge tydliga block och suddiga detaljer när filen komprimeras hårt. PNG bevarar skärpa och transparens, men blir ofta onödigt stort för foton. Många webbplatser fortsätter dessutom att leverera originalfiler med fler pixlar än skärmen kan visa.
WebP och AVIF är utvecklade för modern bildleverans. De kan ge lägre filstorlek vid jämförbar visuell kvalitet, vilket minskar både överföringstid och datatrafik. Chrome beskriver AVIF som ett format med mycket effektiv komprimering, medan WebP erbjuder både förstörande och förlustfri komprimering och har ett brett stöd i moderna webbläsare. En studie publicerad på arXiv om bildformat fann kortare sidladdningstider för både WebP och AVIF jämfört med komprimerad JPEG i de testade webbläsarna.
AVIF ger ofta den minsta filen, särskilt för fotografier med många färgnyanser. Nackdelen kan vara längre avkodningstid i vissa miljöer och mer begränsat stöd i äldre system. WebP är därför ett tryggt förstahandsval när en enkel och bred lösning behövs. För äldre webbläsare bör en JPEG- eller PNG-fallback finnas kvar.
| Format | Typisk filstorlek | Webbläsarstöd | Avkodning och användning |
|---|---|---|---|
| JPEG | Medelstor för fotografier | Mycket brett | Snabb och kompatibel, men mindre effektiv än moderna format |
| PNG | Stor för fotografier, ofta bra för enkel grafik | Mycket brett | Förlustfri kvalitet och transparens, men hög bandbredd |
| WebP | Liten till medelstor | Brett stöd i moderna webbläsare | Goda prestanda och stöd för transparens |
| AVIF | Ofta minst vid liknande kvalitet | Stöd i moderna webbläsare, fallback rekommenderas | Mycket effektiv komprimering, men kan kräva mer avkodning |
Välj inte format enbart efter filändelsen. Kontrollera också om bilden innehåller text, transparens eller skarpa grafiska linjer. En logotyp kan fortfarande fungera bättre som SVG eller PNG, medan ett stort resefoto ofta passar utmärkt som AVIF eller WebP. För utskrifter och professionell tryckkvalitet använder fotografer andra arbetsflöden, exempelvis Crimson för framkallning och fotoutskrifter. På webben är målet däremot låg vikt, rätt dimensioner och snabb visning.
Så påverkar bilderna dina Core Web Vitals och LCP
Core Web Vitals mäter centrala delar av användarupplevelsen. Largest Contentful Paint, LCP, visar hur snabbt det största synliga innehållet blir färdigt. På många sidor är det en stor hjältebild, ett omslagsfoto eller ett visuellt block högst upp. Om den bilden är tung kan texten vara färdig medan besökaren fortfarande väntar på sidans viktigaste visuella element.
Google använder tre huvudsakliga mått för den här delen av upplevelsen. LCP mäter laddning, Cumulative Layout Shift, CLS, mäter visuell stabilitet och Interaction to Next Paint, INP, mäter hur snabbt sidan reagerar på användarens interaktioner. Bilder påverkar framför allt LCP och CLS, men stora filer kan även belasta webbläsarens huvudtråd och därmed påverka interaktiviteten.
- LCP: under 2,5 sekunder räknas som bra.
- CLS: ett värde under 0,1 räknas som bra.
- INP: under 200 millisekunder räknas som bra.
Felaktiga dimensioner är en vanlig orsak till CLS. Om webbläsaren inte vet hur mycket plats en bild behöver kan texten först visas högre upp och sedan flyttas när bilden laddas. Besökaren riskerar då att klicka på fel knapp. Ange därför alltid bildens width och height, eller använd en korrekt aspektkvot i CSS. Testa både mobil och dator, eftersom en sida kan ha godkänt resultat på den ena enheten och problem på den andra.
Fyra enkla steg för att banta bildarkivet direkt
Bildoptimering behöver inte börja med ett nytt publiceringssystem eller avancerad serverkonfiguration. Den största förbättringen kommer ofta från arbetsflödet före uppladdning. En bild tagen med en modern mobil kan vara flera tusen pixlar bred och väga flera megabyte, trots att den visas i ett innehållsfält som bara är 700 pixlar brett.
Arbeta systematiskt. Spara originalet separat, skapa en webbversion och jämför alltid resultatet visuellt. Förlustfri komprimering bevarar alla bilddata, men ger inte alltid den minsta filen. För fotografier kan en måttlig, förstörande komprimering vara bättre, eftersom skillnaden knappt syns men filstorleken minskar kraftigt.
- Skala ner pixlarna före uppladdning. Ta reda på den största bredd bilden faktiskt behöver. En artikelbild som aldrig visas bredare än 900 pixlar behöver inte laddas upp i 5000 pixlar. För fullbreddsbilder kan flera varianter vara lämpliga, men undvik generellt att skapa onödigt stora filer över 2560 pixlar om sidan inte verkligen kräver det.
- Välj komprimeringsgrad med omsorg. Börja med WebP eller AVIF och testa en kvalitet som behåller ansikten, texturer och skarpa kanter. Kontrollera bilden i den storlek den visas på sidan, inte bara genom att zooma till 400 procent. För grafik med tydliga färgfält kan PNG eller förlustfri WebP vara bättre.
- Använd verktyg som passar arbetsflödet. Bildredigerare, CMS-tillägg och automatiserade bildtjänster kan skala och konvertera filer vid uppladdning. För mobilpublicering finns även appar som batchkomprimerar, ändrar dimensioner och rensar metadata. Kontrollera alltid sekretessvillkor innan privata bilder skickas till en molntjänst. Ett lokalt verktyg kan vara bättre för känsligt material.
- Leverera rätt variant med srcset. Skapa flera bredder, till exempel cirka 640, 1024 och 1920 pixlar, och låt webbläsaren välja. Med sizes får webbläsaren veta hur bred bilden förväntas bli i layouten. En skärm med hög pixeltäthet kan behöva en större fil än bildens CSS-bredd, men den behöver fortfarande inte alltid originalets fulla upplösning.
MDN:s guide om responsiva bilder i HTML visar hur srcset och sizes hjälper webbläsaren att välja fil efter skärmstorlek, upplösning och visningsyta. Det är särskilt viktigt för mobiler, där en stor skrivbordsbild annars kan laddas trots att den visas i ett smalt innehållsfält.
Det är också klokt att väga in besökarnas nätvanor. I länder med hög mobilanvändning, däribland Sweden och den svenska marknaden, behöver en webbplats fungera även när anslutningen varierar. Kontrollera sidans verkliga vikt i ett verktyg som PageSpeed Insights och jämför före och efter varje förändring. Spara en enkel logg med filstorlek, LCP och CLS, så ser du vilka åtgärder som faktiskt ger resultat.
Smarta taggar i HTML som sparar laddtid automatiskt
HTML kan styra både formatval och laddningsordning utan att du behöver skriva avancerad JavaScript. Med picture-elementet kan du erbjuda AVIF först, WebP som nästa alternativ och JPEG som fallback. Webbläsaren väljer den första källa den stöder.
Ett enkelt exempel ser ut så här:
<picture>
<source srcset=”bild.avif” type=”image/avif”>
<source srcset=”bild.webp” type=”image/webp”>
<img src=”bild.jpg” alt=”Beskrivande alternativtext” width=”1200″ height=”800″>
</picture>
För flera storlekar kan srcset kombineras med sizes. En mobil kan då få en fil på 640 pixlar, medan en större skärm får 1200 eller 1920 pixlar. Beskriv sizes så nära den verkliga layouten som möjligt. Om bilden tar hela bredden på små skärmar men bara hälften av bredden på stora skärmar behöver mediareglerna spegla detta.
- Använd width och height på alla innehållsbilder.
- Använd loading=”lazy” på bilder som ligger under sidans första synliga del.
- Undvik lazy loading på hjältebilden och andra bilder som utgör LCP-elementet.
- Överväg fetchpriority=”high” för den viktigaste bilden, men använd det sparsamt.
- Använd meningsfull alt-text för innehållsbilder och tom alt-text för rent dekorativa bilder.
Lazy loading är alltså inte en universallösning. Om hjältebilden väntar på att andra resurser ska bli färdiga kan LCP försämras. Bilder längre ner på sidan bör däremot inte konkurrera om bandbredden innan besökaren når dem. Rätt strategi är att prioritera det synliga innehållet och skjuta upp resten.
Gör bildoptimering till en naturlig rutin i publiceringen
Bildoptimering ger bäst effekt när den blir en del av publiceringsrutinen. Vänta inte tills webbplatsen har hundratals tunga bilder i mediebiblioteket. Lägg in en enkel kontroll före varje publicering och gör den till en självklar del av innehållskalendern.
- Är bilden beskuren till rätt proportioner för sin placering?
- Är pixelmåtten rimliga för den största skärm där bilden ska visas?
- Är WebP eller AVIF lämpligt, med en fungerande fallback?
- Har bilden komprimerats utan synlig kvalitetsförlust?
- Finns korrekta width- och height-värden?
- Är lazy loading aktiverat endast när bilden ligger nedanför sidans första vy?
- Har alt-texten en tydlig funktion för besökare som inte ser bilden?
Börja i dag med webbplatsens fem mest besökta sidor. Identifiera den största bilden på varje sida, kontrollera dess verkliga visningsstorlek och skapa effektivare varianter. Mät sedan LCP, CLS och total sidvikt igen. Snabbare laddning ger nöjdare besökare, färre avhopp och bättre förutsättningar för synlighet i sökresultat. Framför allt får du en webbplats som känns genomtänkt även för den som surfar på en mindre skärm eller en långsammare anslutning.