Adaptive Images: Løse det Responsive Image Problemet

Responsive design er ikke bare en endring i layout eller bruk av medieforespørsler her og der, det er en sinnstilstand og en handling som har klar betydning.

Responsive design sier i hovedsak at vi bryr oss mer om innholdet enn vi har tidligere. Faktisk, vi bryr oss så mye at vi selv vil optimalisere innhold som skal leses og sees på enheter som ikke har blitt lansert enda.

I hovedsak prøver vi å presentere informasjon så tydelig som mulig og være så effektiv som mulig alle samtidig. Her er en vanlig misforståelse; mobil første måter å designe som om hele nettstedet ditt dreier seg rundt mobiltelefonen. Det er ikke helt nøyaktig. Mobile først betyr ganske enkelt å designe for den enkleste opplevelsen først, noe som ofte fører oss til å kutte ut generelle kostnader som vi opplever eller kan oppleve i fremtiden.

I verden av design; raske beslutninger; respons; og kreativt innhold må vi først og fremst være årvåken. Å være årvåken kommer ned til å vite når vi har et problem i våre responsive design, og hvordan du løser det. I dag gjør vi nettopp det.

Responsive bilder har vært et tøft emne i mange år, siden det har vært mer enn en "hack-around" måte å gjøre bildene dine følsomme. La oss gå gjennom dette emnet fra bakken, og begynne med hvordan vi pleide å gjøre det.

Fortiden

Boston Globe-nettstedet er et klassisk eksempel på flytende design.

Før vi går videre, må vi gå over hvordan en nettside oppfører oss slik at vi kan snakke om hvordan det fungerer. En rask nedlasting: HTML-filen lastes i rekkefølge, og ressursene blir umiddelbart forespurt etter hvert som de oppdages, deretter utføres skript umiddelbart og deretter sendes alle informasjonskapsler med HTTP-forespørsler.

Prosessen med forespørsel / trukket / hent / etc. har lagt litt begrensning på hvordan kreative vi kan få med disse metodene. Selv om det sikkert ikke har stoppet folk i fortiden. Her er noen måter de har fått rundt dette.

Bytte attributten "src"

Vi kan bruke javascript til å omskrive attributten "src", slik at den trekker og erstatter et bilde basert på nettleserstørrelse, som ser ut til å virke helt fint. Dette har vært det mange har brukt tidligere. Problemet med dette er at det bruker en dobbel HTTP-forespørsel. Først trekkes det opprinnelige bildet, og erstatter det med javascript'd-bildet. Du gjør i hovedsak mer enn du ville ha gjort hvis du ikke gjorde noe i det hele tatt, selv om det ser ut til å fungere.

Er det løsninger på dette? Det er faktisk!

Det er en metode som mange bruker hvor vi legger et 1px gif-bilde i stedet i stedet for det faktiske bildet, slik at i stedet for å hente to bilder til prisen på to, får du i hovedsak to for prisen på en - men det er ikke det er heller ikke ideelt. I dette tilfellet gjør du fremdeles to HTTP-forespørsler.

Dette betyr også at du stoler på javascript for alle bilder. Det er vanskelig, fordi mobiloperatører kan rote med javascript, noen andre ting kan bryte javascript, og et overraskende antall nettsidebrukere deaktiverer det med vilje.

noscript

En annen metode som har fått litt popularitet, er å bruke "noscript" -taggen for mobile bilder og deretter bruke javascript til å bytte ut det til et høyere oppløsningsbilde. Dette syntes å ta samfunnet med storm en stund tilbake på grunn av muligheten til å bytte fra mobile opp til high-rez-versjoner, og det var virkelig sammenfallende med den brede feilfortolkningen av "mobile først" jeg nevnte ovenfor. Dette virker ikke i IE. For en Internet Explorer-løsning må du skrive følgende:

Men problemet med det er at nå fungerer det ikke i den populære nettleseren Firefox. Så det vi må gjøre er:

Som du kan se, er det ikke veldig enkelt, og det er absolutt ikke veldig robust. Det er egentlig ikke en måte å gjøre det rent eller enkelt i det hele tatt. Faktisk har mange av de som jobber i lydhør bilder forsøkt å løse disse problemene i mange år, og har egentlig ikke blitt for langt med det.

Vanligvis hva de har gjort, er brukt en slags javascript for å jobbe gjennom problemet og aksepterte dobbelt http-forespørselen som et nødvendig onde.

Server side løsning?

Den typiske server side løsningen for dette er å bruke javascript til å erstatte "src" med HTML5 "-data-highsrc", og lagre nettleserens størrelse i en informasjonskapsel. Selv om det sender den samme flere HTTP-forespørsler som tidligere.

