Internett er et visuelt medium. Det store flertallet av det visuelle landskapet er takket være bildefiler. Mens mange kan oppnås med CSS, og inline SVG, trenger de fleste nettsteder fortsatt bildefiler.
I gjennomsnitt utgjorde bilder mer enn halvparten av sidestørrelse i fjor, og år for år bildestørrelser øker; det var en 21% vekst i bildestørrelse i 2014 alene.
Samtidig fortsetter antallet og mangfoldet av enheter som får tilgang til nettet, til å vokse. Oppløsninger varierer nå hvor som helst mellom 72ppi (avtagende vanlig) og over 600ppi.
Å lage et bilde for skjermen som vil være av tilstrekkelig kvalitet for en hvilken som helst enhet, er enkelt: lagre det på 1000ppi og ring det en dag. Det resulterende bildet vil være skarpt på selv de høyeste hi-res-enhetene. Men mens kvaliteten din blir høy, så vil også filstørrelsen din. Med siden lastetid a nøkkelfaktor i UX Det er pålagt oss å sikre at nettsteder leveres raskt til brukerne våre. Når bilder er av så høy kvalitet at de tar et dusin sekunder for å laste ned på bredbåndsforbindelser, enn si mobilforbindelser, så er de effektivt ubrukelige.
Målet med responsive bilder er da ikke å levere et høyere kvalitetsbilde til skjermbilder som kan vise det (som vi lett kan gjøre), målet er å levere den høyeste kvalitet som støttes og ingenting mer.
Denne veiledningen er laget for å lære deg hva som fungerer, hvor problemene og fallgruvene fortsatt ligger, og hvordan du kan bruke lydige bilder på nettsteder, i dag.
Jeg føler behovet, behovet for fart
Hvorfor går det raskt med saken? Sikkert er ingen på en 3G-tilkobling lenger? Ingen bruker oppringt. Hvis klientens målgruppe er demografisk, bor det på by Manhattan, hvorfor bør du bryr deg om landlige Lesotho? Faktum er at det er en myte at vi alle er super-raske bredbånd, selges til oss av selskaper som drar nytte av ønsket om stadig økende hastigheter.
De fleste bruker minst to timer hver dag på en dårligere forbindelse. Jeg finner meg ofte mest tid til å bla gjennom når jeg pendler, når selv en pålitelig 3G-tilkobling høres ut som en fjern drøm.
I April Google annonserte at mobil vennlighet ville bli brukt som en rangeringsfaktor for søk utført på enheter som den anser å være "mobile". Selv før det, fart var en faktor i siderangering - både eksplisitt som en del av Googles beregninger, og implisitt som en medvirkende faktor til studsfrekvensen.
I to identisk rangerte nettsteder kan en ekstra 1Kb slippe deg fra tredje plass på Google, til fjerde eller femte. Det kan til og med skille deg fra 10. til 11. - med andre ord fra side 1 til side 2 - med all sammenhengende innvirkning på kundens inntekter.
Trenger du virkelig det bildet?
Det mest optimaliserte bildet det er, er ikke noe bilde i det hele tatt. Hvis du har fem bilder på nettstedet ditt og du slipper en, har du spart 20%, kanskje enda viktigere, du har lagret deg en http-forespørsel. Hvis vi falt alle bildene fra våre nettsteder, ville vi spare oss 100%, og alle fem http-forespørsler. Så hvorfor ikke gjøre det?
Vi slipper ikke bilder fra våre nettsteder fordi de kommuniserer mer effektivt enn tekst på kort sikt. De lager en emosjonell tilkobling som trekker brukere inn i innhold.
Vi vet det Brukerne leser ikke nettsider . Svært få mennesker leser inngående innhold på nettet. Bilder lar oss koble til, kommunisere og forsterke et merke i en brøkdel av tiden som teksten kan håndtere.
Bilder kan være store og ubrukelige å laste ned, men en gang gjengitt i nettleseren er de langt mer effektive enn tekst for å etablere brukerengasjement og forsterker en merkemeddelelse.
Responsive bilder hjelper oss med å sikre at de emosjonelle tilkoblingsbildene bygger, ikke går tapt når den utålmodige brukeren treffer tilbakeknappen.
Hva med SVG?
SVG (Scaleable Vector Graphics) er en av de sanne banebrytende teknologiene på nettet. Det er så langt foran kurven at de fleste designere fortsatt ikke har gjenkjent sitt sanne potensial.
SVG - som navnet antyder - er vektorbasert. Dette betyr at SVG-grafikk er konstruert fra punkter, vinkler og avstander. SVG er også - som navnet antyder - skalerbart, noe som betyr at det vil vise like bra på en 5k iMac eller en Android-smarttelefon, uten tap av kvalitet og ingen endring i filstørrelse.
Hvis du har en flat illustrasjon, et ikon, en logo, omtrent alt som kan vises som en SVG, så er SVG veien å gå.
De fleste bildene på nettet er bitmaps. Generelt sett fungerer en bitmap for å beskrive hver piksel en om gangen, fargen (i RGB - rød, grønn og blå verdier) og i noen tilfeller gjennomsiktigheten. Hvis du har et bilde som måler 100px ved 100px, så har du et bilde med 10.000 piksler; hvis hver piksel har 4 verdier for å beskrive den, så har bildet 40.000 biter data knyttet til det. Høres ut som mye gjør det ikke? Noen ganger er det mindre enn en vektorgrafikk.
Vurder en 1px med 1px bilde; det ville kreve 4 bits data for å registrere som bitmap (rød, grønn, blå og alfa verdier). Betrakt nå det samme firkantede pikselet som er registrert som en vektor; det ville kreve x, y, bredde og høyde på rektangelet, i tillegg til RGBA-verdiene.
Det er rå eksempler, men de er nøyaktige. Ofte overstiger en vektorversjon av et bilde - hvis vi selv har en tilgjengelig for oss - overfilstørrelsen til den tilsvarende bitmappen, og så er bitmap det eneste fornuftige valget.
(Mis) ved hjelp av JavaScript
Som de fleste problemer i livet (hvis livet ditt er online), kan responsive bilder løses av JavaScript. Faktisk i flere år var JavaScript den eneste måten å løse problemet på. JavaScript kan teste en brukeragents evner, bestemme hvilken type nettleser den er, og skrive en standard HTML-bilde tag, som inneholder riktig bilde.
Webdesignere som protesterer mot å bruke JavaScript, gjør det vanligvis fordi noen slår den av . Det er imidlertid ikke særlig tilfelle lenger, spesielt på mobilnett, men det er noen vedvarende problemer: å skrive et bilde med JavaScript betyr at bildet ikke vil bli analysert av søkemotoren, og det vil bare gjengi etter manuset som løp, for eksempel.
Det største problemet med å bruke JavaScript er at det er en misbruk av JavaScripts kjerneformål. HTML inneholder data, CSS håndterer presentasjon, JavaScript håndterer funksjonalitet. Når vi bryter fra de strukturerte rollene, begynner vi å møte problemer som krever hacks å fikse dem. Bilder er data, og bør derfor håndteres av HTML.
Problemet med nettlesere
Siden RWD ble først oppdaget, har bildene vært den største hindringen. Men nå begynner vi å finne måter å løse de ulike problemene på. Teknikker som er kampherdet og vellykket nok til å bli ansett som best practice. Dedikerte utviklere har gitt opp sin tid til å lobbyere WC3 for offisielle løsninger, og for første gang er responsive bilder praktiske.
Nøkkelen til responsive bilder er at de er designet med full bevissthet om feilene på nettet. Det er gjort forsiktighet for at responsive bildeløsninger ikke brister eksisterende nettlesere, slik at selv i nettlesere som ikke støtter lydhør bilder, vil koden svikte tydelig og ikke-responsiv, vil standardbilder vises.
I denne artikkelen ser vi på to offisielle responsive image-HTML-elementer: srcset og bilde.
I dag støtter Edge, Safari og iOS Safari bare en delmengde av srcset- spesifikasjonen. Firefox, Chrome, Opera, Android Browser, og de kommende versjoner av Safari og iOS Safari støtter det fullt ut. (Vi diskuterer forskjellene nedenfor.)
For øyeblikket støttes bildeelementet fullt ut av Firefox, Chrome, Opera og Android Browser. Edge, Safari og iOS Safari støtter ikke det, og de har ikke annonsert en tidsplan for å implementere den.
Selv blant nettlesere som støtter den nye koden, er det uoverensstemmelser da forskjellige nettleserprodusenter tolker W3C-spesifikasjonene på forskjellige måter. For eksempel, når du angir en endring av bilde fra små til store basert på visningsstørrelse, vil enkelte nettlesere bytte til det store bildet når visningsporten er 1px større enn det lille bildetes foretrukne størrelse, andre vil bare bytte til det store bildet når visningsporten favorisert av det store bildet er fullstendig matchet.
I sammendraget deles nettlesere i to leirer: de som favoriserer bilder av høyere kvalitet, hvor det er mulig, og de som favoriserer mindre nedlastinger der det er mulig. Nettleserprodusenter fremmer fortsatt denne utgaven, og etter hvert vil noen av implementeringene bli mest populære. Personlig håper jeg det er sistnevnte, fordi som nevnt ovenfor er ytelsen avgjørende for brukeropplevelsen.
For nå er det beste alternativet for webdesignere å holde seg til spesifikasjonen, og ikke prøv å gjette nettleseren på andre måte. Tross alt er standardopplevelsen i nettleseren (høyere kvalitet eller raskere nedlastinger) en del av hva en bruker velger en standard nettleser for, så hvis brukeren er klar over de forskjellige tilnærmingene, er nettleserens preferanse sannsynligvis brukerens preferanse også .
Responsive image best practice (2015)
Gjennom webens historie har vi brukt ett element for å indikere et bilde, det img- elementet. I HTML5 har img- elementet gjennomgått et subtilt skift i sin rolle, en som er utformet for å aktivere responsive bilder: Img- elementet representerer ikke lenger et bilde, det er nå en plassholder for et bilde.
Dette skillet er viktig, fordi mens et img- element tidligere hadde et enkelt sett med bildedata - være det punktgrafikk eller vektoren - nå kan et bilde inneholde flere datasett.
Img- elementet (for å rekonstruere for noen ikke-kodere) ser slik ut:
Den responsive bildeversjonen av img- elementet ser slik ut:
Knapt noen endring i det hele tatt. Ser du på denne koden, legger du merke til en viktig ting: koden er bakoverkompatibel. Hvis en nettleser skjer med det som ikke forstår srcset- attributtet, vil det bare ignorere det og gjengi bildet i henhold til den opprinnelige 1993-spesifikasjonen.
Hva dette betyr, er at vi nå kan bruke lydige bilder i vårt oppslag, uten behov for funksjonsdeteksjon.
I det nye responsive img- elementet brukes src hovedsakelig som et standardbilde og for nettlesere som ikke gjenkjenner srcset, mens srcset inneholder alle tilgjengelige høyoppløsningsbilder for den stedholderen.
Når du gjengir img- elementet, bestemmer nettleseren for seg hvilken bildefil som passer best.
Bruk av srcset
Nå som vi vet at srcset vil svikte tydeligvis i nettlesere som ikke støtter det, er det gratis å legge til et ekstra bilde:
I dette tilfellet vil enhver nettleser som støtter srcset vise bilde-b.jpg og en hvilken som helst nettleser som ikke støtter srcset, vil vise bilde-a.jpg.
Det er viktig å merke seg at nettleseren bare laster ned bildet det bestemmer det vil vise, det laster ikke ned begge bildene og velger deretter en.
Dessverre får dette oss ikke så langt, for med mindre vi demonstrerer srcset- støtte, er det ingen praktisk applikasjon for å bytte bilder basert på srcset- støtte alene.
Løsningen er å gi ytterligere informasjon til nettleseren om hvilket bilde den skal velge. For å gjøre det, må vi levere informasjon om enten ledig plass eller piksel tetthet.
Bruke x-descriptor
X-descriptoren forteller en nettleser hvor tett pikslene i et bilde er.
Hvis du for eksempel ville gi et retina-grade bilde med dobbelt så mange piksler som et standardbilde, ville du spesifisere retina-bildet i srcset, etterfulgt av et mellomrom og deretter søkeordet "2x".
Vi har vårt bilde:
For å legge til et retina-alternativ for nettleseren, legger vi til følgende srcset:
I dette tilfellet er det tre mulige utfall:
Hvis nettleseren ikke støtter srcset , vil den bruke bildefilen som er angitt i src- attributtet;
hvis nettleseren støtter srcset, og har en skjerm som har en dobbel oppløsning, vil den bruke bildet som er angitt i srcset-attributtet;
Hvis nettleseren støtter srcset, men ikke har en høyoppløselig skjerm, vil den bruke bildet som er angitt i src- attributtet (når ingen "1x" -bilde er angitt i srcset- attributtet, antas src- attributtet å være det bildet alternativ).
Nettleserstøtte er god og forbedrer seg raskt. Med en attributt har vi løst konseptet med lydhør bilder, yay oss!
En siste ting å merke seg om x-descriptor: valget av hvilket bilde som skal lastes, er basert på pixeldensitet, så hvis en bruker zoomser nettleseren til 200% (effektivt halverer bildestørrelsen, og dermed dobler pixeldensiteten) 2x bildet vil lastes inn. Dette kan ha en ugunstig effekt på tilgjengelighet - vi vil absolutt ikke se at nettsteder laster tregere for synskadede, bare fordi de velger å zoome nettleseren.
Bruke w-descriptor
W-descriptor er litt mer avansert enn x-descriptor.W-descriptor fungerer ved å fortelle nettleseren hvor mange faktiske piksler eksisterer på x-aksen (bredden) av et bestemt bildealternativ.
Edge, Safari og iOS Safari støtter ikke w-descriptor på tidspunktet for skriving, så bruken er noe redusert.
La oss gå tilbake til vårt opprinnelige bilde:
Hvis dette bildet er 1600 piksler bredt, og hvis vi vil legge til et retina bilde, som vi gjorde med x-descriptoren ovenfor, ville vi spesifisere et bilde i attributten srcset som er 3200 piksler bredt:
Det er en stor gotcha med w-descriptor: Selv om src- attributtet blir behandlet som standard når du spesifiserer bilder ved hjelp av x-descriptor, ignoreres det helt av nettlesere som støtter srcset hvis du bruker w-descriptor. Når du bruker w-descriptoren, må du spesifisere standarden eksplisitt ved å legge til et andre srcset-bildealternativ , med egen w-descriptor, og skille dem med et komma:
Som fører oss pent inn på ...
Bruke flere bilder
Å kunne spesifisere et høyoppløselig bildealternativ for nettleseren, rett i HTML-koden, er bestemt kult, men som du sikkert gjettet, blir det enda kjøligere når vi angir flere bilder.
Målet med lydhør bilder er å levere det beste kvalitetsbildet som er brukbart av tilgangsenheten, men ikke noe mer. Så enkelt å levere et retina bilde er ikke tilstrekkelig, vi trenger å levere bilder på for eksempel 1x, 1,5x, 2x, 2,5x og 3x.
Igjen, her er vårt opprinnelige bildeoppslag:
Her er det med et retina-bilde som følger med som et alternativ for nettleseren:
Her er det denne gangen med ekstra alternativer i srcset, skilt av kommaer:
Fordi søkeord betyr forskjellige ting for forskjellige mennesker, finner jeg det tilrådelig å nevne bildene i henhold til x-deskriptoren som de tilhører, både som et personlig minnehjelp og for å sikre at de forskjellige størrelsene er klare for andre teammedlemmer:
Husk at vi ikke forteller nettleseren hvilket bilde som skal vises, vi lar det få vite alternativene som er tilgjengelige for det, og tillater det å velge for seg selv. Nettleseren vil bare laste ned et av disse bildene.
En gotcha med flere bilder: Angi aldri to bilder i srcset- attributtet med en tilsvarende x-descriptor og w-descriptor, for eksempel:
Størrelsesattributtet er et spesielt interessant tillegg til spesifikasjonen, fordi størrelsesattributtet tar sine verdier i forhold til visningsporten, ikke bildet.
Ved å bruke vw (visningsbredde) -verdien, spesifiserer vi bildeområdet i forhold til nettleservidden. Husk, img- elementet er nå effektivt bare en plassholder, så vi angir ikke den faktiske størrelsen på bildet, vi spesifiserer Størrelsen på plassholderen som vil inneholde bildet.
100vw er 100% av visningsbredden, 50vw er 50% av visningsbredden, 25vw er 25% av visningsbredden etc.
Hvis vi ønsket å sette img bredden til halvparten av nettleserbredden, ville vi bruke:
Dette er ikke spesielt nyttig før vi kombinerer det med medieforespørsler ...
Bruk av media spørringer
Størrelsesattributtet blir mye kraftigere når vi kombinerer det med medieforespørsler. Vi kan skille flere visningsbredder ved hjelp av kommaer, og fortelle nettleseren hvilken bruker du skal bruke ved hjelp av en CSS-stil mediesøk.
For eksempel, tenk at vi ønsker at et bilde skal utgjør 80% av bredden på visningsporten på de fleste enheter, men på små enheter (som telefoner) med en bredde på 380px eller mindre, ønsker vi å få mest mulig ut av plass tilgjengelig ved å gjøre opp 100% av bredden, ville vi skrive det slik:
Etter denne logikken vil enhver nettleser med en visning på 380 px eller mindre angi bredden på bildet til 100% av visningsporten. En hvilken som helst annen nettleser vil føre til at spørringen fra media returnerer falsk og nettleseren vil flytte til neste verdi av størrelsesattributtet , som i dette tilfellet er 80vw.
Som hovedregel er jeg ubehagelig ved å bruke medieforespørsler i HTML. Akkurat som responsive bildedata tilhører HTML (ikke JavaScript), tilhører medieforespørsler i CSS (ikke HTML). Men alternativet er der for deg hvis du trenger det.
Responsive image best practice (2016?)
Jeg vet ikke om deg, men jeg er ganske spent på mulighetene for srcset. Det er en enkel løsning på et vanskelig problem, og synes å levere alt vi trenger.
Men, som busser, venter du 20 år for en offisiell løsning på lydhør bilder, og deretter kommer to opp på en gang. I tillegg til srcset- attributtet til img- elementet, har vi også bildeelementet.
Bildeelementet er en annen plassholder, om enn en mer tradisjonell. Det har blitt konstruert for å etterligne video- og lydelementene i HTML5, slik at syntaksen blir kjent for de fleste. Bildelementet er ment å bli brukt når du trenger mer kontroll enn hva srcset kan gi.
Dessverre har bildeelementet langt mindre nettleserstøtte enn srcset, og det svikter ikke alltid stille.
Bruke bildeelementet
Her er vårt opprinnelige bildeelement:
Her er bildet vårt nestet inne i et bildeelement:
Vi kan også spesifisere en srcset for et img- element inne i et bildeelement:
Bruke kildeelementet
Bildelementet kommer ikke til liv før vi legger til kildematerialet :
Når du velger hvilken fil som skal brukes, starter nettleseren med det første kildeelementet , og beveger seg gjennom elementene til det finner en som har medieattributt som er sant. Det vil da bruke kildeelementetskildekode.
For eksempel kan vi spesifisere forskjellige bilder for stående og liggende formater:
Vi kan også angi flere bilder ved hjelp av x-descriptor og w-descriptor:
Som med bruk av medieforespørsler i størrelsesattributtet , ville jeg stille spørsmål om visdommen til å kontrollere bildeversjoner basert på stil, i markering i stedet for et stilark. Men muligheten til å bruke medieattributtet er der hvis du trenger det.
Bruke type
Bildelementet kommer egentlig til sin egen når det brukes til å bytte ut ulike typer bilder.
Tenk deg at vi har en standard PNG-fil, men vi vil bruke en WebP-fil, som vanligvis er 26% mindre - husk lydhør bilder handler om å levere den beste bildekvaliteten, med den minste størrelsen - men støttes for tiden bare av Chrome, Opera og Android-nettleseren. Vi må bruke typen attributt for å finne ut om WebP støttes:
I dette tilfellet vil nettleseren kontrollere om WebP-bildeformatet støttes. Hvis det er, vil det avgjøre om skjermen har nok pixeldensitet til å vise retina-image.webp- bildet, om ikke det vil vise image.webp- bildet. Hvis WebP ikke støttes, hopper nettleseren direkte til img- elementet og arbeider gjennom innstillingene for srcset og src på måten vi allerede er kjent med.
Typeattributtet betyr at vi kan gi mye mindre bildeformater der det støttes, noe som resulterer i en mindre filstørrelse.
Kjente problemer
IE9 har et kjent problem, som forhindrer at bildet elementet svikter tydelig. For å kunne håndtere IE9 må du lure IE9 til å tro at kildematerialene er en del av et videoelement:
< !—[if IE 9]>< ![endif]—>
Det er en stygg løsning, men bedre enn ingen løsning i det hele tatt. Vi kan bare håpe at utgivelsen av Windows 10 vil fremskynde nedgangen til IE9, fordi mens Edge ennå ikke støtter bildeelementet, støtter den ikke den på riktig måte (ved å ignorere det).
Det er polyfills som kan hjelpe deg med å støtte bildeelementet på IE, men min egen preferanse er å unngå dem. Jeg misligholder patchproblemer med JavaScript, det påvirker ytelsen og fører til mindre vedlikeholdsbar kode.
Av denne grunn anbefaler jeg å unngå bildeelementet for nå. Med mindre du kjører et storskala e-handelsnettsted, vil den ekstra besparelsen på nedlastingstid som WebP-formatet tilbyr, ikke oppveie ulempen med å la opp merkingen din med skript.
Når IE9 faller under 1%, som skal skje på et tidspunkt i neste år, vil bildeelementet bli levedyktig. Hvis du leser dette i 2016, er du sannsynligvis god å gå.
Opprette lydhør bilder
I motsetning til SVG, skal bitmapbilder ikke skaleres opp. Vår strategi for å håndtere dem, enten vi bruker srcset eller bildeelementet, er å levere et annet bilde basert på nettleserens evner. For å kunne håndtere det, må vi levere en rekke forskjellige bildestørrelser.
De fleste bilderedigeringsprogrammene har automatisert prosessen med å eksportere flere versjoner av et enkelt bilde. Det spiller ingen rolle hvilken applikasjon du bruker, forutsatt at du ender med flere bildestørrelser uten å måtte endre størrelsen manuelt og lagre hver enkelt.
Adobe Photoshop er de facto bitmap editoren. Det er ikke et godt valg for designarbeid, men bildebehandlingsprosessen er jevn og pålitelig. Å generere flere bildeoppløsninger i Photoshop er relativt grei:
Åpne bildet du vil generere flere versjoner av, og legg det på eget lag.
Gi nytt navn til laget som navnet på filen du vil generere (inkludert utvidelsen).
Velg File> Generate> Image Assets, og en mappe med det nye bildet vil bli lagret ved siden av PSD.
Gi nytt navn på laget, og spesifiser hvert bilde du vil generere på forhånd etter den planlagte skalaen. Du trenger ikke å gjenta trinn 3, når du omdøper laget bildene vil bli generert automatisk.
Kreditt for bildet går tilPhilip Collier.
For mer informasjon om generering av bilder i Photoshop, se her.
Basert på disse bildene kan vi tilby nettleseren fem forskjellige alternativer:
Konklusjon
Img- elementet har kommet langt i 20 år. Eller for å være mer nøyaktig var img- elementet utilstrekkelig i 18 år, så sprintet for linjen de siste to årene, til det punktet at det nå er relativt sofistikert.
Det viktigste er at vi kom til løsningen (e).
Av de to tilgjengelige alternativene, srcset og bildet, er den tidligere den mest støttede. Hvis du bygger 95% av nettstedene der ute, er den overlegne støtten og enklere implementering av srcset- attributtet ditt beste alternativ.
Hvis du kjører et stort e-handelsområde, med tusenvis av produktbilder, kan det ekstra arbeidet med å tjene WebP-formatet være verdt, spesielt ettersom støtte til bildeelementet øker de neste par årene.
Den største svakheten i de nåværende alternativene er at nettlesere for øyeblikket ikke har mulighet til å velge et bilde basert på deres tilkoblingshastighet. Vi er tvunget til å stole på at mer dyktige enheter også er på overlegne forbindelser.
Til slutt kan vi endelig servere bilder av høyeste kvalitet praktisk mulig, med den minste størrelsen. Det betyr en bedre opplevelse, på kortere tid, som bare kan være noe å omfavne.
