Seite 2: Umgang mit Bildern

Inhaltsverzeichnis

Große Bilder für kleine Geräte

Laut aktuellen Statistiken, besteht bei einer durchschnittlichen Webseite der größte geladene Anteil mit 62 Prozent aus Bildern. Grund genug, um ein absoluter Performancekiller bei RWD zu sein. Wie optimal in der responsiven Welt mit Bildern umzugehen ist, bleibt heute noch ein ungelöstes Rätsel. Doch eines ist jedem klar: Ein Bild mit hoher Auflösung auf einem kleinen Gerät mit langsamer Verbindung anzuzeigen, ist weder für den Besucher noch für die Bandbreite eine Lösung.

Im Idealfall sollte je nach Auflösung ein optimiertes Bild dargestellt werden. Das einzige Problem dabei ist, dass es für den Server keinen Unterschied macht, wer das Bild gerade anfordert. Selbst eine Abfrage der User Agents, sprich des Browsers, der sich anmeldet, bleibt eine ungünstige Lösung – vor allem da es im Moment viele unterschiedliche gibt und in Zukunft noch viele weitere hinzukommen. Außerdem sagt ein User Agent nur bedingt etwas über die Größe des Bildschirms und dessen Auflösung aus.

Die Auflösung lässt sich nicht auf Serverseite überprüfen, da sie erst clientseitig, also im Browser, zu ermitteln ist. Als Lösung bietet sich beispielsweise an, ein Cookie mit der Auflösung des Geräts zu setzen, bevor das erste Bild der Webseite geladen wird. Der nötige Wert lässt sich anschließend bei der Anfrage für das Bild auf dem Server ermitteln. Theoretisch funktioniert dieses Vorgehen ausgesprochen gut, denn das Setzen eines Cookies auf dem Client erfordert kein komplettes Laden der Seite.

In so gut wie jeder Technik gibt es die Möglichkeit, auf bestimmte Dateien wie Bilder zu horchen und die Anfragen so zu verarbeiten, dass sich Bilder dynamisch zuschneiden lassen. Ein Ablauf kann wie folgt beschrieben werden:

• Ein kleiner Code-Schnipsel, der ein Cookie mit Informationen über die Auflösung setzt, wird beim Laden der Webseite im Head platziert.
• Der Browser sendet bereits bei der ersten Anfrage eines Bildes den Cookie-Header mit. (Der Bereich im Head wird vor dem Body ausgeführt.)
• Der Server routet die Bild-Anfragen (etwa über die .htaccess-Datei) an eine bestimmte Datei oder Komponente, die das Cookie ausliest, das Bild verkleinert und anschließend zurückliefert.
• Die Komponente kümmert sich zusätzlich um das Ablegen des zurechtgeschnittenen Bildes im Cache (/image-cache/480/image.jpg), sodass es bei der nächsten Anfrage sofort zur Verfügung steht.

Diese Variante hat den Vorteil, dass am bestehenden HTML-Markup nichts zu ändern ist, allerdings kann sie sehr performanceintensiv sein und sie ist vom Ansatz her nicht ganz responsiv.

Die Responsive Images Community Group verfolgt mit dem Ansatz, verschiedene Bilder für verschiedene Auflösungen bereitzustellen, ein weiteres interessantes Konzept. Mit dem neuen picture-Element lässt sich ähnlich wie im HTML5-Video-Element die Ressource direkt in der HTML-Datei angeben:

<picture>
    <source  media="(min-width: 1024p)" src="image-hd.jpg">
    <source  media="(min-width: 480px)" src="image.jpg">
    <source  src="image-small.jpg">
    <img  src="image-small.jpg" alt="">
    <p>Ein responsives Bild!</p>
</picture>

Apples Vorschlag an das W3C basiert auf Attributen, mit denen Entwickler Bilder steuern können. Wenn auch auf den ersten Blick mit etwas unverständlichen Angaben, besteht das srcset-Attribut aus dem Namen des Bildes, der Pixeldichte und des maximalen Viewports:

<img  alt="Ein responsives Bild!"
  src="image.jpg"
  srcset="image-hd.jpg  2x, image-phone.jpg 100w,
  image-phone-HD.jpeg 100w 2x">

Die im Attribut verwendeten Regeln können wie folgt verstanden werden:

• image.jpg: Standartbild
• image-hd.jpg: für Geräte mit einer Pixeldichte (pixel ratio) größer als 2
• image-phone.jpg: für Geräte mit einem maximalen Viewport von 100w (w steht hier für width)
• image-phone-hd.jpg: für Geräte mit einem maximalen Viewport von 100w und einer Pixeldichte von höher als 2

Eine reine CSS-Lösung liegt als W3C Editor's Draft ebenfalls vor und wird bereits von Safari 6+ und Chrome 21+ unterstützt:

background-image: image-set( "image.jpg" 1x,
  "image-hd.jpg" 2x,
  "image-druck.jpg" 600dpi );

Letztendlich sollen die neuen Features voraussichtlich mit HTML 5.1 verfügbar sein, bis dahin ist eine JavaScript-Lösung höchstwahrscheinlich das Beste für einen produktiven Einsatz. Dafür bringt zum Beispiel PictureFill eine Reihe von mit data-Attributen versehenen Elementen ins Spiel, die, wenn auch nur mit JavaScript, zum selben Ergebnis führen, sprich anhand der Auflösung ein geeignetes Bild laden:

<span data-picture data-alt="Ein responsives Bild!">
    <span data-src="image-klein.jpg"></span>
    <span data-src="image-medium.jpg" data-media="(min-width: 400px)">
    </span>
    <span data-src="image-large.jpg"  data-media="(min-width: 800px)">
    </span>
 
    <!-- Fallback content für non-JS Browsers. -->
    <noscript>
        <img src="image.jpg" alt="Ein normales Bild!">
    </noscript>
</span>

Von einer anderen Sichtweise betrachtet, könnte vielleicht ein anderer, nicht von der Webseite abhängiger Weg zur Lösung dieses Dilemmas führen. Der Browser rendert ein klassisches Bild (zum Beispiel im JPG-Format) nach dem Top-to-bottom-Verfahren, das heißt, er baut es von oben nach unten auf. Einen anderen Ansatz verfolgen sogenannte Progressive JPGs: Sie werden erst in einer kleinen Auflösung geladen und dann (progressiv) immer schärfer. Die Bandbreite profitiert von der Idee nicht, es kann aber die Benutzerfreundlichkeit erhöhen, da sofort – wenn auch unscharf – ein Bild zu sehen ist.