Internettet er et visuelt medium. Langt det meste af det visuelle landskab er takket være billedfiler. Mens der kan opnås masser med CSS og inline SVG, har de fleste websteder stadig brug for billedfiler.

I gennemsnit tegnede billeder sig for mere end halvdelen af sidestørrelse sidste år, og år for år billedstørrelser stiger; der var en 21% vækst i billedstørrelse i 2014 alene.

Samtidig fortsætter antallet og mangfoldigheden af ​​enheder, der får adgang til internettet, at vokse. Beslutninger varierer nu hvor som helst mellem 72ppi (faldende almindelig) og over 600ppi.

Oprettelse af et billede til skærmen, der vil være af tilstrækkelig kvalitet til enhver enhed, er simpel: Gem det på 1000ppi og kald det en dag. Det resulterende billede vil være skarpt på selv de højeste hi-res enheder. Men mens din kvalitet bliver høj, så vil din filstørrelse også. Med sideindlæsningstid a nøglefaktor i UX det påhviler os at sikre, at websteder straks leveres til vores brugere. Når billeder er af så høj kvalitet, at de tager et halvt sekund at downloade på bredbåndsforbindelser, endsige mobile forbindelser, så er de effektivt ubrugelige.

Målet med lydhørede billeder er ikke at levere et højere kvalitetsbillede til skærme, der kan vise det (som vi nemt kan gøre), målet er at levere den højeste kvalitet, der understøttes og ikke mere.

Denne vejledning er designet til at lære dig, hvad der virker, hvor problemerne og faldgruverne stadig ligger, og hvordan du kan bruge lydhøre billeder på hjemmesider i dag.

Jeg føler behovet, behovet for hastighed

Hvorfor er hurtighed sagen? Sikkert er ingen på en 3G-forbindelse længere? Ingen bruger opkald. Hvis din klient er målrettet demografisk beboer by Manhattan, hvorfor skal du bekymre dig om landdistrikterne Lesotho? Faktum er, det er en myte, at vi alle er superbaserede bredbånd, der sælges til os af virksomheder, der drager fordel af ønsket om stadig stigende hastigheder.

De fleste mennesker bruger mindst to timer hver dag på en ringere forbindelse. Jeg finder mig ofte mest tid til at gennemse, når man pendler, når selv en pålidelig 3G-forbindelse lyder som en fjern drøm.

I april Google annoncerede at mobil venlighed ville blive brugt som en placeringsfaktor for søgninger udført på enheder, som den anser for at være "mobile". Allerede før det, hastighed var en faktor i siderangering - både eksplicit som en del af Googles beregninger og implicit som en medvirkende faktor til din afvisningshastighed.

På to identisk rangerede steder kan en ekstra 1Kb slippe dig fra 3. plads på Google til 4. eller 5.. Det kan endda tabe dig fra 10. til 11. - med andre ord fra side 1 til side 2 - med alle de dermed forbundne konsekvenser for din kundes indtægter.

Har du virkelig brug for det billede?

Det mest optimerede billede der er, er slet ikke noget billede. Hvis du har fem billeder på dit websted, og du vælger en, har du sparet dig selv 20%, måske endnu vigtigere, du har gemt dig selv en http-anmodning. Hvis vi tabte alle billeder fra vores websteder, ville vi spare os 100% og alle fem http-anmodninger. Så hvorfor ikke gøre det?

Vi taber ikke billeder fra vores websteder, fordi de kommunikerer mere effektivt end tekst på kort sigt. De skaber en følelsesmæssig forbindelse, der trækker brugerne i indhold.

Vi ved det brugerne læser ikke websider . Meget få mennesker læser indgående indhold online. Billeder giver os mulighed for at forbinde med, kommunikere og forstærke et mærke i en brøkdel af den tid, teksten kan klare.

Billederne kan være store og uhåndterlige at downloade, men når de er gengivet i browseren, er de langt mere effektive end end tekst til at etablere brugerinddragelse og forstærke en brandbesked.

Responsive billeder hjælper os med at sikre, at den følelsesmæssige forbindelse billeder bygger ikke tabt, når den utålmodige bruger rammer back-knappen.

Hvad med SVG?

