Das Web ist ein visuelles Medium. Die überwiegende Mehrheit dieser visuellen Landschaft ist dank Bilddateien. Während mit CSS und Inline-SVG viel erreicht werden kann, benötigen die meisten Sites noch Bilddateien.

Im Durchschnitt wurden Bilder berücksichtigt mehr als die Hälfte der Seitengröße im letzten Jahr und Jahr für Jahr Bildgrößen zu erhöhen; da war ein 21% Wachstum in Bildgröße im Jahr 2014 allein.

Gleichzeitig steigt die Anzahl und Diversität von Geräten, die auf das Internet zugreifen. Die Resolutionen variieren jetzt irgendwo zwischen 72ppi (abnehmend üblich) und über 600ppi.

Erstellen Sie ein Bild für den Bildschirm, die für jedes Gerät von ausreichender Qualität sein wird, ist einfach: Speichern Sie es bei 1000ppi und nennen Sie es einen Tag. Das resultierende Bild ist selbst auf den höchsten hochauflösenden Geräten scharf. Aber während Ihre Qualität hoch ist, wird auch Ihre Dateigröße. Mit Seitenladezeit a Schlüsselfaktor in UX Es obliegt uns, dafür zu sorgen, dass die Websites unseren Nutzern zeitnah zur Verfügung gestellt werden. Wenn Bilder von so hoher Qualität sind, dass sie ein Dutzend Sekunden für den Download von Breitbandverbindungen benötigen, ganz zu schweigen von mobilen Verbindungen, sind sie effektiv unbrauchbar.

Das Ziel responsiver Bilder besteht dann nicht darin, Bildschirmen mit höherer Qualität Bilder zu liefern, die sie anzeigen können (was wir leicht tun können), das Ziel ist es, Bilder mit der höchsten Qualität zu liefern, und nicht mehr.

Dieser Leitfaden soll Ihnen beibringen, was funktioniert, wo die Probleme und Fallstricke noch immer liegen und wie Sie heute in Webseiten responsive Bilder verwenden können.

Ich spüre die Notwendigkeit, das Bedürfnis nach Geschwindigkeit

Warum ist Geschwindigkeit wichtig? Sicherlich ist niemand mehr auf einer 3G-Verbindung? Niemand verwendet Einwahl. Wenn das Zielpublikum Ihres Kunden in Manhattan lebt, warum sollten Sie sich dann für das ländliche Lesotho interessieren? Tatsache ist, es ist ein Mythos, dass wir alle auf superschnellem Breitband sind, das uns von Unternehmen verkauft wird, die von dem Wunsch nach immer höheren Geschwindigkeiten profitieren.

Die meisten Menschen verbringen jeden Tag mindestens zwei Stunden mit einer schlechteren Verbindung. Ich finde mich oft am meisten Zeit beim Pendeln zu stöbern, wenn sogar eine zuverlässige 3G-Verbindung wie ein weit entfernter Traum klingt.

Im April Google angekündigt Diese Mobilitätsfreundlichkeit würde als Ranking-Faktor für Suchanfragen auf Geräten verwendet, die sie für "mobil" hält. Schon vorher Geschwindigkeit war ein Faktor im Seitenranking - beide explizit als Teil der Google-Berechnungen und implizit als beitragender Faktor für Ihre Absprungrate.

Auf zwei gleichrangigen Websites kann ein zusätzlicher 1-KB-Betrag von Google auf Platz 3, 4 oder 5 fallen. Es könnte Sie sogar vom 10. auf den 11. Platz bringen - also von Seite 1 auf 2 - mit allen damit verbundenen Auswirkungen auf den Umsatz Ihres Kunden.

Brauchst du das Bild wirklich?

Das am besten optimierte Bild ist überhaupt kein Bild. Wenn Sie fünf Bilder auf Ihrer Website haben und eine löschen, haben Sie sich 20% gespart, vielleicht noch wichtiger, Sie haben sich eine HTTP-Anfrage gesichert. Wenn wir alle Bilder von unseren Websites löschen würden, würden wir uns 100% und alle fünf HTTP-Anfragen sparen. Warum also nicht?

Wir löschen keine Bilder von unseren Websites, weil sie auf kurze Sicht effektiver kommunizieren als Text. Sie schaffen eine emotionale Verbindung, die Nutzer in Inhalte hineinzieht.

