Mens mobile enheter og tablett Når de endelig kommer nærmere verdensherredømme, er webteknologi i løpet av å imøtekomme de stadig voksende tallene i skjermstørrelse. Imidlertid gir utviklingen av verktøy for å følge med dette fenomenet oss et helt nytt sett med problemer, med et av de siste ordene som dukker opp: “Nettresponsiv” . Dette er utfordringen med å få nettet til å fungere på de aller fleste, om ikke alle, enheter uten å redusere kvaliteten på brukeropplevelsen. I stedet for å utforme innhold som passer på en stasjonær eller bærbar datamaskin, må informasjonen være tilgjengelig for mobiltelefoner, nettbrett eller andre overflater som er koblet til nettet. Imidlertid er denne utviklingen av Responsivt webdesign Det har vist seg vanskelig og noen ganger smertefullt.

Selv om det kan være nesten trivielt å imøtekomme tekstinformasjon, vises den vanskelige delen når vi vurderer innhold som responsive bilder, infografikk, videoer og så videre, som en gang ble designet med stasjonære datamaskiner i tankene. Dette reiser ikke bare spørsmålet om å kunne vise innholdet riktig, men også hvordan selve innholdet konsumeres ved hjelp av forskjellige enheter. Smarttelefonbrukere er forskjellige fra brukere av stasjonære datamaskiner. Ting som dataplaner og behandlingshastighet er ting du må huske på. Google har begynt å markere nettsteder som er mobilvennlige i søkeresultatene, med noen spekulasjoner hvis det vil føre til en betydelig økning i rekkene til disse nettstedene. Tidligere løsninger fokuserte på dette ved å lansere underdomener som bare var mobile (og omdirigert), men dette økte kompleksiteten og ble raskt utdatert. (Ikke alle nettsteder har muligheten til å ha råd til denne ruten).

I responsivt bildesøk på nettet

På dette punktet kan utviklere og designere sørge for at nettstedslastingen deres er optimalisert for brukere på mobile nettsteder. Mer enn 20% av nettrafikken kommer nå fra mobilbrukere, og antallet vokser. Med bilder som tar inn blant de største delene av datainnhold, har dimensjonering blitt en prioritet, inkludert server-side og front-end-løsninger. For å diskutere disse løsningene for å endre størrelse, må vi først forstå de nåværende manglene ved å koble bilder.

det har bare kildeattributtet koblet direkte til selve bildet. Du har ingen måte å bestemme riktig type bilde uten behov for tillegg.

Kan vi ikke bare sette alle bildestørrelsene som er inkludert i HTML-en, og bruke CSS-regler for å sette display:none for alt annet enn riktig bilde? Det er den mest logiske løsningen i en perfekt logisk verden. Men på denne måten kan nettlesere ignorere alle ikke-eksponerte bilder og teoretisk ikke laste dem ned. Nettleserne er imidlertid optimalisert utover vanlig logikk. For å gjøre siden gjengitt så raskt som mulig, forhåndsviser nettleseren koblet innhold, selv før stilarkene og JavaScript-filene er fullastet. I stedet for å ignorere de store bildene som er ment å skrivebordet endte vi med å laste ned alle bildene, noe som resulterte i en mye større side å laste inn. Den eneste CSS-teknikken fungerer bare for bilder som er ment som bakgrunn fordi disse kan settes i stilark (ved hjelp av mediespørsmål ).

Så hva skal et nettsted gjøre?

Back-End-løsninger for skalerbarhet

Med unntak av nettsteder / underdomener som bare er mobile, snuser vi brukeragenten (UA) og bruker den til å levere riktig størrelse på bilder til brukeren. Enhver utvikler kan imidlertid vitne om hvor upålitelig denne løsningen kan være. Nye UA-tråder vises hele tiden, noe som gjør det slitsomt å vedlikeholde og oppdatere en omfattende liste. Og selvfølgelig tar dette ikke engang hensyn til hvor upålitelige og enkle å lure UA-tråder til å begynne med.

Tilpassbare bilder

Noen sekundære serverløsninger er imidlertid verdt å vurdere. Tilpassbare bilder det er en flott løsning for de bakre endene som er responsive responsive bildearriser. Krever ingen markering spesiell, men på den annen side bruker den en liten JavaScript-fil og gjør det meste av tungt løft i bakfilen din. Den bruker PHP og en konfigurert nginx-server. Det er heller ikke avhengig av UA-sporing, og sjekker i stedet bredden på skjermen. Adaptive Images fungerer bra for å skalere bilder, men er også nyttige når store bilder trenger det kunstretning For eksempel reduksjon av bilder ved hjelp av teknikker som beskjæring og rotering, ikke bare skalering.

Trykk på Sencha

Sencha Touch er en annen back-end-løsning for responsive designbilder, selv om det best omtales som en outsourcet løsning. Sencha Touch vil endre størrelse på bildet tilsvarende når du sporer UA. Nedenfor er et grunnleggende eksempel på hvordan denne tjenesten fungerer:

Det er også muligheten til å spesifisere størrelser, hvis vi ikke vil at Sencha skal endre størrelsen automatisk. På slutten av dagen vil sekundære serverløsninger (og outsourcede) kreve ressurser for å behandle forespørselen før de sender riktig bilde tilbake. Dette tar dyrebar tid og reduserer dermed forespørselsresponsen. En bedre løsning kan være hvis enheten selv bestemmer hvilken ressurs som skal ringes direkte, og serveren svarer riktig.