SVG (Scaleable Vector Graphics) er en af ​​de sande banebrydende teknologier på nettet. Det er så langt foran kurven, at de fleste designere stadig ikke har genkendt sit sande potentiale.

SVG - som navnet antyder - er vektorbaseret. Dette betyder, at SVG-grafik er konstrueret fra punkter, vinkler og afstande. SVG er også - som navnet antyder - skalerbart, hvilket betyder, at det vil vise lige så godt på en 5k iMac eller en Android-smartphone, uden tab af kvalitet og ingen ændring i filstørrelse.

Hvis du har en flad illustration, et ikon, et logo, næsten alt, hvad der kan vises som en SVG, så er SVG vejen at gå.

De fleste billeder på nettet er bitmaps. Generelt fungerer den måde, hvorpå en bitmap fungerer, at beskrive hver pixel en ad gangen, dens farve (i RGB - rød, grøn og blå værdier) og i nogle tilfælde dens gennemsigtighed. Hvis du har et billede, der måler 100px ved 100px, så har du et billede med 10.000 pixel; hvis hver pixel har 4 værdier for at beskrive den, så har billedet 40.000 bits data tilknyttet det. Det lyder som meget, ikke? Nogle gange er det mindre end en vektor grafik.

Overvej et 1px ved 1px billede; det ville kræve 4 bits data til optagelse som bitmap (rød, grøn, blå og alfa værdier). Overvej nu den samme firkantede pixel, der er optaget som en vektor; det ville kræve x, y, bredden og højden af ​​rektanglet ud over RGBA værdierne.

Det er rå eksempler, men de er præcise. Ofte overskrider en vektorversion af et billede - hvis vi endda har en tilgængelig for os - overskridelsen af ​​den tilsvarende bitmaps filstørrelse, og så er bitmap det eneste fornuftige valg.

(Mis) ved hjælp af JavaScript

Ligesom de fleste problemer i livet (hvis dit liv er online) kan responsive billeder løses af JavaScript. Faktisk i flere år var JavaScript den eneste måde at løse problemet på. JavaScript kan teste en brugeragents evner, bestemme hvilken type browser det er, og skrive et standard HTML-billedmærke, der indeholder det relevante billede.

Webdesignere, der protesterer mod at bruge JavaScript, gør det typisk fordi nogle mennesker slukker det . Men det er ikke rigtig tilfældet længere, især på mobilwebben, men der er nogle vedholdende problemer: at skrive et billede med JavaScript betyder, at billedet ikke vil blive analyseret af søgemaskinebots, og det vil kun blive gjort efter scriptet som køre, for eksempel.

Det største problem med at bruge JavaScript er, at det er en misbrug af JavaScript's grundlæggende formål. HTML indeholder data, CSS håndterer præsentation, JavaScript håndterer funktionalitet. Når vi bryder fra de strukturerede roller, begynder vi at støde på problemer, der kræver hacks at rette dem. Billeder er data, og skal derfor håndteres af HTML.

Problemet med browsere

Siden RWD blev først overvejet, har billeder været den største hindring. Men nu begynder vi at finde måder at løse de forskellige problemer på. Teknikker, der er kamphærdede og vellykkede nok til at blive betragtet som bedste praksis. Dedikerede udviklere har givet deres tid til at lobbyere WC3 til officielle løsninger, og nu er det for første gang lykkelige billeder, der er praktiske.

Nøglen til reagerende billeder er, at de er blevet designet med fuld bevidsthed om webens svigt. Der er taget omhu for at sikre, at lydløse billedløsninger ikke brækker eksisterende browsere, så at selv i browsere, der ikke understøtter lydhørige billeder, vil koden svigte og ikke-responsive, vil standardbilleder blive vist.

I denne artikel vil vi se på to officielle lydhør HTML-elementer: srcset og billede.

På nuværende tidspunkt understøtter Edge, Safari og iOS Safari kun en delmængde af srcset- specifikationen. Firefox, Chrome, Opera, Android Browser, og de kommende versioner af Safari og iOS Safari understøtter det fuldt ud. (Vi diskuterer forskellene nedenfor.)

På nuværende tidspunkt understøttes billedelementet fuldt ud af Firefox, Chrome, Opera og Android Browser. Edge, Safari og iOS Safari understøtter det ikke, og de har ikke annonceret en tidsplan for implementering af det.

