WebperfDet finns mycket att tänka på när man utsmyckar sin webbplats, men också när man fyller den med redaktionellt innehåll. De som utsmyckar är oftast proffs på bildhantering, men inte alltid lika proffsiga på vad som gäller för webben och vilka villkor som webben ställer.
Sedan finns det ju redaktörer och alla vi andra som laddar upp material till webbplatser. Det är inte alltid vi får till det, inte heller säkert att vi får hjälp av de verktyg vi erbjuds.
Ibland har man bilder via en mediabank, där mediabanken som gör jobbet åt en, ibland laddar man upp dem manuellt. Idagsläget när alla till sist köpt in på att webbplatser måste vara responsiva ner till en mindre skärm så uppstår ännu ett bekymmer - nämligen att de små skärmarna ofta har högre upplösning än de stora, och därför kan dra nytta av mer detaljrika bilder.
Samtidigt är de små skärmarna, mobiltelefoner i de flesta fall, också behäftade med den stora nackdelen av att ha en trådlös och ibland svajig uppkoppling. Det innebär att även normalupplösta bilder upplevs som jättesega att ladda ner.
Bildhantering för webben är med andra ord svårare än någonsin.
1. Bilder bör vara i den upplösning som de ska visas
Här kommer ett ytterligare krux, nämligen att de flesta responsiva webbplatser har flytande kolumnbredd. Så som nästan alla designat det så finns bilder som fyller hela kolumnens bred.
Ta då som ett tankeexempel att på webbplatsen för Acme AB kan mittkolumnen vara mellan 300->500 pixlar bred. Bilden som visas i toppen i den kolumnen ska vara lika bred som kolumnen för att det ska se klokt ut.
Väljer du då att ladda upp bilder som är 500 eller 300 pixlar breda?
Säg att bilden har ett 2:1-förhållande, då blir 500 pixlarsbildens bredd 250 = 125 000 pixlar. Är den istället 300 bred blir den 150 hög = 45 000 pixlar.
Det är en väldans skillnad på bildyta och ditt val kommer definitivt att påverka prestandan.
Som lök på laxen har vi idag (enligt vissa det angenäma) problemet med högupplösta skärmar. Vad Apple-användare kallar för retina. Det innebär ofta dubbelt så hög upplösning, det vill säga att varje pixel blir fyra för att nå maximal skärpa.
Ovan bild skulle alltså vara 1000 x 500 = 500 000 pixlar för att vara riktigt skarp.
Vågar du skicka en sådan bild till en mobiltelefon som eventuellt är uppkopplad på ett tveksamt mobilnät ute i glesbygden?
Här får du göra en avvägning, men som jag hoppas du förstått är detta inget man kan göra utan eftertanke. Grundregeln är förrädiskt enkel: bilder ska vara i den upplösning som de visas, samt att man inte ska skala ner dem med HTML eller CSS.
Oroar du dig över detta så läs gärna på om responsiva bilder på nätet, dessutom har jag lite mer om det i min bok.
2. Bilder ska sparas i lämpligt format
Grundregeln är att bilder ska vara sparade i det format som möjliggör minst filstorlek i relation till bildkvalitet.
De flesta känner till formaten GIF (uttalas tydligen jiff enligt tyckare…), JPG och PNG som något man stöter på på webben. Dessa format har sina styrkor och svagheter, extremt kortfattat:
- GIF stödjer animationer och transparens, men endast 256 färger. Effektivt just för animationer och ibland enkla illustrationer, som logotyper.
- JPG är ett format för fotografier. Väldigt bra på alla bilder som saknar ytor med en och samma färg - om sånt inträffar brukar de “blöda” och visa rosa och gröna fläckar om det komprimerats.
- PNG har två varianter, ett på 8 bitar och ett på 24 bitar. Den på 8 bitar har likheter med GIF då man kan ha maximalt 256 färger. Vid 24 bitar får man även transparens samt att den då stödjer miljontals färger. PNG är mest effektiv som 8 bitars och för illustrationer, informationsgrafik, logotyper med mera.
Sedan tillkommer initiativ som WebP från Google, det funkar än så länge bara i Chrome och Opera. Vi får väl se hur det går.
3. Bilder behöver sparas för webben
När du valt rätt format behöver en bild sparas för webben. Detta finns i alla bildbehandlingsprogram jag stött på. Det kan vara så att om du tvekar på om du valt rätt format kollar de andra formaten när du väl sparar för webben. Åtminstone Photoshop stödjer detta genom att man högst upp i högra hörnet på dialogrutan kan välja format.
Om du väljer PNG så kolla gärna om filen blir mindre och fortfarande ser ok ut som 8-bitars, gärna med så få färger som möjligt. Efter ett tag får man rätt bra känsla för vilka bilder som kanske funkar som annat bildformat.
Som JPG-fil kan du dels lite grovhugget välja nivå av komprimering, men det finns också ett reglage där du kan välja mellan 0–100 hur mycket kvalitet du vill bevara. Var vaksam på ytor med samma färg eller nyans, och särskilt på hud på människor där vi tycks vara extra känsliga då någon kan upplevas som sjuk om bilden optimerats för hårt.
Det du kommer se vid för hård optimering är att detaljrikedomen tycks försvinna, att det uppstår missfärgade rutor av oftast grönt och rosa. Klipp in en bit vitt i ett foto och komprimera stenhårt så ser du vad jag menar.
En GIF-fil resonerar du som en 8-bitars PNG ovan.
4. Kör bilder genom icke-förstörande optimering
Ok, nu har du alltså redan tagit tre steg för att en bild ska gå snabbt att ladda hem. När blir vi klara egentligen? Ja, detta är det sista steget i den process jag själv tar.
Det vi nu gör är att ta bort helt osynlig onödig data ur bilden - så kallad icke-förstörande optimering. Poängen är att optimeringen inte ska gå att upptäcka med blotta ögat, men ibland kan filerna bli väldigt mycket mindre. Räkna dock med att minst 5 % går att hyvla bort på precis vilken bild som helst.
Jag som kör Mac använder det fantastiska programmet ImageOptim. Det funkar så förträffligt att jag drar en massa bilder (kanske hela webbens bildmapp) till programmets fönster och sedan optimeras alla bilder och skrivs över på sin nuvarande plats. Efter det laddar man upp bilderna.
För dig som inte kör eller har tillgång till en Mac kan jag rekommendera imgopt.com (finns även som plugin i Wordpress, EWWW Bildoptimerare) som gör samma sak fast lite mer omständligt. Annars kan du kolla in listan med alternativ till ImageOptim, där har jag kört Shrink O’Matic på min Windows-dator.