Wir wissen das Benutzer lesen keine Webseiten . Sehr wenige Menschen lesen eingehende Inhalte online. Bilder ermöglichen es uns, eine Marke in einem Bruchteil der Zeit, die der Text bewältigen kann, zu verbinden, zu kommunizieren und zu stärken.

Bilder können groß und schwer zu downloaden sein, aber wenn sie erst einmal im Browser gerendert wurden, sind sie weitaus effizienter als Text, um das Engagement der Nutzer zu stärken und eine Markenbotschaft zu stärken.

Responsive Bilder helfen uns sicherzustellen, dass die Bilder der emotionalen Verbindung nicht verloren gehen, wenn der ungeduldige Benutzer den Zurück-Knopf drückt.

Wie wäre es mit SVG?

SVG (Scaleable Vector Graphics) ist eine der bahnbrechenden Technologien des Internets. Es ist der Zeit so weit voraus, dass die meisten Designer ihr wahres Potenzial noch nicht erkannt haben.

SVG - wie der Name schon sagt - ist vektorbasiert. Dies bedeutet, dass SVG-Grafiken aus Punkten, Winkeln und Entfernungen erstellt werden. SVG ist auch - wie der Name sagt - skalierbar, was bedeutet, dass es genauso gut auf einem 5k iMac oder einem Android-Smartphone angezeigt wird, ohne Qualitätsverlust und keine Änderung der Dateigröße.

Wenn Sie eine flache Abbildung, ein Symbol, ein Logo, fast alles haben, was als SVG angezeigt werden kann, dann ist SVG der richtige Weg.

Die meisten Bilder im Web sind Bitmaps. Die Funktionsweise einer Bitmap besteht im Allgemeinen darin, jedes Pixel einzeln zu beschreiben, seine Farbe (in RGB - Rot-, Grün- und Blauwerte) und in einigen Fällen seine Transparenz. Wenn Sie ein Bild haben, das 100px mal 100px misst, dann haben Sie ein Bild mit 10.000 Pixeln; Wenn jedes Pixel 4 Werte hat, um es zu beschreiben, dann hat das Bild 40.000 Datenbits, die damit verknüpft sind. Klingt nach viel, nicht wahr? Manchmal ist das weniger als eine Vektorgrafik.

Betrachten Sie ein 1px mal 1px Bild; Das würde 4 Bit Daten erfordern, um als Bitmap (Rot-, Grün-, Blau- und Alpha-Werte) aufzuzeichnen. Betrachten Sie nun das gleiche quadratische Pixel, das als Vektor aufgezeichnet wurde; das würde zusätzlich zu den RGBA-Werten die x, y, Breite und Höhe des Rechtecks ​​erfordern.

Das sind grobe Beispiele, aber sie sind genau. Oftmals überschreitet eine Vektorversion eines Bildes - wenn wir überhaupt eines verfügbar haben - die Dateigröße der entsprechenden Bitmap, und dann ist Bitmap die einzig sinnvolle Wahl.

(Mis) mit JavaScript

Wie die meisten Probleme im Leben (wenn Ihr Leben online ist) können reaktionsfähige Bilder mit JavaScript gelöst werden. In der Tat war JavaScript für eine Reihe von Jahren der einzige Weg, um das Problem zu lösen. JavaScript kann die Fähigkeiten eines Benutzeragenten testen, bestimmen, um welche Art von Browser es sich handelt, und ein Standard-HTML-Bild-Tag schreiben, das das entsprechende Bild enthält.

Webdesigner, die JavaScript ablehnen, tun dies normalerweise, weil Manche Leute schalten es aus . Dies ist jedoch nicht mehr der Fall, besonders im mobilen Web, aber es gibt einige anhaltende Probleme: Ein Bild mit JavaScript zu schreiben bedeutet, dass das Bild nicht von Suchmaschinen-Bots analysiert wird und erst nach dem Skript wie zum Beispiel laufen.

Das größte Problem bei der Verwendung von JavaScript ist, dass es einen Zweckmissbrauch von JavaScript ist. HTML enthält Daten, CSS behandelt die Präsentation, JavaScript behandelt die Funktionalität. Wenn wir uns von diesen strukturierten Rollen lösen, treten Probleme auf, die Hacks erfordern, um sie zu beheben. Bilder sind Daten und sollten daher von HTML verarbeitet werden.

Das Problem mit Browsern