Selv blandt browsere, der understøtter den nye kode, er der uoverensstemmelser, da forskellige browserproducenter tolker W3C-specifikationerne på forskellige måder. Når du f.eks. Angiver en ændring af billedet fra små til store baseret på visningsstørrelse, skifter nogle browsere til det store billede, når visningsporten er 1 px større end det lille billedets foretrukne størrelse, mens andre kun skifter til det store billede, når visningsporten begunstiget af det store billede er fuldt matchet.

Sammenfattende er browsere opdelt i to lejre: dem der favoriserer billeder af højere kvalitet, hvor det er muligt, og dem der favoriserer mindre downloads, hvor det er muligt. Browserproducenter fremmer stadig denne ud, så en persons implementering vil efterhånden blive mest populær - personligt håber jeg, at det er sidstnævnte, fordi som nævnt ovenfor er ydeevnen afgørende for brugeroplevelsen.

For øjeblikket er den bedste løsning for webdesignere at holde sig til specifikationen og forsøge ikke at gætte browseren. Når alt kommer til alt, er standardoplevelsen i browseren (højere kvalitet eller hurtigere downloads) en del af, hvad en bruger vælger en standardbrowser for, så hvis brugeren er opmærksom på de forskellige tilgange, er browserens præference sandsynligvis brugerens præference også .

Responsive image best practice (2015)

I hele internets historie har vi brugt et element til at angive et billede, img- elementet. I HTML5 har img- elementet gennemgået et subtilt skift i sin rolle, en, der er designet til at muliggøre lydhøre billeder: Img- elementet repræsenterer ikke længere et billede, det er nu en pladsholder til et billede.

Denne sondring er vigtig, for selvom et img- element tidligere har haft et enkelt sæt billeddata - vær den bitmap eller vektor - kan et billede nu indeholde flere sæt data.

Img elementet (for at genskabe for nogen ikke-kodere) ser sådan ud:

Den responsive billedversion af img- elementet ser sådan ud:

Næppe nogen ændring overhovedet. Når du kigger på denne kode, bemærker du en vigtig ting: koden er bagudkompatibel. Hvis en browser finder sted langs det, der ikke forstår srcset- attributten, ignorerer den simpelthen det og gengiver billedet i henhold til den oprindelige 1993-specifikation.

Hvad det betyder er, at vi nu kan bruge lydige billeder i vores markering uden behov for funktionsdetektering.

I det nye responsive img- element bruges src hovedsageligt som et standardbillede og til browsere, der ikke genkender srcset, mens srcset indeholder alle de tilgængelige high-res- formatbilleder for den pågældende pladsholder.

Når du gengiver img- elementet, bestemmer browseren for sig selv hvilken billedfil der er mest hensigtsmæssig.

Brug af srcset

Nu da vi ved, at srcset svigte tydeligt i browsere, der ikke understøtter det, er vi fri til at tilføje et ekstra billede:

I dette tilfælde vil enhver browser, der understøtter srcset , vise image-b.jpg, og enhver browser, der ikke understøtter srcset, vil vise image-a.jpg.

Det er vigtigt at bemærke, at browseren kun downloader det billede, den beslutter det vil vise, det downloader ikke begge billeder og vælger derefter en.

Desværre får det os ikke meget langt, for medmindre vi demonstrerer srcset- support, er der ingen praktisk anvendelse til at skifte billeder baseret på srcset- support alene.

Løsningen er at give yderligere information til browseren om hvilket billede den skal vælge. For at gøre det, skal vi levere oplysninger om enten ledig plads eller pixeldensitet.

Brug af x-descriptor

X-descriptoren fortæller en browser, hvor tæt pixelene i et billede er.

Hvis du for eksempel ønskede at give et retina-grade billede med dobbelt så mange pixels som et standardbillede, skulle du angive nethinden i srcset efterfulgt af et mellemrum og derefter søgeordet "2x".

Vi har vores billede:

an image

For at tilføje en nethinden mulighed for browseren tilføjer vi følgende srcset:

