Webben är ett visuellt medium. Största delen av det visuella landskapet är tack vare bildfiler. Medan många kan uppnås med CSS och inline SVG behöver de flesta webbplatser fortfarande bildfiler.
I genomsnitt svarade bilderna mer än hälften av sidstorlek förra året, och år i år bildstorleken ökar; det var en 21% tillväxt i bildstorlek i 2014 ensam.
Samtidigt fortsätter antalet och mångfalden av enheter som använder webben att växa. Upplösningarna varierar nu var som helst mellan 72ppi (minskande vanligt) och över 600ppi.
Att skapa en bild för skärmen som är av tillräcklig kvalitet för en enhet är enkelt: spara det vid 1000ppi och ring det en dag. Den resulterande bilden kommer att vara skarp på även högst höga enheter. Men medan din kvalitet kommer att vara hög, så kommer din fila att storlek. Med sidladdningstid a nyckelfaktor i UX det är oss skyldiga att se till att webbplatser levereras till våra användare omedelbart. När bilderna är av sådan hög kvalitet att de tar ett dussin sekunder att ladda ner på bredbandsanslutningar, än mindre mobila anslutningar, så är de effektivt oanvändbara.
Syftet med responsiva bilder är då inte att leverera en bild av högre kvalitet till skärmar som kan visa det (vilket vi enkelt kan göra), syftet är att leverera den högsta kvaliteten som stöds och ingenting mer.
Denna guide är utformad för att lära dig vad som fungerar, där problemen och fallgroparna fortfarande ligger och hur du kan använda lyhörda bilder på webbplatser idag.
Jag känner behovet, behovet av hastighet
Varför går det med snabba saker? Säkerligen är ingen på en 3G-anslutning längre? Ingen använder uppringning. Om din kunds målsättning är att demografiskt bor på Manhattan, varför ska du bry dig om landsbygden Lesotho? Faktum är att det är en myt att vi alla är på super-snabbt bredband, sålda till oss av företag som dra nytta av önskan om allt högre hastigheter.
De flesta spenderar minst två timmar varje dag på en sämre anslutning. Jag befinner mig ofta med mest tid att bläddra när pendling, när även en tillförlitlig 3G-anslutning låter som en bortre dröm.
I april Google meddelade den mobila vänligheten skulle användas som en rankingfaktor för sökningar som utförts på enheter som den anser vara "mobila". Även före det, hastighet var en faktor i sidrankning - både uttryckligen som en del av Googles beräkningar och implicit som en bidragande faktor till din avvisningsfrekvens.
På två identiskt rankade platser kan en extra 1Kb släppa dig från 3: e plats på Google, till 4: e eller 5: e. Det kan till och med släppa dig från 10 till 11 - med andra ord från sida 1 till sida 2 - med all den därmed sammanhängande effekten på kundens intäkter.
Behöver du verkligen den bilden?
Den mest optimerade bilden finns, det finns ingen bild alls. Om du har fem bilder på din webbplats och du släpper en, har du sparat 20%, kanske ännu viktigare, du har sparat dig en http-förfrågan. Om vi tappade alla bilder från våra webbplatser skulle vi spara 100% och alla fem http-förfrågningarna. Så varför inte göra det?
Vi släpper inte bilder från våra webbplatser eftersom de kommunicerar mer effektivt än text på kort sikt. De skapar en känslomässig anslutning som drar användarna till innehåll.
Vi vet det Användarna läser inte webbsidor . Mycket få människor läser djupt innehåll online. Bilder tillåter oss att ansluta till, kommunicera och förstärka ett varumärke på en bråkdel av den tid som texten kan hantera.
Bilder kan vara stora och obehagliga att ladda ner, men en gång gjorda i webbläsaren är de mycket effektivare än än för att skapa användarengagemang och förstärka ett varumärkesmeddelande.
Responsiva bilder hjälper oss att se till att de känslomässiga kopplingsbilden bygger inte går förlorad när den otåliga användaren träffar bakåtknappen.
Vad sägs om SVG?
SVG (Scaleable Vector Graphics) är en av de sanna banbrytande teknologierna på webben. Det ligger så långt före kurvan att de flesta designers fortfarande inte har erkänt sin sanna potential.
SVG - som namnet antyder - är vektorbaserat. Det betyder att SVG-grafik är konstruerad från punkter, vinklar och avstånd. SVG är också - som namnet antyder - skalbar, vilket betyder att den kommer att visas lika bra på en 5k iMac eller en Android-smartphone, utan förlust av kvalitet och ingen ändring i filstorlek.
Om du har en platt illustration, en ikon, en logotyp, nästan vad som helst som kan visas som en SVG, är SVG vägen att gå.
De flesta bilder på webben är bitmappar. I allmänhet fungerar hur en bitmapp fungerar för att beskriva varje bildpunkt en åt gången, dess färg (i RGB - rött, grönt och blått värde) och i vissa fall dess öppenhet. Om du har en bild som mäter 100px med 100px, har du en bild med 10.000 pixlar; om varje pixel har 4 värden för att beskriva den, så har bilden 40.000 bitar av data som är associerade med den. Låter som mycket eller hur? Ibland är det mindre än en vektorgrafik.
Tänk på en 1px med 1px bild; det skulle kräva 4 bitar av data för att spela in som en bitmapp (röda, gröna, blåa och alfa-värden). Betrakta nu samma kvadratpixel som en vektor; det skulle kräva x, y, bredden och höjden av rektangeln, förutom RGBA-värdena.
Det är råa exempel, men de är korrekta. Ofta överstiger en vektorversion av en bild - om vi ens har en tillgänglig för oss - överstorlekens storlek för motsvarande bitmapp, och bitmap är det enda förnuftiga valet.
(Mis) använder JavaScript
Liksom de flesta problem i livet (om ditt liv är online) kan responsiva bilder lösas av JavaScript. I själva verket i ett antal år var JavaScript det enda sättet att lösa problemet. JavaScript kan testa en användares agents förmåga, bestämma vilken typ av webbläsare det är och skriva en vanlig HTML-bildtagg som innehåller den lämpliga bilden.
Webbdesigners som protesterar mot att använda JavaScript gör det normalt för att vissa människor stänger av det . Men det är inte riktigt fallet längre, särskilt på mobilbanan, men det finns några långvariga problem: att skriva en bild med JavaScript innebär att bilden inte kommer att analyseras av sökmotorkrockar, och den kommer bara att göras efter manuset som kör, till exempel.
Det största problemet med att använda JavaScript är att det är en missbruk av JavaScript-kärnan. HTML innehåller data, CSS hanterar presentation, JavaScript hanterar funktionalitet. När vi bryter från de strukturerade rollerna börjar vi stöta på problem som kräver att hackar ska fixa dem. Bilder är data och bör därför hanteras av HTML.
Problemet med webbläsare
Sedan RWD först trodde sig, har bilder blivit det största hindret. Men nu börjar vi hitta sätt att lösa de olika problemen. Tekniker som är kamphärdade och framgångsrika för att betraktas som bästa praxis. Dedikerade utvecklare har gett sig tid att lobbya WC3 för officiella lösningar, och nu är det för första gången snabba bilder som är praktiska.
Nyckeln till responsiva bilder är att de har utformats med en fullständig medvetenhet om bristerna på webben. Försiktighet har vidtagits för att se till att responsiva bildlösningar inte bryter befintliga webbläsare, så att även i webbläsare som inte stöder lyhörda bilder kommer koden att misslyckas tyst och inte responsiv, standardbilder visas.
I den här artikeln tittar vi på två officiella HTML-element för responsivbild : srcset och bild.
För närvarande stöder Edge, Safari och iOS Safari endast en delmängd av srcset- specifikationen. Firefox, Chrome, Opera, Android Browser och de kommande versionerna av Safari och iOS Safari stöder det fullt ut. (Vi diskuterar skillnaderna nedan.)
För närvarande stöds bildelementet fullt ut av Firefox, Chrome, Opera och Android Browser. Edge, Safari och iOS Safari stöder inte det, och de har inte meddelat en tidtabell för att implementera den.
Även bland webbläsare som stöder den nya koden finns det inkonsekvenser eftersom olika webbläsare tolkar W3C-specifikationerna på olika sätt. När du till exempel anger en bildändring från små till stora baserat på visningsstorlek, kommer vissa webbläsare att byta till den stora bilden när visningsporten är 1px större än den lilla bildens föredragna storlek, andra kommer bara att byta till den stora bilden när visningsporten favoriseras av den stora bilden är helt matchad.
Sammanfattningsvis delas webbläsare i två läger: de som gynnar bilder av högre kvalitet där det är möjligt, och de som favoriserar mindre nedladdningar där det är möjligt. Webbläsare tillverkar fortfarande den här ut, så småningom kommer någons genomförande att bli mest populär - personligen hoppas jag att det är sistnämnda, för som noterat ovan är prestanda avgörande för användarupplevelse.
För närvarande är det bästa alternativet för webbdesigners att hålla sig till specifikationen och försök inte att gissa webbläsaren. Trots allt är standardupplevelsen i webbläsaren (högre kvalitet eller snabbare nedladdningar) en del av vad en användare väljer en standardwebbläsare för, så om användaren är medveten om olika tillvägagångssätt är webbläsarens preferens sannolikt användarens preferens också .
Responsive image best practice (2015)
I hela webbhistoriken har vi använt ett element för att indikera en bild, img- elementet. I HTML5 har img- elementet genomgått ett subtilt skift i sin roll, en som är utformad för att möjliggöra responsiva bilder: img- elementet representerar inte längre en bild, det är nu en platshållare för en bild.
Denna distinktion är viktig, eftersom ett img- element som tidigare innehöll en enda uppsättning bilddata - var den bitmappen eller vektorn - nu kan en bild hålla flera datasatser.
Img- elementet (att återskapa för alla icke-kodare) ser så här ut:
Den responsiva bildversionen av img- elementet ser ut så här:
Knappt någon förändring alls. Om du tittar på den här koden märker du en viktig sak: koden är bakåtkompatibel. Om en webbläsare händer längs det som inte förstår srcset- attributet, ignoreras det enkelt och gör bilden enligt original 1993-specifikationen.
Vad det innebär är att vi nu kan använda lyhörda bilder i vår markering utan att det behövs funktionsdetektering.
I det nya responsiva img- elementet används src huvudsakligen som en standardbild och för webbläsare som inte känner igen srcset, medan srcset innehåller alla tillgängliga högupplösta formatbilder för den platshållaren.
När du gör img- elementet bestämmer webbläsaren själv vilken bildfil som är mest lämplig.
Använda srcset
Nu när vi vet att srcset kommer att misslyckas tyst i webbläsare som inte stöder det, kan vi lägga till en extra bild:
I det här fallet kommer en webbläsare som stöder srcset att visa bild-b.jpg och alla webbläsare som inte stöder srcset kommer att visa bild-a.jpg.
Det är viktigt att notera att webbläsaren bara laddar ned den bild som den bestämmer den vill visa, den laddar inte ner båda bilderna och väljer sedan en.
Tyvärr får det inte oss väldigt långt, för om vi inte demonstrerar srcset- stöd, finns det ingen praktisk tillämpning för att byta bilder baserade på srcset- stöd ensamt.
Lösningen är att ge ytterligare information till webbläsaren om vilken bild den ska välja. För att kunna göra det måste vi tillhandahålla information om antingen ledigt utrymme eller pixeldensitet.
Använda x-descriptor
X-descriptor berättar en webbläsare hur tätt pixlarna i en bild är.
Om du till exempel vill ge en retina-grade bild med dubbelt så många pixlar som en standardbild, anger du retina-bilden i srcset, följt av ett mellanslag och sedan sökordet "2x".
Vi har vår bild:
För att lägga till en retina-alternativ för webbläsaren lägger vi till följande srcset:
I det här fallet finns tre möjliga resultat:
Om webbläsaren inte stöder srcset används den bildfil som anges i src- attributet.
Om webbläsaren stöder srcset och har en skärm som kan dubbla upplösningen använder den bilden som anges i srcset-attributet.
Om webbläsaren stöder srcset men inte har en högupplöst skärm, kommer den att använda bilden som anges i src attributet (när ingen "1x" -bild är specificerad i srcset- attributet antas src- attributet vara den bilden alternativ).
Browser support är bra och snabbt förbättras. Med ett attribut har vi löst upp det svåra av svåra bilder, du!
En sista sak att notera om x-descriptor: Valet av vilken bild som ska laddas baseras på pixeldensitet, så om en användare zoomsar sin webbläsare till 200% (effektivt halverar bildstorleken och så fördubblar pixeldensiteten) 2x bilden laddas. Detta kan ha en negativ inverkan på tillgängligheten - vi vill verkligen inte se att sidor laddas långsammare för synskadade, helt enkelt för att de väljer att zooma deras webbläsare.
Använda w-descriptor
W-descriptor är lite mer avancerad än x-descriptor.W-descriptorn fungerar genom att berätta för webbläsaren hur många faktiska pixlar som finns på x-axeln (bredden) för ett visst bildalternativ.
Edge, Safari och iOS Safari stöder inte w-descriptor vid skrivningstillfället, så användbarheten är något reducerad.
Låt oss återvända till vår ursprungliga bild:
Om den här bilden är 1600 pixlar bred och om vi vill lägga till en retina-bild, som vi gjorde med x-beskrivaren ovan, skulle vi ange en bild i attributet srcset som är 3200 pixlar bred:
Det finns en stor gotcha med w-descriptor: även om src- attributet behandlas som standard när du specificerar bilder med hjälp av x-descriptorn ignoreras det helt och hållet av webbläsare som stöder srcset om du använder w-descriptor. När du använder w-descriptorn måste vi explicit ange standardvärdet genom att lägga till ett andra srcset-bildalternativ med egen w-descriptor och skilja dem med ett kommatecken:
Vilket leder oss snyggt på ...
Använda flera bilder
Att kunna ange ett högupplösta bildalternativ för webbläsaren direkt i vår HTML-kod är bestämt coolt, men som du gissade antagligen blir det ännu kallare när vi anger flera bilder.
Målet med lyhörda bilder är att leverera den bästa kvalitetsbilden som kan användas av åtkomstenheten, men inget mer. Så enkelt att leverera en näthinnans bild är inte tillräcklig, vi behöver tillhandahålla bilder på till exempel 1x, 1,5x, 2x, 2,5x och 3x.
Återigen, här är vår ursprungliga bildmarkering:
Här finns det en retina-bild som levereras som ett alternativ för webbläsaren:
Här är den här gången med extra alternativ i srcset, åtskilda av kommatecken:
Eftersom sökord betyder olika saker för olika personer tycker jag att det är lämpligt att namnge mina bilder enligt x-deskriptorn som de tillhör, både som ett personligt minneshjälpmedel och för att se till att de olika storlekarna är klara för andra teammedlemmar:
Kom ihåg att vi inte berättar för webbläsaren vilken bild som ska visas, vi låter den veta vilka alternativ som är tillgängliga för den och låter den välja själv. Webbläsaren hämtar bara en av dessa bilder.
En gotcha med flera bilder: Ange inte någonsin två bilder i attributet srcset med en matchande x-descriptor och w-descriptor, till exempel:
Storleksattributet är ett särskilt intressant tillägg till specifikationen, eftersom storlekarattributet tar sina värden i förhållande till visningsporten, inte bilden.
Med vw (visningsbredd) -värdet specificerar vi bildområdet i förhållande till webbläsarens bredd. Kom ihåg att img- elementet nu bara är en platshållare, så vi specificerar inte den faktiska storleken på bilden, vi specificerar storlek på platshållare som innehåller bilden.
100vw är 100% av visningsbredd, 50vw är 50% av visningsbredd, 25vw är 25% av visningsbredd etc.
Om vi ville ställa in img bredden till hälften av webbläsarens bredd, skulle vi använda:
Det här är inte särskilt användbart tills vi kombinerar det med mediafrågor ...
Använda mediafrågor
Storleksattributet blir mycket kraftfullare när vi kombinerar det med mediafrågor. Vi kan separera flera visningsbredder med kommatecken och berätta för webbläsaren vilken som ska användas med hjälp av en CSS-stilmediasökning.
Tänk dig att vi vill att en bild ska utgöra 80% av bredden på vårt visningsutrymme på de flesta enheter, men på små enheter (som telefoner) med en bredd på 380px eller mindre vill vi göra det mesta av utrymme tillgängligt genom att göra upp 100% av bredden, skulle vi skriva så här:
Efter denna logik kommer varje webbläsare med ett visningsutrymme på 380px eller mindre att ställa in bildens bredd till 100% av visningsporten. Alla andra webbläsare kommer att orsaka att mediafrågan returnerar falskt och webbläsaren kommer att flytta till nästa värde av storlekarattributet , vilket i detta fall är 80vw.
Som en allmän regel är jag obekväma med hjälp av mediefrågor i HTML. Precis som mottagande bilddata tillhör HTML (inte JavaScript), hörs mediefrågor i CSS (inte HTML). Alternativet finns dock för dig om du behöver det.
Responsive image best practice (2016?)
Jag vet inte om dig, men jag är ganska upphetsad av möjligheterna till srcset. Det är en enkel lösning på ett svårt problem, och verkar leverera allt vi behöver.
Men som bussar, väntar du 20 år på en officiell lösning på lyhörda bilder, och två visas på en gång. Förutom srcset- attributet för img- elementet har vi också bildelementet.
Bildelementet är en annan platshållare, om än en mer traditionell. Det har konstruerats för att efterlikna video- och ljudelementen i HTML5, så dess syntax kommer att vara bekant för de flesta. Bildelementet är avsett att användas när du behöver mer kontroll än vad srcset kan tillhandahålla.
Tyvärr har bildelementet betydligt mindre webbläsarsupport än srcset och det sviker inte alltid tyst.
Använda bildelementet
Här är vårt ursprungliga bildelement:
Här är vår bild nestad inuti ett bildelement:
Vi kan också ange en srcset för ett img- element i ett bildelement:
Använda källelementet
Bildelementet kommer inte till liv förrän vi lägger till källelementet:
När du väljer vilken fil som ska användas startar webbläsaren med det första källelementet och rör sig genom elementen tills det hittar en vars medietillstånd löser sig till true, det kommer då att använda det källaelementets srcset.
Till exempel kan vi ange olika bilder för porträtt och liggande format:
Vi kan också ange flera bilder med x-descriptor och w-descriptor:
Liksom med användningen av mediefrågor i storlekarattributet skulle jag ifrågasätta visdomen att styra bildversioner baserat på stil, i markering istället för ett stilark. Alternativet att använda medieattributet finns dock om du behöver det.
Använda typ
Bildelementet kommer verkligen till sin egen när det används för att byta ut olika typer av bilder.
Tänk dig att vi har en vanlig PNG-fil, men vi vill använda en WebP-fil, vilket är typiskt 26% mindre - kom ihåg att lyhörda bilder handlar om att ge bästa bildkvalitet, med den minsta storleken - men stöds för tillfället endast av Chrome, Opera och Android-webbläsaren. Vi måste använda typattributet för att avgöra om WebP stöds:
I det här fallet kontrollerar webbläsaren om WebP-bildformatet stöds. Om det är, kommer det att avgöra om skärmen har tillräckligt med pixeldensitet för att visa retina-image.webp- bilden, om inte den kommer att visa image.webp- bilden. Om WebP inte stöds kommer webbläsaren hoppa direkt till img- elementet och arbeta genom srcset och src- alternativen på det sätt som vi redan är bekanta med.
Typattributet innebär att vi kan ge mycket mindre bildformat där det stöds, vilket resulterar i en mindre filstorlek.
Kända problem
IE9 har ett känt problem, som förhindrar att bildelementet misslyckas tyst. För att hantera IE9 måste du lura IE9 för att tro att källelementen är en del av ett videoelement:
< !—[if IE 9]>< ![endif]—>
Det är en ful lösning, men bättre än ingen lösning alls. Vi kan bara hoppas att utgåvan av Windows 10 kommer att påskynda nedgången av IE9, eftersom Edge ännu inte stöder bildelementet, stöder det inte på rätt sätt (genom att ignorera det).
Det finns polyfills som kan hjälpa dig att stödja bildelementet på IE, men min egen preferens är att undvika dem. Jag misstroppar patchproblem med JavaScript, det påverkar prestanda och leder till mindre underhållbar kod.
Av denna anledning rekommenderar jag att du undviker bildelementet för nu. Om du inte kör en storskalig e-handelsplats, är det osannolikt att den extra besparingen på nedladdningstiden som WebP-formatet erbjuder uppvägs överväger besväret med att patchera din markering med skript.
När IE9 faller under 1%, vilket bör hända någon gång nästa år, blir bildelementet livskraftigt. Om du läser detta i 2016 är du noga med att gå.
Skapa responsiva bilder
Till skillnad från SVG, uppgraderar bitmapbilder inte upp. Vår strategi för att hantera dem, oavsett om vi använder srcset eller bildelementet , är att tillhandahålla en annan bild baserat på webbläsarens möjligheter. För att hantera det måste vi leverera en mängd olika bildstorlekar.
De flesta bildredigeringsprogram har automatiserat processen att exportera flera versioner av en enda bild. Det spelar ingen roll vilken applikation du använder, förutsatt att du hamnar med flera bildstorlekar utan att behöva ändra storlek på storlek och spara varje.
Adobe Photoshop är de facto bitmap editoren. Det är inte ett bra val för designarbete, men dess bildbehandlings arbetsflöde är jämn och pålitlig. Att generera flera bildupplösningar i Photoshop är relativt enkelt:
Öppna bilden som du vill generera flera versioner av, och lägg den på ett eget lager.
Byt namn på skiktet som namnet på den fil du vill skapa (inklusive förlängningen).
Välj Arkiv> Generera> Bildegenskaper och en mapp med din nya bild sparas vid sidan av din PSD.
Byt namn på skiktet och specificera varje bild som du vill generera före den avsedda skalan. Du behöver inte upprepa steg 3, när du byter namn på lagret bildas bilderna automatiskt.
Kredit för bilden går tillPhilip Collier.
För mer information om hur du genererar bilder i Photoshop, kolla här.
Baserat på dessa bilder kan vi erbjuda webbläsaren fem olika alternativ:
Slutsats
Img- elementet har kommit långt i 20 år. Eller för att vara mer exakt var img- elementet otillräckligt i 18 år och sprintade sedan efter linjen de senaste två åren, till den punkt som det nu är relativt sofistikerat.
Det viktiga är att vi kom till lösningen / lösningarna.
Av de två tillgängliga alternativen, srcset och bild är den förra överlägset mest stödjande. Om du bygger 95% av webbplatserna där ute, är det överlägset stöd och enklare implementeringen av srcset- attributet ditt bästa alternativ.
Om du kör en stor e-handelsplats med tusentals produktbilder kan det extra arbetet med att betjäna WebP-formatet vara värt, särskilt då stöd för bildelementet ökar under de närmaste åren.
Den största svagheten i de nuvarande alternativen är att webbläsare för närvarande inte har möjlighet att välja en bild baserat på deras anslutningshastighet. Vi är tvungna att lita på att mer skickliga enheter också är överlägset anslutna.
I slutändan kan vi äntligen servera bilder av högsta kvalitet praktiskt möjligt, med minsta storlek. Det betyder en bättre upplevelse, på kortare tid, som bara kan vara något att omfamna.