Grunnen til at folk likte denne metoden var at de følte at det var sikrere gitt at de lagret nettleserstørrelsen i en informasjonskapsel, og de følte at det var mindre margin for feil. I virkeligheten skjønt, det er ikke nøyaktig. Her er noen grunner til at denne metoden ikke er like stor som de andre metodene som er oppført hittil. Det tillater bare å hente store og små bilder, det handler ikke om endringer i enhetens orientering, og det bryter dårlig, fordi nå nettlesere forhåndsinnhenter bilder. Også en stor tilbakebetaling er at noen ganger ikke informasjonskapsler er satt raskt nok, noe som resulterer i at skrivebordet får bilder beregnet på mobiltelefoner.

På grunn av alt dette, nemlig en feil av passende alternativer på serveren og klientsiden, trenger vi en ny løsning.

Og dette er akkurat der adaptive bilder Metode trinnene i.

Den adaptive bildemetoden

Adaptive bilder er den sanne løsningen på hele dette konseptet. Det er bokstavelig talt like enkelt som en dra og slippe på serveren din, og du er ferdig. Denne adaptive metoden bruker en htaccess-fil, en php-fil og en enkelt linje med javascript, og det er det .

Du drar bare htaccess og php filen til rotkatalogen din og legger til javascript i hodet på indeksfilen din, og du er ferdig. Ingenting annet å selv bekymre seg for. Nå tilbyr det massevis av tilpasning, men vi kommer inn i det nær slutten.

For nå, la oss hoppe rett inn i begynnelsen av den adaptive metoden.

Målene

Først la oss identifisere prosjektets mål. Skaperen av adaptive bilder, Matthew Wilcox , har identifisert disse som hans mål for denne løsningen:

• Må være lett å sette opp og bruke.
• Må være så lite vedlikehold som mulig.
• Må jobbe med eksisterende innhold, ingen markupredigeringer eller tilpasset CMS er nødvendig.
• Må tillate flere versjoner.
• Må jobbe med designbruddspunkter og ikke brudd på enheter.
• Må enkelt byttes ut når en overlegen løsning kommer.

Og disse målene for dette prosjektet er alle avhengige av antakelsen om at

Etiketter på nettstedet ditt bruker allerede det høyeste oppløsningsbildet, som etter min mening er rimelig antagelse. Vanligvis vil vi ha de beste bildene på vår side allerede, som jeg vet veldig få webdesignere som setter sine beste bilder på telefonversjoner og deres verste på nettet. Det er også ganske selvforklarende.

Hvordan det fungerer

Vi skal bare dykke inn i koden, men før vi gjør det, kan vi snakke om hvordan det fungerer på et høyere nivå. Enkelt sagt, javascript oppdager de største skjermdimensjonene som er tilgjengelige på den enheten, og lagrer den i en informasjonskapsel. .Htaccess-filen peker deretter på visse forespørsler til adaptive-images.php, og deretter basert på disse reglene, gjør PHP-filen noe behandling. Inne i prosessen er der den virkelige magien skjer, og på alle måter vil jeg anbefale alle som leser denne sjekk ut PHP-filen. Det er den vakreste skrevet PHP jeg har sett i år . Det er definitivt et must-see.

La oss nå flytte inn på detaljer om hvordan disse filene fungerer, og samspill med hverandre. Her diskuterer vi alt du får når du laster ned pakken fra adaptiv-bildesiden.

Javascript-koden

JavaScript-koden du må kopiere, er dette:

Og det må gå før andre javascript i hodet ditt . Det er også verdt å merke seg at hvis du vil dra nytte av netthinnen på noen av de nyere Apple-produktene, kan du bruke følgende javascript-linje:

Som du ser, er den siste linjen veldig lik, og den eneste forskjellen er at den vil sende bilder med høyere oppløsning til slike enheter som tillater det. Vær oppmerksom på at det vil bety langsommere nedlastinger for Retina-brukere, men bedre bilder selvfølgelig.

Vær oppmerksom på at dette fortsatt må være det første javascript i hodet ditt.

.Htaccess-filen

En .htaccess-fil er rett og slett et glorifisert katalogadministrasjonsverktøy, og hvis du allerede har et nettsted som du vurderer å bruke adaptive bilder på, har du sannsynligvis allerede en .htaccess-fil, så det vi trenger å gjøre er å legge til noe innhold . Bare åpne den (den ligger alltid i rotkatalogen på nettstedet ditt), og legg til dette:

Options +FollowSymlinksRewriteEngine On# Adaptive-Images ----------------------------------------# Add any directories you wish to omit from the Adaptive-Images process on a new line, as follows:# RewriteCond %{REQUEST_URI} !some-directory# RewriteCond %{REQUEST_URI} !another-directoryRewriteCond %{REQUEST_URI} !assets# Send any GIF, JPG, or PNG request that IS NOT stored inside one of the above directories# to adaptive-images.php so we can select appropriately sized versionsRewriteRule .(?:jpe?g|gif|png)$ adaptive-images.php# END Adaptive-Images ----------------------------------------