I dette tilfælde er der tre mulige resultater:

  1. Hvis browseren ikke understøtter srcset , vil den bruge den billedfil, der er angivet i src attributten;
  2. hvis browseren understøtter srcset og har en skærm med en dobbelt opløsning, vil den bruge det billede, der er angivet i srcset attributten;
  3. hvis browseren understøtter srcset, men ikke har et high-res-skærm, vil det bruge det billede, der er angivet i src- attributten (når der ikke er angivet et "1x" billede i srcset- attributten, antages src- attributten at være det billede mulighed).

Browser support er god og forbedrer hurtigt. Med en egenskab har vi løst konfrontet med lydhøre billeder, yay os!

En sidste ting at bemærke om x-deskriptoren: valget af hvilket billede der skal indlæses er baseret på pixeldensitet, så hvis en bruger zoomer deres browser til 200% (effektivt halver billedstørrelsen og så fordobler pixeldensiteten) 2x billedet vil indlæse. Dette kan have en negativ indvirkning på tilgængeligheden - vi vil bestemt ikke se, at websteder indlæses langsommere for de synshandicappede, simpelthen fordi de vælger at zoome deres browser.

Brug af w-descriptor

W-deskriptoren er lidt mere avanceret end x-deskriptoren. W-deskriptoren virker ved at fortælle browseren, hvor mange faktiske pixels der findes på x-aksen (bredden) af en bestemt billedindstilling.

Edge, Safari og iOS Safari understøtter ikke w-descriptor på tidspunktet for skrivning, så dets anvendelighed er noget reduceret.

Lad os vende tilbage til vores originale billede:

an image

Hvis dette billede er 1600 pixels bredt, og hvis vi ønsker at tilføje et retina billede, som vi gjorde med x-descriptoren ovenfor, ville vi angive et billede i attributten srcset , der er 3200 pixel bredt:

Der er en stor gotcha med w-descriptor: selvom src- attributten behandles som standard, når du angiver billeder ved hjælp af x-descriptoren, ignoreres det fuldstændigt af browsere, der understøtter srcset, hvis du bruger w-descriptor. Når vi bruger w-descriptoren, skal vi angive standardeksplicit ved at tilføje en anden srcset- billedoption med egen w-deskriptor og adskille dem med et komma:

Hvilket fører os pænt ind på ...

Brug af flere billeder

At kunne angive en høj opløsning billedindstilling til browseren lige i vores HTML-kode er bestemt cool, men som du sikkert gættede bliver den endnu køligere, når vi angiver flere billeder.

Målet med lydhøre billeder er at levere det bedste kvalitetsbillede, der kan bruges af adgangsapparatet, men ikke mere. Så simpelthen at levere et retina billede er ikke tilstrækkeligt, vi skal levere billeder på f.eks. 1x, 1,5x, 2x, 2,5x og 3x.

Endnu engang er her vores originale billedmarkering:

an image

Her er det med et retina-billede, der leveres som en mulighed for browseren:

Her er det, denne gang med ekstra muligheder i srcset, adskilt af kommaer:

Fordi søgeord betyder forskellige ting for forskellige mennesker, finder jeg det tilrådeligt at navngive mine billeder i henhold til den x-deskriptor, som de tilhører, både som et personlig hukommelseshjælp og for at sikre, at de forskellige størrelser er klare for andre holdmedlemmer:

Husk, vi fortæller ikke browseren, hvilket billede der skal vises, vi lader det kende de muligheder, der er tilgængelige for det, og tillader det at vælge selv. Browseren downloader kun et af disse billeder.

One gotcha med flere billeder: angiv ikke nogensinde to billeder i srcset attributten med en matchende x-descriptor og w-descriptor, for eksempel:

Det ville være dårligt ...

Brug af størrelser

Størrelsesattributten er en særlig interessant tilføjelse til specifikationen, fordi størrelsesattributten tager sine værdier i forhold til visningsporten, ikke billedet.

Ved hjælp af vw (visningsbredde) -værdien angiver vi billedområdet i forhold til browserværden. Husk, at img- elementet nu er effektivt kun en pladsholder, så vi ikke specificerer den faktiske størrelse af billedet, vi specificerer Størrelsen af ​​pladsholderen, der vil indeholde billedet.

100vw er 100% af viewportbredden, 50vw er 50% af viewportbredden, 25vw er 25% af viewportbredden mv.

