Het web is een visueel medium. De overgrote meerderheid van dat visuele landschap is te danken aan afbeeldingsbestanden. Hoewel er veel kan worden bereikt met CSS en inline SVG, hebben de meeste sites nog steeds afbeeldingsbestanden nodig.
Gemiddeld genomen worden afbeeldingen geregistreerd meer dan de helft van paginagrootte vorig jaar, en van jaar tot jaar nemen de beeldgroottes toe; er was een 21% groei alleen in beeldformaat in 2014.
Tegelijkertijd blijft het aantal en de diversiteit van apparaten die toegang krijgen tot het web groeien. De resoluties variëren nu ergens tussen de 72ppi (steeds vaker voor) en meer dan 600ppi.
Een afbeelding maken voor het scherm dat van voldoende kwaliteit is voor elk apparaat is eenvoudig: bewaar het op 1000ppi en noem het een dag. De resulterende afbeelding is knapperig op zelfs de hoogste hi-res apparaten. Maar terwijl je kwaliteit hoog zal zijn, geldt dat ook voor je bestandsgrootte. Met laadtijd van de pagina a sleutelfactor in UX het is aan ons om ervoor te zorgen dat sites snel aan onze gebruikers worden geleverd. Wanneer afbeeldingen van zo'n hoge kwaliteit zijn dat ze een tiental seconden nodig hebben om te downloaden via breedbandverbindingen, laat staan mobiele verbindingen, dan zijn ze effectief onbruikbaar.
Het doel van responsieve beelden is dan ook niet om een beeld van hogere kwaliteit te leveren aan schermen die het kunnen weergeven (wat we gemakkelijk kunnen doen), het doel is om de best mogelijke beeldkwaliteit te leveren en niets meer.
Deze gids is bedoeld om u te leren wat werkt, waar de problemen en valkuilen nog steeds liggen, en hoe u tegenwoordig responsieve afbeeldingen op websites kunt gebruiken.
Ik voel de behoefte, de behoefte aan snelheid
Waarom is snelheid belangrijk? Er is toch niemand meer op een 3G-verbinding? Niemand gebruikt inbellen. Als de demografische doelgroep van uw klant woont in het centrum van Manhattan, waarom zou u dan om het platteland van Lesotho geven? Het is een feit dat het een mythe is dat we allemaal op supersnelle breedband werken, verkocht aan ons door bedrijven die profiteren van het verlangen naar steeds hogere snelheden.
De meeste mensen brengen ten minste twee uur per dag door in een inferieure verbinding. Ik merk vaak dat ik de meeste tijd heb om te bladeren tijdens het woon-werkverkeer, zelfs als een betrouwbare 3G-verbinding klinkt als een droom.
In april Google aangekondigd dat mobiele vriendelijkheid wordt gebruikt als een rangordefactor voor zoekopdrachten die worden uitgevoerd op apparaten die het als 'mobiel' beschouwt. Zelfs daarvoor snelheid was een factor in paginarangschikking - zowel expliciet als onderdeel van de berekeningen van Google, en impliciet als een bijdragende factor aan uw bouncepercentage.
In twee identiek gerangschikte sites kan een extra 1Kb u van de derde plek op Google naar de vierde of vijfde plaats brengen. Het kan u zelfs van 10 naar 11 brengen - met andere woorden van pagina 1 tot pagina 2 - met alle bijbehorende gevolgen voor de inkomsten van uw klant.
Heb je dat beeld echt nodig?
Het meest geoptimaliseerde beeld dat er is, is helemaal geen beeld. Als je vijf afbeeldingen op je site hebt en er een hebt neergezet, heb je jezelf 20% bespaard, misschien nog belangrijker, je hebt jezelf een http-verzoek opgeslagen. Als we alle afbeeldingen van onze sites hebben verwijderd, besparen we ons 100% en alle vijf http-verzoeken. Dus waarom niet doen?
We plaatsen geen afbeeldingen van onze sites omdat ze op korte termijn effectiever communiceren dan tekst. Ze creëren een emotionele band die gebruikers naar inhoud trekt.
We weten dat gebruikers lezen geen webpagina's . Zeer weinig mensen lezen diepgaande online-inhoud. Met afbeeldingen kunnen we een merk verbinden, communiceren en versterken in een fractie van de tijd die tekst kan beheren.
Afbeeldingen kunnen groot en onpraktisch zijn om te downloaden, maar eenmaal weergegeven in de browser zijn ze veel efficiënter dan tekst voor het vaststellen van gebruikersbetrokkenheid en het versterken van een merkboodschap.
Responsieve beelden helpen ons ervoor te zorgen dat de opbouw van emotionele verbindingen niet verloren gaat wanneer de ongeduldige gebruiker op de terugknop drukt.
Hoe zit het met SVG?
SVG (Scaleable Vector Graphics) is een van de echte baanbrekende technologieën van het web. Het is zo ver vooruit op de curve dat de meeste ontwerpers nog steeds niet het ware potentieel ervan hebben herkend.
SVG - zoals de naam al aangeeft - is gebaseerd op vectoren. Dit betekent dat SVG-afbeeldingen zijn opgebouwd uit punten, hoeken en afstanden. SVG is ook - zoals de naam al aangeeft - schaalbaar, wat betekent dat het net zo goed zal worden weergegeven op een 5k iMac of een Android-smartphone, zonder verlies van kwaliteit en zonder wijziging van de bestandsgrootte.
Als u een platte illustratie, een pictogram, een logo, vrijwel alles dat kan worden weergegeven als een SVG, dan is SVG de juiste keuze.
De meeste afbeeldingen op het web zijn bitmaps. Over het algemeen is de manier waarop een bitmap werkt elke pixel één voor één te beschrijven, de kleur (in RGB - rood, groen en blauw) en in sommige gevallen de transparantie. Als u een afbeelding van 100 px bij 100 px hebt, hebt u een afbeelding met 10.000 pixels; als elke pixel 4 waarden heeft om deze te beschrijven, dan heeft de afbeelding 40.000 bits aan gegevens die ermee geassocieerd zijn. Klinkt als veel, nietwaar? Soms is dat minder dan een vectorafbeelding.
Overweeg een afbeelding van 1 px bij 1 px; dat zou 4 bits gegevens vereisen om te registreren als een bitmap (rode, groene, blauwe en alpha-waarden). Beschouw nu hetzelfde vierkante pixel opgenomen als een vector; dat zou de x, y, breedte en hoogte van de rechthoek vereisen, naast de RGBA-waarden.
Dat zijn ruwe voorbeelden, maar ze zijn juist. Vaak overschrijdt een vectorversie van een afbeelding - als we er een beschikbaar hebben - de bestandsgrootte van de equivalente bitmap en is bitmap de enige verstandige keuze.
(Mis) met behulp van JavaScript
Zoals de meeste problemen in het leven (als je leven online is), kunnen responsieve afbeeldingen worden opgelost door JavaScript. In feite was JavaScript een aantal jaren de enige manier om het probleem op te lossen. JavaScript kan de capaciteiten van een gebruikersagent testen, bepalen wat voor soort browser het is en een standaard HTML-afbeeldingstag schrijven met de juiste afbeelding.
Webontwerpers die bezwaar maken tegen het gebruik van JavaScript doen dat meestal omdat sommige mensen zetten het uit . Dat is echter niet langer het geval, vooral niet op het mobiele internet, maar er zijn enkele hardnekkige problemen: het schrijven van een afbeelding met JavaScript betekent dat de afbeelding niet wordt geparseerd door bots van zoekmachines, en deze wordt alleen weergegeven na het script als run, bijvoorbeeld.
Het grootste probleem met het gebruik van JavaScript is dat het een verkeerd gebruik van het hoofddoel van JavaScript is. HTML bevat gegevens, CSS verwerkt presentatie, JavaScript handelt functionaliteit af. Wanneer we breken met die gestructureerde rollen, beginnen we problemen tegen te komen die hacks vereisen om ze te repareren. Afbeeldingen zijn gegevens en moeten daarom met HTML worden afgehandeld.
Het probleem met browsers
Sinds RWD voor het eerst werd bedacht, waren afbeeldingen het grootste struikelblok. Maar nu beginnen we manieren te vinden om de verschillende problemen op te lossen. Technieken die gevechtsgehard en succesvol genoeg zijn om als best-practice te worden beschouwd. Toegewijde ontwikkelaars hebben hun tijd opgegeven om te lobbyen bij de WC3 voor officiële oplossingen en nu zijn voor het eerst responsieve beelden praktisch.
De sleutel tot responsieve beelden is dat ze zijn ontworpen met een volledig bewustzijn van de tekortkomingen van het web. Er is voor gezorgd dat responsieve beeldoplossingen bestaande browsers niet doorbreken, zodat zelfs in browsers die geen responsieve afbeeldingen ondersteunen, de code stil zal falen en niet-responsieve standaardafbeeldingen zullen worden weergegeven.
In dit artikel kijken we naar twee officiële responsieve HTML-elementen voor afbeeldingen: srcset en picture.
Op dit moment ondersteunen Edge, Safari en iOS Safari alleen een subset van de specificatie srcset . Firefox, Chrome, Opera, Android Browser en de komende versies van Safari en iOS Safari ondersteunen dit volledig. (We bespreken de onderstaande verschillen.)
Momenteel wordt het beeldelement volledig ondersteund door Firefox, Chrome, Opera en Android Browser. Edge, Safari en iOS Safari ondersteunen dit niet en hebben geen tijdschema aangekondigd voor de implementatie ervan.
Zelfs onder browsers die de nieuwe code ondersteunen, zijn er inconsistenties omdat verschillende browserfabrikanten de W3C-specificaties op verschillende manieren interpreteren. Wanneer u bijvoorbeeld een wijziging van de afbeelding opgeeft van klein naar groot op basis van de kijkvenstergrootte, zullen sommige browsers overschakelen naar de grote afbeelding wanneer het kijkvenster 1 px groter is dan de voorkeursgrootte van de kleine afbeelding, andere zullen alleen overschakelen naar de grote afbeelding wanneer de kijkvenster begunstigd door de grote afbeelding is volledig gekoppeld.
Kort samengevat, browsers zijn opgesplitst in twee kampen: die waar mogelijk afbeeldingen van hogere kwaliteit begunstigen en waar mogelijk kleinere downloads. Browserfabrikanten schoppen dit nog steeds af, en uiteindelijk zal iemands implementatie het meest populair zijn - persoonlijk hoop ik dat dit de laatste is, omdat zoals hierboven vermeld, de prestaties cruciaal zijn voor de gebruikerservaring.
Voor nu is de beste optie voor webontwerpers om zich aan de specificatie te houden en niet te proberen de browser een tweede keer te raden. De standaardervaring in de browser (hogere kwaliteit of snellere downloads) is immers onderdeel van waar een gebruiker een standaardbrowser voor selecteert, dus als de gebruiker op de hoogte is van de verschillende benaderingen, is de voorkeur van de gebruiker waarschijnlijk ook de voorkeur van de gebruiker. .
Responsieve afbeelding van best practices (2015)
In de geschiedenis van het web hebben we één element gebruikt om een afbeelding aan te duiden, het img- element. In HTML5 heeft het img- element een subtiele verschuiving in zijn rol ondergaan, een die is ontworpen om responsieve afbeeldingen mogelijk te maken: het img- element vertegenwoordigt niet langer een afbeelding, het is nu een tijdelijke aanduiding voor een afbeelding.
Dat onderscheid is belangrijk, omdat terwijl een img- element eerder een enkele set afbeeldingsgegevens bevatte - die bitmap of vector zijn - nu een afbeelding meerdere gegevenssets kan bevatten.
Het img- element (om samen te vatten voor niet-codeerders) ziet er als volgt uit:
De responsieve afbeeldingsversie van het img- element ziet er als volgt uit:
Nauwelijks enige verandering. Als u naar deze code kijkt, merkt u één belangrijk ding op: de code is compatibel met eerdere versies. Als er een browser langskomt die het attribuut srcset niet begrijpt, negeert het dit en maakt het de afbeelding volgens de oorspronkelijke specificatie uit 1993.
Wat dit betekent, is dat we nu responsieve afbeeldingen kunnen gebruiken in onze opmaak, zonder de noodzaak voor kenmerkdetectie.
In het nieuwe reagerende img- element wordt src voornamelijk gebruikt als standaardafbeelding en voor browsers die srcset niet herkennen , terwijl srcset alle beschikbare high-res- formaatafbeeldingen voor die tijdelijke aanduiding bevat.
Bij het renderen van het img- element zal de browser zelf bepalen welk beeldbestand het meest geschikt is.
Met behulp van srcset
Nu we weten dat srcset stilletjes zal mislukken in browsers die dit niet ondersteunen, kunnen we een extra afbeelding toevoegen:
In dit geval zal elke browser die srcset ondersteunt image-b.jpg weergeven en elke browser die geen ondersteuning biedt voor srcset zal image-a.jpg weergeven .
Het is belangrijk om te weten dat de browser alleen de afbeelding download die hij wil weergeven, hij downloadt niet beide afbeeldingen en kiest er vervolgens een.
Helaas komt dit ons niet ver, want tenzij we srcset- ondersteuning demonstreren, is er geen praktische toepassing voor het schakelen van afbeeldingen op basis van alleen ondersteuning voor srcset .
De oplossing is om de browser extra informatie te geven over welke afbeelding hij moet kiezen. Om dat te doen, moeten we informatie verstrekken over beschikbare ruimte of pixeldichtheid.
Met behulp van x-descriptor
De x-descriptor vertelt een browser hoe dicht de pixels in een afbeelding zijn.
Als u bijvoorbeeld een beeld van het netvlies-kwaliteit wilt bieden met tweemaal het aantal pixels als standaardafbeelding, geeft u de retina-afbeelding op in de set, gevolgd door een spatie en vervolgens het trefwoord '2x'.
We hebben ons beeld:
Om een retina-optie voor de browser toe te voegen, voegen we de volgende srcset toe:
In dit geval zijn er drie mogelijke uitkomsten:
als de browser geen ondersteuning biedt voor srcset , wordt het afbeeldingsbestand gebruikt dat is opgegeven in het attribuut src ;
als de browser srcset ondersteunt en een scherm heeft dat in staat is tot een dubbele resolutie, gebruikt het de afbeelding die is opgegeven in het attribuut srcset;
als de browser srcset ondersteunt maar geen scherm met hoge resolutie heeft, gebruikt deze de afbeelding die is opgegeven in het kenmerk src (wanneer er geen "1x" -afbeelding is opgegeven in het attribuut srcset , wordt aangenomen dat het src- attribuut die afbeelding is keuze).
Browserondersteuning is goed en verbetert snel. Met één attribuut hebben we het raadsel van responsieve beelden opgelost, yay us!
Nog een ding om op te letten over de x-descriptor: de keuze van welke afbeelding moet worden geladen is gebaseerd op pixeldichtheid, dus als een gebruiker hun browser inzoomt op 200% (de afbeelding effectief halveren, en dus de pixeldichtheid verdubbelt), dan is de 2x afbeelding wordt geladen. Dit kan een nadelig effect hebben op de toegankelijkheid - we willen zeker niet dat sites langzamer laden voor slechtzienden, gewoon omdat ze ervoor kiezen om in hun browser te zoomen.
W-descriptor gebruiken
De w-descriptor is iets geavanceerder dan de x-descriptor. De w-descriptor werkt door de browser te vertellen hoeveel werkelijke pixels op de x-as (de breedte) van een bepaalde afbeeldingsoptie aanwezig zijn.
Edge, Safari en iOS Safari ondersteunen geen w-descriptor op het moment van schrijven, dus het nut is enigszins verminderd.
Laten we terugkeren naar onze oorspronkelijke afbeelding:
Als dit beeld oorspronkelijk 1600 pixels breed is en we een retina-afbeelding willen toevoegen, zoals we deden met de bovenstaande x-descriptor , zouden we een afbeelding opgeven in het srcset- attribuut dat 3200 pixels breed is:
Er is één belangrijke gotcha met de w-descriptor: hoewel het src -kenmerk wordt behandeld als de standaardwaarde bij het opgeven van afbeeldingen met de x-descriptor, wordt het geheel genegeerd door browsers die srcset ondersteunen als u de w-descriptor gebruikt. Wanneer we de w-descriptor gebruiken , moeten we de standaardinstelling expliciet opgeven door een tweede srcset- afbeeldingsoptie toe te voegen, met zijn eigen w-descriptor, en deze te scheiden met een komma:
Dat brengt ons keurig op ...
Meerdere afbeeldingen gebruiken
Het is beslist cool om een hoge resolutie afbeeldingsoptie voor de browser in onze HTML-code te kunnen specificeren, maar zoals je waarschijnlijk al geraden had, wordt het nog cooler als we meerdere afbeeldingen specificeren.
Het doel van responsieve afbeeldingen is om de beste beeldkwaliteit te leveren die bruikbaar is door het toegangsapparaat, maar niets meer. Dus het eenvoudigweg leveren van een retina-afbeelding is niet voldoende, we moeten afbeeldingen leveren op bijvoorbeeld 1x, 1.5x, 2x, 2.5x en 3x.
Nogmaals, dit is onze originele afbeeldingmarkering:
Hier is het met een afbeelding van het netvlieskwaliteit die als optie voor de browser wordt geleverd:
Hier is het, deze keer met extra opties in de set, gescheiden door komma's:
Omdat zoekwoorden verschillende dingen betekenen voor verschillende mensen, vind ik het raadzaam om mijn afbeeldingen een naam te geven volgens de x-descriptor waartoe ze behoren, beide als persoonlijk geheugensteuntje en om ervoor te zorgen dat de verschillende grootten duidelijk zijn voor andere teamleden:
Vergeet niet dat we de browser niet vertellen welk beeld moet worden weergegeven, we laten het de beschikbare opties kennen en kunnen het voor zichzelf selecteren. De browser zal slechts een van deze afbeeldingen downloaden.
Eén gotcha met meerdere afbeeldingen: geef nooit twee afbeeldingen op in het kenmerk srcset met een overeenkomende x-descriptor en w-descriptor, bijvoorbeeld:
Het kenmerk sizes is een bijzonder interessante toevoeging aan de specificatie, omdat het kenmerk sizes de waarden ten opzichte van het kijkvenster en niet de afbeelding gebruikt.
Als we de waarde vw (viewport width) gebruiken, specificeren we het afbeeldingsgebied ten opzichte van de breedte van de browser. Onthoud dat het img- element nu eigenlijk alleen maar een tijdelijke aanduiding is, dus we geven niet de werkelijke grootte van de afbeelding op. We specificeren de grootte van de placeholder die de afbeelding zal bevatten.
100vw is 100% van de viewportbreedte, 50vw is 50% van de viewportbreedte, 25vw is 25% van de viewportbreedte, etc.
Als we de img- breedte willen instellen op de helft van de breedte van de browser, gebruiken we:
Dit is niet erg handig, totdat we het combineren met mediaquery's ...
Mediaquery's gebruiken
Het kenmerk sizes wordt veel krachtiger wanneer we het combineren met mediaquery's. We kunnen meerdere viewport-breedten scheiden met behulp van komma's en de browser vertellen welke te gebruiken door een media-query in CSS-stijl te gebruiken.
Stel u bijvoorbeeld voor dat een afbeelding 80% van de breedte van onze viewport op de meeste apparaten moet hebben, maar op kleine apparaten (zoals telefoons) met een breedte van 380 px of minder, willen we optimaal profiteren van de beschikbare ruimte door 100% van de breedte uit te maken, zouden we dat als volgt schrijven:
Volgens deze logica zal elke browser met een kijkvenster van 380px of minder de breedte van het beeld instellen op 100% van het kijkvenster. Elke andere browser zorgt ervoor dat de mediaquery false retourneert en de browser wordt verplaatst naar de volgende waarde van het kenmerk sizes , in dit geval 80vw.
Over het algemeen voel ik me ongemakkelijk bij het gebruik van mediaquery's in HTML. Net zoals responsieve beeldgegevens thuishoren in HTML (niet JavaScript), behoren mediaquery's tot CSS (niet HTML). De optie is er echter voor u als u deze nodig hebt.
Responsieve image-best-practice (2016?)
Ik weet het niet van je, maar ik ben behoorlijk enthousiast over de mogelijkheden van srcset. Het is een eenvoudige oplossing voor een moeilijk probleem en lijkt alles te leveren wat we nodig hebben.
Maar, zoals bussen, wacht u 20 jaar op een officiële oplossing voor responsieve beelden, en dan komen er twee tegelijk aan. Naast het kenmerk srcset van het img- element hebben we ook het afbeeldingselement .
Het afbeeldingselement is een andere tijdelijke aanduiding, zij het een meer traditionele. Het is ontworpen om de video- en audio- elementen in HTML5 na te bootsen, dus de syntaxis is voor de meesten bekend. Het afbeeldingselement is bedoeld om te worden gebruikt wanneer u meer controle nodig hebt dan srcset kan bieden.
Helaas heeft het afbeeldingselement veel minder browserondersteuning dan srcset en het faalt niet altijd stil.
Het beeldelement gebruiken
Dit is ons originele afbeeldingselement:
Hier is onze afbeelding genest in een afbeeldingelement:
We kunnen ook een srcset opgeven voor een img- element in een afbeeldingselement :
Het bronelement gebruiken
Het afbeeldingselement komt pas tot leven als we het bronelement toevoegen:
Wanneer u selecteert welk bestand u wilt gebruiken, start de browser met het eerste bronelement en bladert door de elementen totdat het een element vindt waarvan het mediakenmerk de waarde true heeft en vervolgens de bronset van dat bronelement gebruikt.
We kunnen bijvoorbeeld verschillende afbeeldingen opgeven voor staande en liggende formaten:
We kunnen ook meerdere afbeeldingen specificeren met behulp van x-descriptor en w-descriptor:
Net als bij het gebruik van mediaquery's in het kenmerk sizes , zou ik de wijsheid in twijfel trekken van het besturen van afbeeldingsversies op basis van stijl, in markup in plaats van een stylesheet. De optie om het media- attribuut te gebruiken is er echter als u het nodig hebt.
Type gebruiken
Het beeldelement komt goed tot zijn recht als het wordt gebruikt om verschillende soorten afbeeldingen uit te wisselen.
Stel dat we een standaard PNG-bestand hebben, maar we willen een WebP-bestand, dat is meestal 26% kleiner - onthoud dat responsieve afbeeldingen over het leveren van de beste beeldkwaliteit, met het kleinste formaat, maar momenteel alleen worden ondersteund door Chrome, Opera en de Android-browser. We moeten het type -kenmerk gebruiken om te bepalen of WebP wordt ondersteund:
In dit geval zal de browser controleren of de WebP-afbeeldingsindeling wordt ondersteund. Als dat zo is, bepaalt het of het scherm voldoende pixeldichtheid heeft om de afbeelding retina-image.webp weer te geven . Als dit niet het geval is, wordt de afbeelding image.webp weergegeven . Als WebP niet wordt ondersteund, springt de browser rechtstreeks naar het img- element en verwerkt de srcset- en src- opties op de manier die we al kennen.
Het typekenmerk betekent dat we veel kleinere beeldformaten kunnen bieden waar dit wordt ondersteund, wat resulteert in een kleinere bestandsgrootte.
Bekende problemen
IE9 heeft een bekend probleem, die verhindert dat het beeldelement in stilte uitvalt. Om IE9 af te handelen, moet IE9 misleiden door te denken dat de bronelementen deel uitmaken van een video- element:
< !—[if IE 9]>< ![endif]—>
Het is een lelijke oplossing, maar beter dan helemaal geen oplossing. We kunnen alleen maar hopen dat de release van Windows 10 de ondergang van IE9 zal versnellen, omdat Edge het beeldelement nog niet ondersteunt, maar het niet op de juiste manier ondersteunt (door het te negeren).
Er zijn polyfills dat kan je helpen het beeldelement op IE te ondersteunen, maar mijn eigen voorkeur is om ze te vermijden. Ik wantrouw patchen problemen met JavaScript, het heeft invloed op de prestaties en leidt tot minder onderhoudbare code.
Om deze reden raad ik aan het afbeeldingselement voor nu te vermijden. Tenzij u een grootschalige e-commercesite draait, is het onwaarschijnlijk dat de extra besparing op downloadtijd die het WebP-formaat biedt, opweegt tegen het ongemak van het patchen van uw markup met script.
Zodra IE9 onder 1% daalt, wat op een bepaald punt in het volgende jaar zou moeten gebeuren, wordt het beeldelement levensvatbaar. Als u dit in 2016 leest, bent u waarschijnlijk goed om te gaan.
Responsieve afbeeldingen maken
In tegenstelling tot SVG worden bitmapafbeeldingen niet groter. Onze strategie om ze aan te pakken , of we nu gebruik maken van srcset of het beeldelement, is om een andere afbeelding te leveren op basis van de mogelijkheden van de browser. Om dat aan te kunnen, moeten we een verscheidenheid aan verschillende beeldformaten leveren.
De meeste beeldbewerkingstoepassingen hebben het proces voor het exporteren van meerdere versies van een enkele afbeelding geautomatiseerd. Het maakt niet uit welke toepassing u gebruikt, op voorwaarde dat u meerdere afbeeldingsformaten krijgt zonder dat u elke grootte handmatig hoeft te wijzigen en op te slaan.
Adobe Photoshop is de de facto bitmap-editor. Het is geen geweldige keuze voor ontwerpwerk, maar de workflow voor beeldverwerking is soepel en betrouwbaar. Het genereren van meerdere afbeeldingsresoluties in Photoshop is relatief eenvoudig:
Open de afbeelding waarvan u meerdere versies wilt genereren en plaats deze op een eigen laag.
Hernoem de laag als de naam van het bestand dat u wilt genereren (inclusief de extensie).
Selecteer File> Generate> Image Assets en een map met uw nieuwe afbeelding wordt naast uw PSD opgeslagen.
Hernoem de laag en specificeer elke afbeelding die u wilt genereren, voorafgegaan door de beoogde schaal. U hoeft stap 3 niet te herhalen, zodra u de laag hernoemt, worden de afbeeldingen automatisch gegenereerd.
Krediet voor het beeld gaat naarPhilip Collier.
Voor meer informatie over het genereren van afbeeldingen in Photoshop, kijk hier.
Op basis van deze afbeeldingen kunnen we de browser vijf verschillende opties aanbieden:
Conclusie
Het img- element heeft in 20 jaar een lange weg afgelegd. Of, om nauwkeuriger te zijn, het img- element was 18 jaar ontoereikend en sprintte vervolgens in de afgelopen twee jaar voor de lijn, tot het punt dat het nu relatief geavanceerd is.
Het belangrijkste is dat we tot de oplossing (en) zijn gekomen.
Van de twee beschikbare opties, srcset en picture, is de eerste verreweg het meest ondersteund. Als u 95% van de sites bouwt, is de beste ondersteuning en eenvoudige implementatie van het kenmerk srcset uw beste optie.
Als u een grote e-commercesite met duizenden productafbeeldingen gebruikt, is het extra werk om het WebP-formaat te bedienen misschien de moeite waard, vooral omdat de ondersteuning voor het beeldelement de komende jaren toeneemt.
De grootste zwakte in de huidige opties is dat browsers momenteel geen manier hebben om een afbeelding te selecteren op basis van hun verbindingssnelheid. We zijn genoodzaakt te vertrouwen dat meer capabele apparaten ook superieure verbindingen hebben.
Uiteindelijk kunnen we uiteindelijk de hoogst mogelijke afbeeldingen leveren, op de kleinste maat. Dat betekent een betere ervaring, in een kortere tijd, die alleen iets is om te omarmen.
