Anpassa bildstorlekar på rätt sätt

Mät det bredaste bilden någonsin visas i, dubbla det för högupplösta skärmar och ändra storlek på ditt bibliotek till det värdet. Att visa ett fotografi på 4000 pixlar i ett utrymme på 800 pixlar innebär att webbläsaren laddar ner ungefär 25 gånger mer pixeldata än den kan visa, för att sedan kasta resten.

Med en mobilanslutning får besökaren betala för alltihop, både i tid och data. Att anpassa bilders storlek rätt är oftast den enskilt största minskningen av sidstorlek som kan göras på en webbplats, och det kräver bara en batchbearbetning istället för en omdesign.

Varför för stora bilder kostar så mycket

Filstorleken skalar med antalet pixlar, så att halvera bredden och höjden tar bort cirka 75 procent av datamängden. Förhållandet är kvadratiskt snarare än linjärt, vilket är anledningen till att slöseriet växer snabbt.

Den första raden visar det vanliga fallet på webbplatser där redaktörer laddar upp direkt från en kamera. Webbläsaren laddar ner 4,2 MB, skalar ner bilden och visar motsvarigheten till en fil på 180 KB.

Så mäter du den faktiska visningsstorleken

Högerklicka på bilden på din publicerade sida, välj Inspektera och läs av den visade storleken istället för ursprung storleken. Webbläsare visar båda siffrorna, och avståndet mellan dem utgör slöseriet.

Kontrollera det bredaste läget snarare än det typiska. En bild i en artikelspalt kan visas i 700 pixlar på en dator och 380 på en mobil, så 700 är siffran som räknas. Testa i det bredaste webbläsarfönstret dina besökare realistiskt använder, eftersom en banner i fullbredd växer med skärmstora och kräver en annan beräkning.

Dubbleringsregeln för högupplösta skärmar

Multiplicera visningsbredden med 2 och stanna där, eftersom skärmar utöver den pixeltätheten inte visar någon ytterligare förbättring som någon märker. En bild som visas i 700 pixlar bör exporteras i 1400.

Att tredubbla föreslås ibland men är sällan motiverat. Skillnaden mellan 2 och 3 gångers täthet går inte att upptäcka på normalt visningsavstånd, samtidigt som filen växer med mer än hälften. Att komprimera hårdare vid 2 gångers täthet ger ett bättre resultat än att komprimera lätt vid 3 gånger, eftersom de extra pixlarna döljer komprimeringen.

Vanliga visningsbredder att ändra storlek för

• Bild i artikelbrödtext: visas runt 700 px, exportera i 1400 px.
• Hero-bild i fullbredd: visas upp till 1920 px, exportera i 1920 px och komprimera hårdare.
• Funktionsbild i halvbredd: visas runt 600 px, exportera i 1200 px.
• Miniatyrbild i produktraster: visas runt 300 px, exportera i 600 px.
• Författar- eller profilfoto: visas runt 80 px, exportera i 160 px.
• Logotyp i en sidhuvud: visas runt 180 px, exportera i 360 px eller använd vektorgrafik.

Varför bilder i fullbredd är undantaget

En banner i fullbredd har ingen fast visningsstorlek, så begränsa den till 1920 pixlar och komprimera den hårdare istället för att dubblera. Att dubblera en bild i fullbredd till 3840 pixlar skapar en fil som ingen webbsida kan motivera.

Banners betraktas vanligtvis på avstånd och innehåller färre fina detaljer än ett produktfoto, vilket gör att aggressiv komprimering märks mindre. En banner på 1920 pixlar med kvalitet 70 i WebP hamnar typiskt under 200 KB och ser bra ut på alla skärmar, medan versionen på 3840 pixlar inte ger någon synlig fördel till 4 gånger vikten.

Så åtgärdar du ett helt bibliotek

Följ dessa 6 steg för att ändra storlek på en befintlig webbplats på rätt sätt.

1. Lista bildutrymmena i din design, vilket oftast rör sig om 4 till 6 distinkta storlekar snarare än dussintals.
2. Mät visningsbredden för varje utrymme med hjälp av webbläsarens granskningsverktyg på den levande sidan.
3. Dubbla varje bredd för att få din exportstorlek.
4. Sortera biblioteket i mappar utifrån utrymme, eftersom en batch tillämpar en storlek på alla filer i den.
5. Ändra storlek på varje mapp till dess målbredd, komprimera sedan och konvertera i samma moment.
6. Ersätt filerna med samma namn så att befintliga sidor fortsätter att fungera.