Seit der Erfindung von RWD waren Bilder der größte Stolperstein. Aber jetzt beginnen wir Wege zu finden, um die verschiedenen Probleme zu lösen. Techniken, die kämpferisch und erfolgreich genug sind, um als Best-Practice angesehen zu werden. Dedizierte Entwickler haben ihre Zeit aufgegeben, um auf der WC3 für offizielle Lösungen zu werben, und jetzt sind zum ersten Mal reaktionsfähige Bilder praktisch.

Der Schlüssel zu responsiven Bildern besteht darin, dass sie in vollem Bewusstsein für die Fehler des Webs entwickelt wurden. Es wurde sorgfältig darauf geachtet, dass reaktionsfähige Bildlösungen vorhandene Browser nicht beschädigen, sodass selbst in Browsern, die keine reaktionsfähigen Bilder unterstützen, der Code automatisch fehlschlägt und nicht reagiert. Daher werden Standardbilder angezeigt.

In diesem Artikel werden zwei offizielle reaktionsfähige Bild-HTML-Elemente betrachtet: srcset und picture.

Derzeit unterstützen Edge, Safari und iOS Safari nur eine Teilmenge der srcset- Spezifikation. Firefox, Chrome, Opera, Android Browser und die kommenden Versionen von Safari und iOS Safari unterstützen dies vollständig. (Wir werden die Unterschiede unten diskutieren.)

Derzeit wird das Bildelement von Firefox, Chrome, Opera und Android Browser vollständig unterstützt. Edge, Safari und iOS Safari unterstützen dies nicht, und sie haben keinen Zeitplan für die Implementierung angekündigt.

Sogar unter Browsern, die den neuen Code unterstützen, gibt es Inkonsistenzen, da verschiedene Browserhersteller die W3C-Spezifikationen auf unterschiedliche Weise interpretieren. Wenn Sie beispielsweise eine Änderung des Bilds von klein nach groß anhand der Größe des Darstellungsbereichs festlegen, wechseln einige Browser zum großen Bild, wenn das Ansichtsfenster 1 x größer ist als die bevorzugte Größe des kleinen Bildes, andere nur im Ansichtsfenster zum großen Bild begünstigt durch das große Bild ist vollständig abgestimmt.

Zusammenfassend lässt sich sagen, dass Browser in zwei Bereiche unterteilt sind: diejenigen, die Bilder mit höherer Qualität bevorzugen, und solche, die möglichst kleine Downloads bevorzugen. Browser-Hersteller tun dies immer noch, schließlich wird sich jemands Implementierung als am populärsten erweisen - persönlich hoffe ich, dass es letzteres ist, denn wie oben erwähnt, ist die Leistung für die Benutzererfahrung entscheidend.

Im Moment ist die beste Option für Webdesigner, sich an die Spezifikation zu halten und nicht den Browser zu raten. Schließlich ist die Standarderfahrung im Browser (höhere Qualität oder schnellere Downloads) Teil dessen, wofür ein Benutzer einen Standardbrowser auswählt. Wenn der Benutzer also die verschiedenen Ansätze kennt, dann ist die Browserpräferenz wahrscheinlich auch die Benutzerpräferenz .

Responsive Image Best-Practice (2015)

In der Geschichte des Webs haben wir ein Element verwendet, um ein Bild, das img- Element, anzugeben. In HTML5 hat das img- Element eine subtile Verschiebung seiner Rolle erfahren, die reaktionsfähige Bilder ermöglichen soll: Das img- Element repräsentiert kein Bild mehr, es ist jetzt ein Platzhalter für ein Bild.

Diese Unterscheidung ist wichtig, denn während ein img- Element zuvor einen einzelnen Satz von Bilddaten enthielt - sei es diese Bitmap oder dieser Vektor -, kann ein Bild nun mehrere Datensätze enthalten.

Das img- Element (um alle Nicht-Coder zu rekapitulieren) sieht folgendermaßen aus:

Die responsive Image-Version des img- Elements sieht folgendermaßen aus:

Kaum eine Veränderung überhaupt. Wenn Sie diesen Code betrachten, bemerken Sie eine wichtige Sache: Der Code ist abwärtskompatibel. Wenn ein Browser das Attribut srcset nicht versteht, wird er ignoriert und das Bild gemäß der ursprünglichen Spezifikation von 1993 gerendert .

Das bedeutet, dass wir nun in unserem Markup reaktionsfähige Bilder verwenden können, ohne dass eine Feature-Erkennung erforderlich ist.