Front-End-løsninger

I nyere tid har det vært store forbedringer på nettlesersiden for å løse problemer med responsive bilder.

Elementet den er introdusert og godkjent i HTML5-spesifikasjonene av W3C. Den er foreløpig ikke tilgjengelig i alle nettlesere, men det vil ikke vare lenge før dette skjer. Inntil da stoler vi på polyfills Javascript for elementet. Polyfills er også en flott løsning for eldre nettlesere som mangler dette elementet.

Det er også tilfellet med attributt srcset Egenskap som er tilgjengelig for forskjellige nettleserbaserte WebKits for -elementet. Dette kan brukes uten JavaScript og er en flott løsning hvis nettlesere som ikke er webKit blir ignorert. Det er en god midlertidig ressurs i det sjeldne tilfellet hvor andre løsninger ikke er nok, men det skal ikke betraktes som en omfattende løsning.

Bildefyll

Bildefyll det er en bokhandel polyfill for elementet. Det er en av de mest populære bibliotekene i en rekke front-end-løsninger for skalerbarhet og relaterte problemer. Det er to versjoner; Bildefyll v1 etterligner elementet ved hjelp av span mens Picturefill v2 bruker elementet blant nettlesere som allerede har det og gir polyfill for eldre, (f.eks. for IE> = IE9). Har noe begrensninger og forstyrrelser , spesielt for Android 2.3 - som for øvrig er et eksempel på hvordan img srcset kommer til unnsetning. Her er et utvalg av markering for bruk av Picturefill v2:

For å forbedre ytelsen for brukere med begrensede dataplaner kan Picturefill være kombinert med lat belastning . Imidlertid kan biblioteket tilby mer omfattende nettleserstøtte og håndtere rare saker i stedet for å stole på oppdateringer.

Imager.js

Imager.js er et bibliotek opprettet av teamet av BBC nyheter for å oppnå at responsive bilder hadde en annen tilnærming enn den som ble brukt i Picturefill. Mens du prøver å bringe varen til nettlesere som ikke støttes, konsentrerer Imager.js seg om å laste ned bare de riktige bildene mens du ser på nettverkshastigheter. Den inkluderer også lat belastning uten å stole på outsourcede biblioteker. Det fungerer ved å sette elementer av plassholder og erstatt dem med elementer. Koden vist 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 en progressiv løsning.

Source Shuffling

Source Shuffling nærmer seg dette problemet fra en litt annen vinkel enn resten av front-end-bibliotekene. Det ser ut som noe fra den 'mobile først' skoletankegangen, der den serverer den minste mulige oppløsningen som standard. Ved å oppdage hvilken enhet som har større skjerm, endrer den bildekilden til en større. Det føles mer som en hack og mindre som en fullvoksen bokhandel. Dette er en flott løsning hovedsakelig for mobilnettsteder, men det betyr at dobbel nedlasting av ressurser for stasjonære og / eller nettbrett er uunngåelig.

Andre bemerkelsesverdige JavaScript-biblioteker er:

• HiSRC - Et jQuery-plugin for responsive bilder. Å stole på jQuery kan være et problem.

• Mobify.js - Et generelt bibliotek for responsivt innhold, inkludert bilder, stilark og til og med JavaScript. 'Fang' dOM før ressursen lastes. Mobify er et kraftig og omfattende bibliotek, men det kan være overkill hvis målet er å bare ha responsive bilder.

oppsummert

På slutten av dagen er det opp til utvikleren å bestemme hvilken tilnærming som skal brukes i Responsivt webdesign bilder for brukerbasen din. Dette betyr at datainnsamling og testing vil gi deg en bedre ide om hvilken tilnærming du skal bruke.

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

• Er eldre nettlesere et problem? Hvis de ikke er det, bør du vurdere å bruke en mer moderne tilnærming (f.eks. Bildefyll, attributt srcset).

• Er responstid kritisk? Hvis det ikke er det, kan du velge en back-end eller outsourcet løsning.

• Bør løsningene være interne? Outsourcede opsjoner er åpenbart uaktuelt.

• Er det mange bilder på nettstedet som prøver å gå over til responsive bilder? Er det bekymringer for validering eller semantiske etiketter (eller ikke-semantiske etiketter)? Dette vil kreve en backend-løsning for å veilede bildeforespørsler til noe som Adaptive Images.

• Er kunstretning et problem (spesielt for store bilder med mye informasjon)? Et bibliotek som Picturefill kan være en bedre løsning for et slikt scenario. Også noen av backend-løsningene kan fungere også.

• Er det noen bekymringer med JavaScript? Enhver front-end-løsning vil ikke være aktuelt, og etterlater alternativer som back-end eller outsourcet som er avhengige av UA-sporing.

• Er det en prioritet for mobil responstid vs stasjonær responstid? Et bibliotek som Source Shuffling bør være det mest passende for den saken.

• Er det behov for å gi responsiv oppførsel til alle aspekter av nettstedet, ikke bare bildene? Mobify kan fungere bedre.

• Er den perfekte verden nådd? Så bruk bare CSS-tilnærming display:none!