Nå er den interessante delen av dette at du egentlig ikke trenger å gjøre noen endringer i det hele tatt.

Vanligvis vil nettsteder at alle bildene skal være lydhør og spille godt med alle formfaktorer, slik at du egentlig ikke trenger å ekskludere noe. Hvis du vil eller trenger det, er det alternativet der, men husk at du vil være responsiv og progressiv. .Htaccess-filen her er perfekt for dette prosjektet, og tjener som en nøkkel i hele prosessen, slik at det uten at du virkelig ikke kan bruke denne metoden. Som et resultat må du sørge for at du ikke glemmer dette, eller legg til det hvis du ikke har en.

PHP-filen

Alt du trenger å gjøre med dette er å dra og slipp det inn i rotkatalogen din, og det vil ta vare på alt annet. Det er en liten tilpassbar seksjon som du kan se her:

/* CONFIG ------------------------------ */$resolutions = array(1382, 992, 768, 480); // the resolution break-points to use (screen widths, in pixels)$cache_path = "ai-cache"; // where to store the generated re-sized images. Specify from your document root!$jpg_quality = 80; // the quality of any generated JPGs on a scale of 0 to 100$sharpen  = TRUE; // Shrinking images can blur details, perform a sharpen on re-scaled images?$watch_cache = TRUE; // check that the adapted image isn't stale (ensures updated source images are re-cached)$browser_cache = 60*60*24*7; // How long the BROWSER cache should last (seconds, minutes, hours, days. 7days by default)/* END CONFIG ------ Don't edit anything after this line unless you know what you're doing -------------- */

Som det står om resten av manuset, hvis du ikke vet hva du gjør så hvorfor ikke bare la det være alene? Hvis du liker tinkering, la oss bare kaste litt lys her.

$ oppløsninger er skjermbredder vi skal jobbe med. I standard vil det lagre et nytt format for store skjermer, vanlige skjermer, tabletter, telefoner og små telefoner.

$ cache_path Hvis du ikke liker at de cached bildene skrives til den mappen, kan du sette den et annet sted. Bare legg banen til mappen her og sørg for at du oppretter den på serveren.

$ Sharpen vil utføre en subtil sletting på de oppskalere bildene. Vanligvis er dette bra, men du vil kanskje slå den av hvis serveren din er veldig opptatt.

$ watch_cache hvis serveren din blir veldig opptatt, kan det hende at ytelsen gjøres til FALSE. Det vil imidlertid bety at du må manuelt rydde ut hurtigmappen hvis du bytter en ressurs.

Nå som du vet alt om tilpasningen, kan du være nysgjerrig, akkurat hva gjør PHP-filen akkurat? Vel, la oss gå gjennom det trinn for trinn:

• Den leser informasjonskapselen og passer til resultatet i bruddpunkter som samsvarer med CSS-brytpunktene
• Den sjekker sin egen cachekatalog for å se om en versjon av den forespurte filen eksisterer ved den pausepunktstørrelsen.
• Hvis det gjør det, sammenligner det datoene på det og opprinnelsen for å sikre at cacheversjonen ikke er foreldet.
• Hvis den ikke finnes i hurtigbufring da oppretter det bare et rescaled bilde hvis kildebildet er større enn breakpointstørrelsen. Da caches det for fremtidig bruk.

Ai-cookie.php filen

Du får også denne filen 'ai-cookie.php' i mappen din når du laster ned den adaptive bildepakken, men dette kan faktisk slettes som det har å gjøre med en alternativ metode for å oppdage brukerens skjermstørrelse. Skaperen av adaptive bilder anbefaler at du sletter dette og går med standardmetoden.

Og det handler om innholdet i pakken. Nå må du sørge for at du tar en titt på alle filene du popper inn på nettstedet ditt, og dobbeltsjekker at du bruker beste praksis med medieforespørsler. Vær også sikker på å stille spørsmål hvis du har noen på dette innholdet eller medieforespørsler generelt, da jeg elsker å snakke om den typen ting. La oss nå oppsummere hva vi har her.

I summering:

Det er sikkert et fascinerende system, og en som jeg forutser å være i bruk i årene som kommer. For det første, hva kan jeg tilpasse med dette systemet som helhet?

Med dette systemet kan du:

• Angi breakpoints for å matche CSS.
• Angi hvor du vil ha hurtigmappen.
• Angi kvaliteten på de genererte JPG-ene.
• Angi hvor lenge nettlesere skal cache bildet for.
• Subtly sharpen genererte bilder.
• Alternativt javascript for å oppdage høye DPI-enheter.

I fremtiden vil jeg også alle elske den til å oppdage båndbredde på et system, i stedet for enhetsstørrelse eller nettleserbredde. Fordi det er den virkelige nøkkelen i å bestemme hvilket bilde du skal sende hvor, men fra nå er det ingen mulig måte å gjøre det på.

Besøk adaptive-images.com å laste ned filene jeg har henvist til i denne artikkelen.