Hvis vi ønskede at indstille img bredden til halvdelen af ​​browserbredden, ville vi bruge:

Dette er ikke særlig nyttigt, før vi kombinerer det med medieforespørgsler ...

Brug af medieforespørgsler

Størrelsesattributten bliver meget mere kraftfuld, når vi kombinerer det med medieforespørgsler. Vi kan adskille flere visningsbredder ved hjælp af kommaer og fortælle browseren, hvilke der skal bruges ved brug af en CSS-stil mediesøgning.

Forestil dig for eksempel, at vi ønsker, at et billede skal udgøre 80% af bredden af ​​vores viewport på de fleste enheder, men på små enheder (som telefoner) med en bredde på 380px eller mindre, vil vi få det bedste ud af det plads til rådighed ved at gøre op 100% af bredden, ville vi skrive det som:

Efter denne logik vil enhver browser med en visning på 380 px eller mindre indstille bredden af ​​billedet til 100% af visningsporten. Enhver anden browser vil medføre, at medieforespørgslen returneres falsk, og browseren vil flytte til den næste værdi af størrelsesattributten , hvilket i dette tilfælde er 80vw.

Som en generel regel er jeg ubehagelig ved at bruge medieforespørgsler i HTML. Ligesom responsive billeddata tilhører HTML (ikke JavaScript), hører medieforespørgsler i CSS (ikke HTML). Men muligheden er der for dig, hvis du har brug for det.

Responsive image best practice (2016?)

Jeg ved ikke om dig, men jeg er meget begejstret for mulighederne for srcset. Det er en simpel løsning på et vanskeligt problem, og synes at levere alt, hvad vi har brug for.

Men som busser venter du 20 år for en officiel løsning på lydhørede billeder, og så kommer to op på én gang. I tillæg til srcset- attributten for img- elementet har vi også billedelementet.

Billedelementet er en anden pladsholder, omend en mere traditionel. Det er blevet konstrueret til at efterligne video- og lydelementerne i HTML5, så dets syntaks vil være kendt for de fleste. Billedelementet er beregnet til at blive brugt, når du har brug for mere kontrol end, at srcset kan levere.

Desværre har billedelementet langt mindre browser support end srcset, og det svigter ikke altid lydløst.

Brug af billedelementet

Her er vores originale billedelement:

an image

Her er vores billede nestet inde i et billedelement:

an image

Vi kan også angive en srcset for et img element inde i et billedelement:

Brug af kildeelementet

Billedelementet kommer ikke til liv, før vi tilføjer kildeelementet :

an image

Når du vælger hvilken fil der skal bruges, starter browseren med det første kildeelement , og bevæger sig gennem elementerne, indtil det finder en, hvis mediefunktion løser sande, så bruger den kildeelementets srcset.

For eksempel kunne vi angive forskellige billeder til portræt og landskabsformater:

an image

Vi kan også angive flere billeder ved hjælp af x-descriptor og w-descriptor:

an image

Som med brugen af ​​medieforespørgsler i størrelsesattributten , ville jeg stille spørgsmålstegn ved visdommen ved at kontrollere billedversioner baseret på stil, i markering i stedet for et stylesheet. Men muligheden for at bruge medieattributten er der, hvis du har brug for den.

Brug af type

Billedelementet kommer virkelig i sig selv, når det bruges til at bytte ud forskellige typer billeder.

Forestil dig, at vi har en standard PNG-fil, men vi vil bruge en WebP-fil, som typisk er 26% mindre - husk lydhøre billeder handler om at levere den bedste billedkvalitet, med den mindste størrelse - men understøttes for øjeblikket kun af Chrome, Opera og Android-browseren. Vi skal bruge typen attributten for at afgøre, om WebP understøttes:

I dette tilfælde kontrollerer browseren, om WebP-billedformatet understøttes. Hvis det er, vil det afgøre, om skærmen har nok pixeldensitet til at vise retina-image.webp- billedet, hvis det ikke vil vise billedet.webp- billede. Hvis WebP ikke understøttes, springer browseren direkte hen til img- elementet og arbejder gennem srcset og src- indstillingerne som vi allerede er bekendt med.