Im neuen responsiven img- Element wird src hauptsächlich als Standardbild und für Browser verwendet, die srcset nicht erkennen , während srcset alle verfügbaren Bilder im Hochauflösungsformat für diesen Platzhalter enthält.

Beim Rendern des img- Elements bestimmt der Browser selbst, welche Bilddatei am besten geeignet ist.

Verwenden von srcset

Da wir jetzt wissen, dass srcset in Browsern, die es nicht unterstützen, automatisch stört , können wir ein zusätzliches Bild hinzufügen:

In diesem Fall zeigt jeder Browser, der srcset unterstützt, image-b.jpg an und jeder Browser, der srcset nicht unterstützt, zeigt image-a.jpg an.

Es ist wichtig zu beachten, dass der Browser nur das Bild herunterladen wird, das er anzeigen möchte, es lädt nicht beide Bilder und wählt dann eines aus.

Leider bringt uns das nicht sehr weit, denn es gibt keine praktische Anwendung, um Bilder auf srcset- Unterstützung allein zu übertragen, wenn wir die srcset- Unterstützung nicht demonstrieren.

Die Lösung besteht darin, dem Browser zusätzliche Informationen darüber zu geben, welches Bild er auswählen soll. Um dies zu tun, müssen wir Informationen über den verfügbaren Platz oder die Pixeldichte liefern.

Verwenden von X-Deskriptor

Der x-Deskriptor teilt einem Browser mit, wie dicht die Pixel in einem Bild sind.

Wenn Sie z. B. ein Netzhautbild mit der doppelten Anzahl von Pixeln als Standardbild bereitstellen möchten, geben Sie das Netzhautbild im srcset gefolgt von einem Leerzeichen und dann dem Schlüsselwort "2x" an.

Wir haben unser Bild:

an image

Um eine Retina-Option für den Browser hinzuzufügen, fügen wir den folgenden srcset hinzu:

In diesem Fall gibt es drei mögliche Ergebnisse:

  1. Wenn der Browser srcset nicht unterstützt, verwendet er die im src- Attribut angegebene Bilddatei.
  2. Wenn der Browser srcset unterstützt und über einen Bildschirm mit doppelter Auflösung verfügt, wird das im Attribut srcset angegebene Bild verwendet.
  3. Wenn der Browser srcset unterstützt, aber keinen Bildschirm mit hoher Auflösung hat, verwendet er das im Attribut src angegebene Bild. Wenn im Attribut srcset kein Bild "1x" angegeben ist, wird das src- Attribut als Bild angenommen Möglichkeit).

Browser-Unterstützung ist gut und verbessert sich schnell. Mit einer Eigenschaft haben wir das Rätsel der responsiven Bilder gelöst, yay us!

Eine letzte Bemerkung zum x-Deskriptor: Die Auswahl des zu ladenden Bildes basiert auf der Pixeldichte. Wenn also ein Benutzer seinen Browser auf 200% vergrößert (die Bildgröße halbiert und damit die Pixeldichte verdoppelt), wird 2x angezeigt Bild wird geladen. Dies kann sich nachteilig auf die Barrierefreiheit auswirken - wir möchten sicherlich nicht, dass Websites für Sehbehinderte langsamer geladen werden, einfach weil sie ihren Browser zoomen.

W-Deskriptor verwenden

Der w-Deskriptor ist etwas weiter fortgeschritten als der x-Deskriptor. Der w-Deskriptor arbeitet, indem er dem Browser sagt, wie viele tatsächliche Pixel auf der x-Achse (der Breite) einer bestimmten Bildoption existieren.

Edge, Safari und iOS Safari unterstützen w-Deskriptor zum Zeitpunkt des Schreibens nicht, daher ist seine Nützlichkeit etwas reduziert.

Kehren wir zu unserem ursprünglichen Bild zurück:

an image

Wenn dieses Bild nativ 1600 Pixel breit ist und wir ein Retina-Bild hinzufügen möchten, wie wir es mit dem obigen x-Deskriptor getan haben, würden wir ein Bild im srcset- Attribut angeben , das 3200 Pixel breit ist:

Es gibt ein großes Problem mit dem w-Deskriptor: Obwohl das src- Attribut beim Angeben von Bildern mit dem x-Deskriptor als Standard behandelt wird , wird es von Browsern, die srcset unterstützen, vollständig ignoriert, wenn Sie den w-Deskriptor verwenden. Bei der Verwendung des w-Deskriptors müssen wir den Standard explizit angeben, indem wir eine zweite srcset- Image-Option mit einem eigenen w-Deskriptor hinzufügen und sie durch ein Komma trennen:

Das führt uns ordentlich auf ...

Verwenden mehrerer Bilder

In der Lage zu sein, eine hochauflösende Bildoption für den Browser direkt in unserem HTML-Code anzugeben, ist ausgesprochen cool, aber wie Sie wahrscheinlich erraten haben, wird es noch cooler, wenn wir mehrere Bilder angeben.

Das Ziel responsiver Bilder ist es, das Bild mit der besten Qualität zu liefern, das von dem zugreifenden Gerät verwendet werden kann, aber nicht mehr. Es genügt also nicht, ein Netzhautbild zu liefern, wir müssen beispielsweise Bilder mit 1x, 1.5x, 2x, 2.5x und 3x liefern.

Noch einmal, hier ist unser Originalbild-Markup:

an image

Hier ist es mit einem Netzhautbild als Option für den Browser geliefert:

Hier ist es, diesmal mit zusätzlichen Optionen im srcset, getrennt durch Kommas:

Da Schlüsselwörter für verschiedene Personen unterschiedliche Bedeutungen haben, empfehle ich es, meine Bilder entsprechend dem x-Deskriptor zu benennen, zu dem sie gehören, sowohl als persönliche Gedächtnisstütze als auch um sicherzustellen, dass die verschiedenen Größen für andere Teammitglieder klar sind:

Denken Sie daran, dass wir dem Browser nicht mitteilen, welches Bild angezeigt werden soll. Wir teilen ihm die verfügbaren Optionen mit und ermöglichen ihm, selbst auszuwählen. Der Browser wird nur eines dieser Bilder herunterladen.

Ein Fehler mit mehreren Bildern: Geben Sie niemals zwei Bilder im Attribut srcset mit einem passenden x-Deskriptor und w-Deskriptor an, zum Beispiel:

Es wäre schlecht ...

Größen verwenden

Das Attribut sizes ist eine besonders interessante Ergänzung zur Spezifikation, da das Attribut sizes seine Werte relativ zum Ansichtsfenster und nicht zum Bild annimmt.

Mit dem Wert vw (Ansichtsfensterbreite) geben wir den Bildbereich relativ zur Browserbreite an. Denken Sie daran, dass das img- Element jetzt nur ein Platzhalter ist. Daher geben wir nicht die tatsächliche Größe des Bilds an, sondern geben an Größe des Platzhalters, der das Bild enthält.

100vw entspricht 100% der Breite des Darstellungsbereichs, 50vw entspricht 50% der Breite des Darstellungsbereichs, 25vw entspricht 25% der Breite des Darstellungsbereichs usw.

Wenn wir die Img- Breite auf die Hälfte der Browserbreite einstellen wollten, würden wir verwenden:

Dies ist nicht besonders nützlich, bis wir es mit Medienabfragen kombinieren ...

Medienabfragen verwenden

Das Größenattribut wird viel leistungsfähiger, wenn wir es mit Medienabfragen kombinieren. Wir können mehrere Ansichtsfensterbreiten mit Kommas trennen und den Browser über eine Medienabfrage im CSS-Stil informieren.

Stellen Sie sich zum Beispiel vor, dass ein Bild 80% der Breite unseres Ansichtsfensters auf der Mehrheit der Geräte ausmacht, aber auf kleinen Geräten (wie Telefonen) mit einer Breite von 380 Pixel oder weniger, möchten wir das Beste aus dem verfügbaren Platz, indem wir 100% der Breite ausmachen, schreiben wir das so:

Gemäß dieser Logik wird jeder Browser mit einem Darstellungsbereich von 380 px oder weniger die Breite des Bilds auf 100% des Ansichtsfensters festlegen. Jeder andere Browser führt dazu, dass die Medienabfrage false zurückgibt, und der Browser wird zum nächsten Wert des Attributs sizes wechseln, in diesem Fall 80vw.

In der Regel fühle ich mich unbehaglich bei der Verwendung von Medienabfragen in HTML. So wie reaktionsfähige Bilddaten in HTML (nicht JavaScript) gehören, gehören Medienabfragen in CSS (nicht HTML). Die Option ist jedoch für Sie da, wenn Sie sie brauchen.