Att sortera i mappar är steget som gör detta till ett batchjobb. De flesta webbplatser använder betydligt färre unika bildstorlekar än de tror, och att gruppera efter utrymme tar bort behovet av att hantera filer individuellt.

Responsiva bilder och srcset-attributet

Använd srcset för att erbjuda flera storlekar och låta webbläsaren välja rätt bild för varje enhet. En mobil laddar då ner en fil på 400 pixlar medan en dator laddar ner en fil på 1400 pixlar från samma kod.

Generera 3 bredder per bild, vanligtvis 400, 800 och 1600 pixlar, och lista dem med deras pixelbredder så att webbläsaren kan välja. De flesta publiceringssystem skapar detta automatiskt vid uppladdning, så kontrollera vad din plattform redan gör. Om den gör det förbättrar en korrekt dimensionerad originalbild ändå varje genererad variant.

Ändra alltid storlek före komprimering

Att ändra storlek först innebär att komprimeringen har mindre arbete att göra, så kvaliteten kan förbli hög medan filen hålls liten. Att komprimera först och ändra storlek efteråt kastar bort detaljer som du sedan slänger igen.

Ordningen påverkar också hur resultatet ser ut. En bild som komprimeras i full storlek innehåller artefakter som blir mer synliga när bilden skalas ner, eftersom artefakterna skalas med den. Att ändra storlek först ger en renare källfil för kodaren och ett märkbart bättre resultat vid samma filstorlek.

Vad detta gör för sidhastigheten

Rätt storleksanpassning av bilder tar vanligtvis bort 60 till 90 procent av bildvikten på en webbplats som aldrig har gjort det tidigare. Förbättringen är större än någon formatändring och oftast större än alla andra optimeringar tillsammans.

Effekten märks mest för mobilbesökare, där anslutningarna är långsammare och data kostar pengar. Largest Contentful Paint förbättras direkt, eftersom det måttet normalt avgörs av en enda stor bild. Att klara granskningen Properly size images i Lighthouse rensar ofta 2 eller 3 relaterade varningar samtidigt.

Förstora aldrig en bild för att fylla ut

Att förstora lägger till pixlar som kameran aldrig fångade, så resultatet blir oskarpt och filen växer utan nytta. Att förminska är alltid säkert, medan förstoring är den åtgärd som garanterat ser sämre ut.

Om en källbild är mindre än utrymmet den måste fylla är de ärliga alternativen att använda den i sin naturliga storlek, beskära layouten runt den eller ersätta bilden. Att förstora ett fotografi på 600 pixlar till 1600 pixlar ger en suddig fil som väger 4 gånger mer än originalet, vilket misslyckas med både kvalitet och hastighet samtidigt.

Sök igenom en sida efter för stora bilder

Öppna utvecklarverktygen, växla till fliken Nätverk, filtrera på bilder och läs in sidan igen. Listan visar varje bild med dess överförda storlek, sorterad med den största först.

Vilken enskild bild som helst över 500 KB är värd att undersöka, och varje sida där bilderna totalt överstiger 2 MB har ett problem. Håll muspekaren över en bild i panelen Element för att se dess ursprungliga och visade storlek sida vid sida. Ett stort gap mellan de 2 siffrorna är själva definitionen av en felaktigt dimensionerad bild, och det syns på några sekunder.

Ändra storlek på ett bibliotek i en enda omgång

Ställ in målbredden en gång och tillämpa den på alla filer i en mapp, istället för att ändra storlek på bilder en och en. Ett bibliotek med flera hundra bilder ändras i storlek på några minuter när arbetet körs i en batch.

Släpp in upp till 500 filer samtidigt, eller dra ett ZIP-arkiv rakt in, och ställ in bredd, format och komprimeringsmål för hela uppsättningen. Allt körs i din webbläsare på din egen processor, så kundwebbplatser, staging-filer och opublicerade gallerier når aldrig en server. Ingenting laddas upp, vilket innebär att en storleksändring av ett helt bibliotek sker utan att en enda fil skickas över nätverket.