Typetypen betyder, at vi kan levere meget mindre billedformater, hvor det understøttes, hvilket resulterer i en mindre filstørrelse.

Kendte problemer

IE9 har et kendt problem, der forhindrer billedelementet i at svigte. For at kunne håndtere IE9 skal du narre IE9 til at tro at kildematerialerne er en del af et videoelement :

< !—[if IE 9]>< ![endif]—>

Det er en grim løsning, men bedre end ingen løsning overhovedet. Vi håber kun, at udgivelsen af ​​Windows 10 vil fremskynde nedgangen i IE9, fordi Edge endnu ikke understøtter billedelementet, understøtter den ikke på den rigtige måde (ved at ignorere det).

Der er polyfills der kan hjælpe dig med at støtte billedelementet på IE, men min egen præference er at undgå dem. Jeg mistillid patch problemer med JavaScript, det påvirker ydeevnen og fører til mindre vedligeholdelige kode.

Af denne grund anbefaler jeg at undgå billedelementet for nu. Medmindre du kører et stort e-handelswebsted, er det usandsynligt, at den ekstra besparelse på downloadtidspunktet, som WebP-formatet tilbyder, opvejer ulejligheden ved at patchere din markering med script.

Når IE9 falder under 1%, hvilket skal ske på et eller andet tidspunkt i det næste år, bliver billedelementet levedygtigt. Hvis du læser dette i 2016, er du sikkert god at gå.

Oprettelse af lydhøre billeder

I modsætning til SVG opgraderer bitmapbilleder ikke op. Vores strategi for at håndtere dem, uanset om vi bruger srcset eller billedelementet, er at levere et andet billede baseret på browserens evner. For at kunne håndtere det skal vi levere en række forskellige billedstørrelser.

De fleste billedredigeringsprogrammer har automatiseret processen med at eksportere flere versioner af et enkelt billede. Det betyder ikke noget, hvilken applikation du bruger, forudsat at du ender med flere billedstørrelser uden at skulle manuelt ændre størrelse og gemme hver enkelt.

Adobe Photoshop er de facto bitmap editor. Det er ikke et godt valg til designarbejde, men billedbehandlingsprocessen er glat og pålidelig. Generering af flere billedopløsninger i Photoshop er relativt ligetil:

  1. Åbn det billede, du vil generere flere versioner af, og læg det på sit eget lag.
    trin 1

  2. Omdøb laget som navnet på den fil, du vil generere (inklusive udvidelsen).
    step_2

  3. Vælg Filer> Generer> Billedaktiver, og en mappe med dit nye billede gemmes sammen med din PSD.
    Step_3

  4. Omdøb laget, og specificer hvert billede, du vil generere forud for den tilsigtede skala. Du behøver ikke at gentage trin 3, når du omdøber laget, billederne genereres automatisk.
    Step_4

Kredit for billedet går til Philip Collier .

For mere information om generering af billeder i Photoshop, se her.

Baseret på disse billeder kan vi tilbyde browseren fem forskellige muligheder:

Konklusion

Img- elementet er kommet langt i 20 år. Eller for at være mere præcist var img- elementet utilstrækkeligt i 18 år og sprintede for linjen i de sidste to år, til det punkt, at det nu er relativt sofistikeret.

Det vigtige er, at vi kom til løsningen (r).

Af de to tilgængelige muligheder, srcset og billede er den tidligere langt den mest understøttede. Hvis du bygger 95% af webstederne derude, er den overlegne support og enklere implementering af srcset- attributten din bedste løsning.

Hvis du kører et stort e-handelssite med tusindvis af produktbilleder, kan det ekstra arbejde, der tjener WebP-formatet, være umagen værd, især da støtte til billedelementet stiger i løbet af de næste par år.

Den største svaghed i de nuværende muligheder er, at browsere i øjeblikket ikke har mulighed for at vælge et billede baseret på deres forbindelseshastighed. Vi er tvunget til at stole på, at mere dygtige enheder også er på overlegne forbindelser.

I sidste ende kan vi endelig servere billeder af højeste kvalitet praktisk muligt, med den mindste størrelse. Det betyder en bedre oplevelse på kortere tid, som kun kan være noget at omfavne.

Udvalgte billedbrug, bjergbillede og enhed billede via Shutterstock.