Responsive Image Best-Practice (2016?)

Ich weiß nicht wie es euch geht, aber ich bin ziemlich begeistert von den Möglichkeiten von srcset. Es ist eine einfache Lösung für ein schwieriges Problem und scheint alles zu liefern, was wir brauchen.

Aber wie bei Bussen warten Sie 20 Jahre auf eine offizielle Lösung für reaktionsschnelle Bilder, und dann tauchen zwei auf einmal auf. Neben dem srcset- Attribut des img- Elements haben wir auch das Bildelement.

Das Bildelement ist ein weiterer Platzhalter, wenn auch ein traditionellerer. Es wurde entwickelt, um die Video- und Audioelemente in HTML5 nachzuahmen, so dass seine Syntax den meisten vertraut ist. Das Bildelement soll verwendet werden, wenn Sie mehr Kontrolle benötigen, als srcset bereitstellen kann.

Leider hat das Bildelement weit weniger Browserunterstützung als srcset und es schlägt nicht immer automatisch fehl.

Verwenden des Bildelements

Hier ist unser originelles Bildelement:

an image

Hier ist unser Bild in einem Bildelement verschachtelt:

an image

Wir können auch ein srcset für ein img- Element innerhalb eines Bildelements angeben:

Verwenden des Quellelements

Das Bildelement wird erst dann lebendig, wenn wir das Quellelement hinzufügen:

an image

Wenn Sie die zu verwendende Datei auswählen, beginnt der Browser mit dem ersten Quellelement und durchläuft die Elemente, bis eine Datei gefunden wird, deren Medienattribut in true aufgelöst wird. Anschließend wird das srcset dieses Quellelements verwendet.

Zum Beispiel könnten wir verschiedene Bilder für Hoch- und Querformate angeben:

an image

Wir können auch mehrere Bilder mit x-Deskriptor und w-Deskriptor angeben :

an image

Wie bei der Verwendung von Medienabfragen im Größenattribut stelle ich die Weisheit der Kontrolle von Bildversionen auf der Grundlage von Stil in Markup anstelle von Stylesheets in Frage. Die Option zur Verwendung des Medienattributs ist jedoch vorhanden, wenn Sie es benötigen.

Typ verwenden

Das Bildelement kommt besonders gut zum Einsatz, wenn verschiedene Bildtypen ausgetauscht werden.

Stellen Sie sich vor, wir haben eine PNG-Standarddatei, aber wir möchten eine verwenden WebP-Datei, Das ist in der Regel 26% kleiner - denken Sie daran, dass bei Responsive Images die beste Bildqualität bei der kleinsten Größe erzielt wird, aber derzeit nur von Chrome, Opera und dem Android-Browser unterstützt wird. Wir müssen das type- Attribut verwenden, um festzustellen, ob WebP unterstützt wird:

In diesem Fall prüft der Browser, ob das WebP-Bildformat unterstützt wird. Wenn dies der Fall ist, wird festgestellt, ob der Bildschirm über genügend Pixeldichte verfügt, um das Bild retina-image.webp anzuzeigen, andernfalls wird das Bild image.webp angezeigt . Wenn WebP nicht unterstützt wird, springt der Browser direkt zum img- Element und durchläuft die srcset- und src- Optionen auf die Weise, mit der wir bereits vertraut sind.

Das Attribut type bedeutet, dass wir bei der Unterstützung viel kleinere Bildformate bereitstellen können, was zu einer kleineren Dateigröße führt.

Bekannte Probleme

IE9 hat ein bekanntes Problem, Dies verhindert, dass das Bildelement unbemerkt abstürzt. Um mit IE9 umgehen zu können, müssen Sie IE9 dahingehend täuschen, dass die Quellelemente Teil eines Videoelements sind :

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

Es ist eine hässliche Lösung, aber besser als gar keine Lösung. Wir können nur hoffen, dass die Veröffentlichung von Windows 10 den Untergang von IE9 beschleunigen wird, denn während Edge das Bildelement noch nicht unterstützt, unterstützt es es nicht auf die richtige Weise (indem es es ignoriert).

Es gibt Polyfüllungen Das kann Ihnen helfen, das Bildelement im IE zu unterstützen, aber ich möchte sie lieber vermeiden. Ich misstraue Patching-Problemen mit JavaScript, beeinträchtigt die Leistung und führt zu weniger wartungsfähigem Code.

