Som mobil og tablett enheter kommer nærmere å oppnå endelig verdensherredømme, webdesign og teknologi er i et løp for å imøtekomme det stadig økende antall skjermstørrelser. Å utvikle verktøy for å møte utfordringene ved dette fenomenet bringer imidlertid et helt nytt sett med problemer, med et av de siste moteordene som dukker opp “Responsivt nett” . Dette er utfordringen med å få nettet til å fungere på de fleste, om ikke alle, enheter uten å forringe brukerens opplevelse. I stedet for å utforme innhold som passer til stasjonære eller bærbare datamaskiner, må informasjon være tilgjengelig for mobiltelefoner, nettbrett eller andre overflater som er koblet til nettet. Imidlertid dette Responsivt webdesign evolusjon har vist seg å være vanskelig og noen ganger smertefull.

Selv om det kan være nesten trivielt å imøtekomme tekstinformasjon, kommer den vanskelige delen når vi tar hensyn til innhold som responsive bilder, infografikk, videoer osv., Som en gang ble designet med bare skrivebord. Dette bringer ikke bare opp spørsmålet om å vise innholdet riktig, men også hvordan selve innholdet konsumeres ved hjelp av forskjellige enheter. Brukere på smarttelefoner er forskjellige fra brukere på stasjonære datamaskiner. Ting som dataplaner og behandlingshastighet må også vurderes. Google har begynt å markere mobilvennlige nettsteder i søkeresultatene, med noen spekulasjoner at det vil føre til et betydelig løft på sideresultater til slike nettsteder. Tidligere løsninger adresserte dette ved å distribuere mobile underdomener (og viderekoblinger), men dette økte kompleksiteten og falt raskt ut av moten. (Ikke alle sider har muligheten til å ha råd til denne ruten.)

På jakt etter responsive nettbilder

På dette punktet må utviklere og designere sørge for at nettstedbelastningen er optimalisert for å møte brukerne som er på mobile nettsteder. Over 20% av nettrafikken er nå mobilbrukere, og tallet stiger fortsatt. Med bilder som tar de største delene av sideinnholdsdata, blir det en prioritet å redusere denne belastningen. Det er gjort flere forsøk på å forenkle størrelsen på responsivt design, inkludert både server-side og front-end-løsninger. For å diskutere disse responsive bildeløsningene, må vi først forstå gjeldende mangler ved bildekobling.

tag har bare kildeattributtet som lenker direkte til selve bildet. Det er ingen måte å bestemme riktig type bilde som er nødvendig uten tillegg.

Kan vi ikke bare ha alle bildestørrelsene inkludert i HTML-en, og bruke CSS-regler til display:none for alle, men det riktige bildet? Det er den mest logiske løsningen i en perfekt logisk verden. På denne måten kan nettleseren ignorere alle bildene som ikke vises, og i teorien ikke laste dem ned. Nettlesere er imidlertid optimalisert utover vanlig logikk. For å få siden til å gjengis raskt nok, henter nettleseren på forhånd koblet innhold før selv de nødvendige stilarkene og JavaScript-filene er fullastet. I stedet for å ignorere de store bildene beregnet på stasjonære datamaskiner, ender vi opp med å ha lastet ned alle bildene og resulterer i en enda større sideinnlasting. Den eneste CSS-teknikken fungerer bare for bilder som er ment som bakgrunnsbilder, fordi disse kan settes i stilarket (ved hjelp av mediespørsmål).

Så, hva skal du gjøre på et nettsted?

Back-End Responsive Image Scaling Solutions

Hvis vi sperrer bare mobile nettsteder / underdomener, sitter vi igjen med å snuse brukeragenten (UA) og bruke den til å levere de riktige bildene tilbake til brukeren. Enhver utvikler kan imidlertid attestere hvor upålitelig denne løsningen kan være. Nye UA-strenger dukker opp hele tiden, noe som gjør det anstrengende å vedlikeholde og oppdatere en omfattende liste. Og selvfølgelig tar dette ikke engang hensyn til påliteligheten til UA-strenger som er lett å spoofe.

Adaptive Images

Noen serverløsninger er imidlertid verdt å vurdere. Adaptive Images er en flott løsning for de som foretrekker en responsiv bildefiksering på baksiden. Det krever ingen spesiell markering, men bruker i stedet en liten JavaScript-fil og gjør det meste av det tunge arbeidet i back-end-filen. Den bruker en PHP- og nginx-konfigurert server. Det er heller ikke avhengig av noe UA-sniffing, men sjekker i stedet for skjermbredden. Adaptive Images fungerer bra for å skalere ned bilder, men det er også praktisk når store bilder trenger det kunstretning , dvs. billedreduksjon med teknikker som beskjæring og rotasjon - ikke bare skalering.

Sencha Touch

Sencha Touch er en annen backend-responsiv designbildeløsning, selv om det er bedre å referere til det som en tredjepartsløsning. Sencha Touch vil endre størrelse på bildet ved å snuse UA. Nedenfor er et grunnleggende eksempel på hvordan tjenesten fungerer:

Det er også et alternativ å spesifisere bildestørrelser, i tilfelle vi ikke vil at Sencha skal endre størrelse på bildet automatisk.

På slutten av dagen krever løsninger på serversiden (og tredjeparts) ressurser for å behandle forespørselen før de sender riktig bilde tilbake. Dette tar dyrebar tid og bremser i sin tur forespørselsresponsen. En bedre løsning kan være hvis enheten selv bestemte hvilke ressurser som skal bestilles direkte, og serveren svarer deretter.