Aus diesem Grund empfehle ich, das Bildelement vorerst zu vermeiden. Sofern Sie nicht eine große E-Commerce-Website betreiben, wird die zusätzliche Einsparung beim Herunterladen, die das WebP-Format bietet, kaum die Unannehmlichkeit überwiegen, dass Sie Ihr Markup mit einem Skript versehen.

Sobald IE9 unter 1% fällt, was irgendwann im nächsten Jahr passieren sollte, wird das Bildelement lebensfähig. Wenn Sie dies 2016 lesen, sind Sie wahrscheinlich gut zu gehen.

Responsive Bilder erstellen

Im Gegensatz zu SVG werden Bitmap-Bilder nicht vergrößert. Unsere Strategie für den Umgang mit ihnen, egal ob wir srcset oder das Bildelement verwenden, besteht darin, basierend auf den Fähigkeiten des Browsers ein anderes Bild bereitzustellen . Um das zu bewältigen, müssen wir eine Vielzahl unterschiedlicher Bildgrößen liefern.

Die meisten Bildbearbeitungsanwendungen haben den Export mehrerer Versionen eines einzelnen Bildes automatisiert. Es spielt keine Rolle, welche Anwendung Sie verwenden, vorausgesetzt, Sie erhalten mehrere Bildgrößen, ohne die Größe manuell ändern und speichern zu müssen.

Adobe Photoshop ist der De-facto-Bitmap-Editor. Es ist keine gute Wahl für Design-Arbeit, aber seine Bildverarbeitung Workflow ist reibungslos und zuverlässig. Das Generieren mehrerer Bildauflösungen in Photoshop ist relativ einfach:

  1. Öffnen Sie das Bild, für das Sie mehrere Versionen erstellen möchten, und platzieren Sie es auf einer eigenen Ebene.
    Schritt 1

  2. Benennen Sie den Layer als Namen der Datei um, die Sie generieren möchten (einschließlich der Erweiterung).
    Schritt 2

  3. Wählen Sie "Datei"> "Generieren"> "Bild-Assets" und ein Ordner mit Ihrem neuen Bild wird zusammen mit Ihrer PSD gespeichert.
    Schritt 3

  4. Benennen Sie die Ebene um, indem Sie jedes Bild angeben, das Sie mit der gewünschten Skalierung versehen möchten. Sie müssen Schritt 3 nicht wiederholen, sobald Sie die Ebene umbenannt haben, werden die Bilder automatisch generiert.
    Schritt 4

Kredit für das Bild geht nach Philip Collier .

Weitere Informationen zum Erstellen von Bildern in Photoshop siehe hier.

Basierend auf diesen Bildern können wir dem Browser fünf verschiedene Optionen anbieten:

Fazit

Das IMG- Element hat in 20 Jahren einen langen Weg zurückgelegt. Oder, um genauer zu sein, das img- Element war 18 Jahre lang nicht ausreichend, sprintete dann in den letzten zwei Jahren für die Linie, bis zu dem Punkt, dass es jetzt relativ hoch entwickelt ist.

Das Wichtigste ist, dass wir die Lösung (en) gefunden haben.

Von den beiden verfügbaren Optionen, srcset und picture, wird ersteres bei weitem am meisten unterstützt. Wenn Sie 95% der Websites erstellen , ist die bessere Unterstützung und einfachere Implementierung des srcset- Attributs die beste Option.

Wenn Sie eine große E-Commerce-Site mit Tausenden von Produktabbildungen betreiben, kann sich die zusätzliche Arbeit für das WebP-Format lohnen, zumal die Unterstützung für das Bildelement in den nächsten Jahren zunimmt.

Die größte Schwachstelle in den aktuellen Optionen besteht darin, dass Browser derzeit keine Möglichkeit haben, ein Bild basierend auf ihrer Verbindungsgeschwindigkeit auszuwählen. Wir müssen darauf vertrauen, dass leistungsfähigere Geräte auch über bessere Verbindungen verfügen.

Letztendlich können wir schließlich Bilder höchster Qualität praktisch in der kleinsten Größe liefern. Das bedeutet eine bessere Erfahrung in einer kürzeren Zeit, die nur etwas sein kann, das man annehmen kann.

Ausgewählte Bild verwendet, Berg Bild und Gerätebild über Shutterstock.