Front-End-løsninger

I nyere tid har det vært store forbedringer på nettlesersiden for å adressere responsive bilder.

Theelement har blitt introdusert og godkjent i HTML5-spesifikasjonen av W3C. Den er foreløpig ikke allment tilgjengelig i alle nettlesere, men det vil ikke vare lenge før den er tilgjengelig. Inntil da stoler vi på JavaScript-fyllinger for elementet. Polyfills er også en flott løsning for eldre nettlesere som mangler elementet.

Det er også tilfellet med srcset Egenskap som er tilgjengelig for flere webKit-baserte nettlesere for element. Dette kan brukes uten JavaScript og er en flott løsning hvis nettlesere som ikke er webKit skal ignoreres. Det er en nyttig stopper for det merkelige tilfellet hvor andre løsninger kommer til kort, men ikke bør betraktes som en omfattende løsning.

Bildefyll

Bildefyll er et polyfill-bibliotek for elementet. Det er en av de mest populære bibliotekene blant front-end-løsningene for responsive bildestørrelses- og skaleringsproblemer. Det er to versjoner; Bildefyll v1 etterligner elementet ved hjelp av span mens Picturefill v2 bruker elementet blant nettleserne som allerede tilbyr det og gir en polyfyll for eldre (for eksempel for IE> = IE9). Det har noen begrensninger og arbeid rundt , spesielt for Android 2.3 - som for øvrig er et eksempel på hvor img srcset attributt kommer til unnsetning. Nedenfor er et eksempel på markering for bruk av Picturefill v2:

For å forbedre ytelsen til brukere med begrensede dataplaner, kan Picturefill være kombinert med lat belastning . Imidlertid kan biblioteket tilby bredere nettleserstøtte og adressere de rare tilfellene i stedet for å stole på oppdateringer.

Imager.js

Imager.js er et bibliotek opprettet av BBC nyheter teamet for å oppnå responsive bilder med en annen tilnærming til den som brukes av Picturefill. Mens Picturefill prøver å bringe elementet til nettlesere som ikke støttes, fokuserer Imager.js på å laste ned bare de riktige bildene, samtidig som man holder øye med nettverkshastigheter. Den inneholder også lat lasting uten å stole på tredjepartsbiblioteker. Det fungerer ved å bruke plassholderelementer og erstatte dem med elementer. Eksempelkoden nedenfor viser denne oppførselen:

new Imager({ availableWidths: [480, 768, 1200] });

Den gjengitte HTML-en vil se slik ut:

new Imager({ availableWidths: [480, 768, 1200] });

Nettleserstøtte er mye bedre enn Picturefill på bekostning av å være en mer pragmatisk løsning enn fremtidsrettet.

Source Shuffling

Source Shuffling nærmer seg det responsive bildeproblemet fra en litt annen vinkel enn resten av front-end-biblioteker. Det ligner noe ut av den 'mobile first' tankeskolen, der den tjener den minste mulige oppløsningen som standard. Når det oppdages at en enhet har en større skjerm, bytter den bildekilden til et større bilde. Det føles som mer hack og mindre fullverdig bibliotek. Dette er en flott løsning for hovedsakelig mobile nettsteder, men det betyr at dobbelt ressursnedlasting for stasjonære og / eller nettbrett er uunngåelig.

Noen andre bemerkelsesverdige JavaScript-biblioteker er:

• HiSRC - Et jQuery-plugin for responsive bilder. Avhengighet av jQuery kan være et problem.
• Mobify.js - Et mer generelt bibliotek for responsivt innhold, inkludert bilder, stilark og til og med JavaScript. Den 'fanger' DOM før ressurslastning. Mobify er et kraftig omfattende bibliotek, men kan være overkill hvis målet bare er responsive bilder.

Sammendrag

På slutten av dagen er det opp til utvikleren å bestemme hvilken Responsivt webdesign bildetilnærming passer til brukerbasen. Dette betyr at datainnsamling og testing vil gi en bedre ide om tilnærmingen å ta.

For å avslutte, kan listen over spørsmål nedenfor være nyttig å vurdere før du bestemmer deg for den riktige responsive bildeløsningen.

• Er eldre nettlesere et problem? Hvis ikke, bør du vurdere å bruke en mer moderne tilnærming (for eksempel: Picturefill, srcset attributt)
• Er responstid kritisk? Hvis ikke, velg en tredjeparts- eller back-end-løsning.
• Skal løsningene være internt? Tredjepartsløsninger vil åpenbart utelukkes.
• Er det mange bilder allerede på et nettsted som prøver å gå over til responsive bilder? Er det bekymringer om validering eller semantiske koder (eller rettere ikke-semantiske koder)? Dette vil kreve en back-end-løsning for å dirigere bildeforespørslene til noe som Adaptive Images.
• Er kunstretning et problem (spesielt for store bilder med mye informasjon)? Et bibliotek som Picturefill vil være en bedre løsning for et slikt scenario. Også noen av back-end-løsningene vil fungere også.
• Er det bekymring for mangel på JavaScript? Enhver av front-end-løsningene vil være uaktuelt, noe som etterlater back-end- eller tredjepartsalternativene som er avhengige av UA-sniffing.
• Er det en prioritet for responstider på mobilenheter fremfor svartider på skrivebordet? Et bibliotek som Source Shuffling kan være mer passende.
• Er det behov for å gi responsiv oppførsel til alle sider av nettstedet, ikke bare bilder? Mobify.js kan fungere bedre.
• Er den perfekte verden oppnådd? Bruk bare CSS display:none nærme seg!