Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Der neue Standard für responsive Bilder

picture und srcset

Der neue Standard für responsive Bilder

Bilder machen den Großteil des Übertragungsvolumens einer Webseite aus. Es ist deshalb eine große Herausforderung, eine Lösung für die responsive Einbindung von Bildern zu finden und damit die Ladezeiten für mobile Endgeräte zu verbessern. Die Lösung bilden das neue srcset-Attribut und das neue picture-Element.

Moderne Webseiten sollen sich nicht nur an beliebige Endgeräte und deren Bildschirme anpassen, sie sollen dabei auch performant sein. Zudem werden moderne Webseiten immer bilderlastiger, gerne auch mit Slideshows, die fünf und mehr großformatige Bilder animiert präsentieren. Oft werden auch sehr große Headerbilder genutzt.

Spätestens auf Smartphones hat der Nutzer allerdings keinen Gewinn durch großformatige Bilder. Sie kosten viel Übertragungszeit und vielleicht auch teures Datenvolumen. Ausserdem gehen auf kleinen Bildschirmen bei manchen Motiven die wichtigen Details verloren. Deshalb fanden sich vor wenigen Jahren ein paar Webentwickler zusammen, um eine Spezifikation für responsive Bilder zu erarbeiten. Die Ergebnisse der langen und intensiv geführten Debatte werden jetzt nach und nach in die Browser eingearbeitet. Mehr Details zu den Hintergründen hat Christoph Zillgens in seinem Artikel im Adventskalender 2012 geliefert.

Zwei Einsatzszenarien

Im Grundsatz gibt es zwei Einsatzszenarien für responsive Bilder:

  1. Ein Bild soll mit den für die Bildschirmauflösung passenden Abmessungen ausgeliefert werden. Für kleinere Bildschirme würden dadurch Bilder mit geringerer Dateigröße geladen werden.
  2. Zusätzlich zum ersten Szenario könnte es notwendig sein, das Bild neu zu beschneiden, damit auf kleineren Auflösungen nicht der spärlich vorhandene Platz mit unnötigen Bildbereichen verschwendet wird.

Für das erste Szenario wurde ein neues Attribut eingeführt: srcset. Für das zweite Szenario wurde das neue picture-Element eingeführt, das mit dem vorgenannten Attribut kombiniert werden kann.

Kleinere Bilder für kleinere Bildschirme

Wird ein großes Bild mittels CSS auf kleinen Bildschirmen herunterskaliert, verliert es nichts von der eigenen Dateigröße. Stattdessen ist der Browser nur etwas stärker gefordert, weil er eine größere Datenmenge kleiner rechnen muss. Ein Smartphone würde das Bild zwar passend anzeigen, jedoch ein viel zu großes Bild herunterladen und so wertvolle Zeit und Transfervolumen vergeuden. Wir benötigen also einen Mechanismus, der ein Bild in Abhängigkeit der aktuellen Bildschirmauflösung ausliefert. Bislang ging dies nur mit JavaScript. Mit den neuen Attributen srcset und sizes bekommen Webworker nun eine Technik an die Hand, die dies mittels HTML den Browser machen lässt.

Der Browser weiß zu jeder Zeit, welche Bildschirmauflösung mein Endgerät hat und wie groß der Viewport des Browsers ist. Im srcset-Attribut geben wir ihm den Hinweis, welche Breite ein Bild hat. So kann der Browser das Bild passend zur Umgebung laden.

  1. <img
  2.   src="http://placehold.it/400x200&amp;text=Fallback"
  3.   srcset="http://placehold.it/320x160/ddd 320w,
  4.    http://placehold.it/480x240/ccc 480w,
  5.    http://placehold.it/768x384/444 768w,
  6.    http://placehold.it/1024x512/a20000 1024w,
  7.    http://placehold.it/1280x640/fd8700 1280w"
  8.   alt="Super tolle Bildbeschreibung">

Das neue Attribut kann im img-Element eingesetzt werden und ergänzt die bisherige Quellenangabe. Browser, die das neue Attribut verstehen, ignorieren die Quelle im src-Attribut, alle anderen lesen sie wie immer aus. Das ist eingebaute Graceful Degredation.

Im srcset-Attribut notiert der Webworker eine kommaseparierte Liste mehrerer Bilderquellen. Jeder Listeneintrag enthält erst die Quelle und danach die Breite des Bildes in Pixeln (320w). Der Browser wählt anhand dieser Breitenangabe das Bild aus, das ihm am Passendsten für den zur Verfügung stehenden Raum erscheint. Der Webworker kann da leider nicht eingreifen. Das Attribut ist auch dafür geeignet, hochauflösende Bilder zur Verfügung zu stellen:

  1. <img src="bild.jpg" srcset="bild-x2.jpg 2x, bild-x3.jpg 3x">

In diesem Fall werden Alternativen für Retina-Bildschirme (tolles-bild-x2.jpg 2x) und noch höher auflösende Monitore (tolles-bild-x3.jpg 3x) gegeben. Der Browser nimmt sich auch hier das Passende. So kann der Webworker endlich nicht nur Schmuckbilder als background-image mittels CSS, sondern auch im HTML eingebundene redaktionelle Bilder für hochauflösende Bildschirme austauschen.

Mit diesem neuen Attribut ist die wichtigste Arbeit schon getan. Es bleibt dabei für Hersteller von Content-Management-Systemen die Herausforderung, nicht nur mehrere Bilder an einer Stelle referenzierbar zu machen, sondern auch deren Breite auszulesen und dann korrekt mit der neuen Syntax zu notieren.

Obwohl der Browser wie oben erwähnt die wichtigsten Umgebungsparameter einer Webseite immer parat hat, kann er das Verhältnis von Bilderbreite und Viewportbreite nicht automatisch schnell errechnen. Mit dem sizes-Attribut können Webworker Abhilfe schaffen. In diesem Attribut werden Mediaqueries mit den Breiten der Bilder, gerechnet in Viewportbreiten (vw), verknüpft:

  1. sizes="(max-width: 20em) 100vw,
  2.        (max-width: 30em) 60vw,
  3.        (max-width: 40em) 50vw"

vw ist hierbei eine relative Breitenangabe. Mit 60vw sind 60% der Viewportbreite gemeint. Der Viewport ist die Fläche, die innerhalb des Browsers zur Darstellung der Inhalte übrigbleibt. Bei mobilen Endgeräten ist dieser Platz fix.

Ein Hoch auf die Details

Die eben vorgestellten Techniken werden dann genutzt, wenn ein Bild in unterschiedlichen Größen für unterschiedliche Bildschirmgrößen zur Verfügung gestellt werden soll. Doch was ist mit redaktionell bearbeiteten Bildern? Viele Motive wirken verkleinert nicht. Das Bild eines Redners wirkt in einer großen Breite auch mit viel Hintergrund. Wird das Bild verkleinert, muss ein Ausschnitt mit dem Redner gewählt werden, da dieser sonst verloren ginge. Solch redaktionell bearbeitete Bilder sollen mit dem neuen picture-Element verbreitet werden. Es erinnert im Grundaufbau ein wenig an das video-Element:

  1. <picture>
  2.   <source media="(min-width: 70em)"
  3.     srcset="http://lorempixel.com/1120/560"
  4.     class="flexible">
  5.   <source media="(min-width: 55em)"
  6.     srcset="http://lorempizza.com/880/440"
  7.     class="flexible">
  8.   <source media="(min-width: 40em)"
  9.     srcset="http://placekitten.com/640/320"
  10.     class="flexible">
  11.   <source
  12.     srcset="http://placeskull.com/360/180">
  13.   <img src="http://placehold.it/400x200&text=Fallback"
  14.        class="flexible"
  15.        alt="Super toller Beschreibungstext">
  16. </picture>

Das picture-Tag fungiert als Wrapper. In ihm sind die einzelnen Alternativbilder mit dem neuen Element source notiert. Es kann ein media-Attribut tragen, das eine Mediaquery definiert. Die eben beschriebenen Attribute srcset und sizes können auch bei source genutzt werden. Die letze Instanz von source hat keine Mediaquery und ist damit der kleinste gemeinsame Nenner. Als Fallback für Browser, die das picture-Element nicht kennen, wird als Letztes ein Fallback-Bild ganz normal mit dem img-Element notiert.

Die source-Elemente haben semantisch nicht den gleichen Status wie das Fallback-Bild im img-Element. Ein Alternativtext ist nur für das img-Element vorgesehen. Mittels source werden nur optische Alternativen vermittelt. Es wird interessant sein zu sehen, ob in diesem Punkt in ein paar Jahren die Spezifikation verändert werden wird, wenn es keine Browser mehr gibt, die das neue picture-Element und damit auch source nicht unterstützen und somit die Notwendigkeit für das img-Element wegfallen wird.

Anselm Hannemann gibt in einem Vortrag ein Beispiel, das alle bisherigen neuen Elemente und Attribute kombiniert. Der Code ist nicht einfach zu lesen und er wird sicherlich noch schwieriger in einem CMS zu realisieren sein:

  1. <picture>
  2.   <source media="(max-width: 80em)"
  3.     sizes="(max-width: 30em) 100vw,
  4.            (max-width: 50em) 50vw,
  5.            calc(33vw - 100px)"
  6.     srcset="pic100.jpg 100w, pic200.jpg 200w,
  7.             pic400.jpg 400w, pic800.jpg 800w, pic1600.jpg 1600w,
  8.             pic3200.jpg 3200w">
  9.   <img src="phew.jpg" alt="Woah, what is this?!">
  10. </picture>

CMS-Unterstützung

Eine echte Herausforderung wird die neue Technik für die CMS-Hersteller. Schließlich müssen mehrere Bilder in ein Element notiert werden, die Art der Einbindung ist unterschiedlich. Es gibt mehrere Möglichkeiten, die Attribute zu nutzen. All dies muss zudem für den Redakteur verständlich kommuniziert werden. Schließlich sind Redakteure normalerweise keine HTML-Experten. Contao hat die neuen responsiven Bilder schon in der neuen Version 3.4 integriert. Auch Drupal 8 wird im Core ein Modul für Responsive Images mitbringen, das auch einen Fallback für ältere Browser berücksichtigt. Wir können zudem auf die ersten Implementierungen in den sogenannten "Enterprise-CMS" gespannt sein.

Browserunterstützung

Bis die alten Browser ausgestorben sind, die die neuen Techniken (srcset, picture) nicht unterstützen, wird es noch lange dauern. Weder sind zum Ende des Jahres 2014 in allen modernen Browsern die neuen Techniken eingebaut und scharfgestellt, noch kann der IE mit einer solchen Unterstützung glänzen. Es ist nicht klar, ob der IE 12 damit aufwarten wird. Auf alle Fälle müssten alle IE-Versionen bis einschliesslich Version 11 aussterben, damit wir flächendeckend native responsive Bilder nutzen können.

Bis dahin können wir uns mit der Nutzung eines Polyfills behelfen. Picturefill ist die in diesem Fall überall empfohlene Krücke. In den oben verlinkten Beispielen auf Codepen ist die neueste Version von Picturefill integriert. Mehr als die möglichst frühe Verlinkung dieses Polyfills muss der Webworker nicht tun. Die Beispiele funktionieren mit dessen Hilfe in allen Browsern. Chrome wartet mit nativer Unterstützung auf.

Chrome lädt dank seiner nativen Unterstützung für die neuen Techniken niemals die Fallbackbilder herunter. Es ist der Testumgebung geschuldet, dass er trotzdem immer das Polyfill herunterlädt. In einem echten Projekt könnte das Polyfill nach einer Modernizr-Prüfung verlinkt oder unterdrückt werden.

Firefox lädt neben dem passenden Bild auch das Fallbackbild herunter. Ein Teilaspekt der Perfomanceoptimierung von Browsern ist, dass sie Bilder möglichst frühzeitig herunterladen. Dies geschieht, bevor mittels JavaScript eingeschritten werden kann. Das Fallbackbild kann selbstverständlich auch ein skaliertes 1px-GIF sein. Dadurch wäre die »Zusatzlast« nur minimal.

Dank Picturefill und dem alternativen Polyfill respimage von Alexander Farkas spricht nichts mehr dagegen, die neuen Techniken für responsive Bilder schon heute zu nutzen. Ohne das Polyfill werden wir trotzdem die nächsten Jahre leider nicht auskommen.

Weiterführende Links

Kommentare

Florence Maurice
am 05.12.2014 - 08:40

Eine Anmerkung hierzu:
"Firefox lädt neben dem passenden Bild auch das Fallbackbild herunter."
Das tut - gerade mal getestet - ebenso der IE11. Deswegen wird bei der Verwendung von picturefill auch vorgeschlagen, auf das src-Attribut zu verzichten (die Beispiele dort sind immer ohne):

"Unfortunately, choosing to add a src attribute to the img element in your picture element isn't a good workaround either, as any browser that exists today will fetch that src url even if it is not going to be used (which is wasteful)."

An sich hat man m.E. nur zwei Möglichkeiten:
1. Native Fallback von Browsern verwenden, d.h. ohne Picturefill, dafür das src-Attribut normal einsetzen.
2. Picture-Fill nutzen ohne src-Attribut. Browser ohne JavaScript bekommen aber dann nur den alt-Text zu sehen.

Permanenter Link

alexander farkas
am 05.12.2014 - 12:18

Das ist so im Detail nicht ganz richtig.

Zu IE11:
Der IE nutzt zwar auch einen preload parser (MS war hier sogar Vorreiter). Der IE unterstützt aber auch das abbrechen von Bild sourcen (Chrome in einer abgewandelten Variante auch und FF ab Version 36 ebenfalls).

Zur src Strategie:
Bei Nutzung von picturefill hast du sicherlich recht, zumal pf auch ein paar bugs hat, die zu Tage treten sobald man src benutzt. Aber du kannst beispielsweise das src attribut als lowsrc attribut verwenden. Sofern das polyfill das unterstützt hast du einen recht interessanten Effekt, da ja sowieso beide Bilder runtergeladen werden, kann man erst als "ersten Eindruck" das kleine Bild anzeigen und dann das größere. Hierdurch wird die wahrgenommene performance sogar eher gesteigert. Ich habe unter http://afarkas.github.io/respimg-load/ ein paar Verlgeichsbeispiele hochgeladen. Wie du sehen wirst fühlt sich die respimage lowsrc Variante deutlich schneller an als die picturefill nosrc Variante (BTW: Insbesondere bei einem 2dpr Gerät lohnt sich auch ein kleiner Blick ins netpanel.)

Permanenter Link

Florence Maurice
am 05.12.2014 - 14:59

das respimg-load sieht wirklich sehr interessant aus ... und löst das Problem des Fallbacks anscheinend gut. Schöne Idee auch mit dem lowsrc! Gibt es schon Projekte, bei denen respimg eingesetzt wird?

Permanenter Link

alexander farkas
am 05.12.2014 - 16:29

Danke. War auch etwas arbeit. Selber habe ich noch kein projekt damit realisiert. Ist ja noch ein relativ junges projekt.

Aber ich weiß dass meine alte Firma es gerade für ein größeres Projekt einsetzt. Daneben durch mails von Entwicklern kenne ich folgende Seiten:

- http://fernandalima.com.br/en/news/ (setzt eine sehr alte Version ein, wo ich selber a) noch nicht das Abbruch-Verhalten im IE kannte und b) das lqip pattern nach guypo variante verwendet habe (inzwischen nutze ich es so wie Steve Souders es beschreibt) (haben beide vor- und nachteile. )
- http://bit.ly/1plS5gq (aktueller, aber ich glaube er verwendet picture mit srcset x statt einfach nur srcset mit w)

Permanenter Link

Santa
am 05.12.2014 - 10:23

Zum Thema Support durch die Browser: Ja, im Prinzip reden wir ja nur über die Fallbacklösung. Es ist davon auszugehen dass Leute mit Retina-Display (oder QHD [??] etc) auch auf eine moderne Browsersuite setzen. Also ruhig einsetzen und die Nutzer zum update zwingen ;)

Permanenter Link
Jens Grochtdreis

Jens Grochtdreis (Autor)
am 05.12.2014 - 10:25

Danke, Florence, für diese Ergänzung. Als Mac-User war ich einfach zu faul, den IE11 in einer VM zu testen. Ich dachte mir schon, dass er sich genauso verhält, wie der Firefox. Was soll er auch sonst tun?

Der Verzicht auf das src-Attribut ist m.W.n. im Standard eher untersagt. Aber man kann da natürlich auch ein 1px-GIF unterbringen. Die aktuelle Lage ist eher ungünstig, das sehe ich auch so. Aber in kurzer Zeit wird die Zahl der Nutzer, die zwei Bilder anstatt eines laden müssen, geringer sein. Dann finde ich es nicht so schlimm. Es ist einfach eine neue Technik, die mit einem Polyfill logischerweise nicht perfekt erreichbar ist. Im Gegensatz zu Flexbox kann man aber diese Technik polyfillen, wenn auch mit einem leichten Nachteil. Muss man wissen und kann man dann abwägen.

Permanenter Link

Florence Maurice
am 05.12.2014 - 10:38

@Jens: Ja, dass das nicht valide ist, wenn man das src-Attribut weglässt, damit hast du recht. Ob es aber besser ist, ein 1px großes Dummybild zu nutzen? Das bezweifle ich ein bisschen. Das ist ja dann nur ein Fake-Fallback, da erscheint mir das Weglassen von src sauberer ... oder eben ohne Polyfill mit src.

Permanenter Link

Christoph Wagner
am 05.12.2014 - 13:05

Sehe ich genauso. Das ist ja auch bei 1x1 ein weiterer Request. Dann lieber nicht valide und schneller.

Permanenter Link

Mirco
am 05.12.2014 - 10:48

Ein sehr schöner Artikel, der das Thema umfassend beleuchtet.

Ich habe die Umsetzung in Contao bereits ausprobiert und die ist echt Hammer! Funktioniert out of the box und deckt beide Einsatzszenarien ab. Echt krass, was die Entwickler da geleistet haben!

Permanenter Link

Sascha
am 05.12.2014 - 12:03

Ich habe da vor ein paar Monaten mal was für srcset und sizes gebaut, da ich mir die Syntax nicht merken wollte.
https://github.com/voodoocode/responsive-placeholder

Permanenter Link

Florence Maurice
am 05.12.2014 - 12:34

@Sascha: nettes Tool :-)
Allerdings fehlen anscheinend noch beim erzeugten Code hinter dem sizes-Attribut die runden Klammern um die Media Queries:

min-width: 300px 80vw,
min-width: 800px 33vw

müsste sein:

(min-width: 300px) 80vw,
(min-width: 800px) 33vw

Permanenter Link

Sascha
am 19.12.2014 - 11:25

Ok, ich hatte die Prämisse, dass man die Klammer selbst mit ins Feld schreibt.
Ich werd das nochmal komfortabler machen.

Permanenter Link

Florence Maurice
am 19.12.2014 - 11:58

ach so, darauf war ich nicht gekommen ... aber ist natürlich auch möglich :-)

Permanenter Link

Gunnar Bittersmann
am 05.12.2014 - 13:48

Browser, die das neue Attribut verstehen, ignorieren die Quelle im src-Attribut, alle anderen lesen sie wie immer aus. Das ist eingebaute Graceful Degredation.

Das ist sogar progressive enhancement.

Das picture-Tag fungiert als Wrapper.

Das picture-Element.

Schließlich müssen mehrere Bilder in ein Element notiert werden, die Art der Einbindung ist unterschiedlich. Es gibt mehrere Möglichkeiten, die Attribute zu nutzen.

In einer idealen Welt müsste man gar nicht verschiedene Ressourcen im HTML einbinden, sondern würde einfach <img src="kitten" alt="Kätzchen, was sonst"/> schreiben. Der Server würde je nach Gegebenheiten des Clients kitten.small.1x.jpg oder kitten.large.2x.jpg ausliefern.

Die Technik dafür ist uralt: content negotiation. Natürlich hätte man dafür entsprechende Felder im HTTP-Header schaffen müssen, um dem Server die Gegebenheiten des Clients (kann neben Bildschirmgröße auch gerade zur Verfügung stehende Bandbreite sein!) mitzuteilen, wie Accept-Language für language negotiaion.

Ich bin immer noch nicht davon überzeugt, dass der mir picture und srcset eingeschlagene Weg der bessere ist.

Permanenter Link
Henry Zeitler

Henry Zeitler (Webkraut)
am 05.12.2014 - 14:46

@Gunnar: Die Technik content negotiation ist zwar uralt, wird aber aktuell wieder diskutiert. Es gibt nämlichen einen ähnlichen Ansatz, der sich HTTP Client-Hints nennt. Mal sehen wohin sich das noch entwickelt...

Permanenter Link

Der Caspers
am 05.12.2014 - 15:31

language negotiaion

Es heißt language negotiation.

Permanenter Link
Nicolai Schwarz

Nicolai Schwarz (Webkraut)
am 05.12.2014 - 16:10

Ah schau, der Gunnar. Ich habe mich schon gefragt, ob du vielleicht krank bist. Oder im Urlaub.
Willkommen beim diesjährigen Adventskalender. :)

Permanenter Link
Nicolai Schwarz

Nicolai Schwarz (Webkraut)
am 10.12.2014 - 13:33

Ok, kleiner Besserwisser-Battle:

Das picture-Tag fungiert als Wrapper.

Das picture-Element.

Speziell darüber bin ich beim Redigieren auch gestolpert. Mein erster Impuls war ebenso, daraus ein Element zu machen. Allerdings geht es darum, einen Wrapper zu bilden, etwas, das die anderen Elemente umschließt. Ein picture-Element besteht aus Start-Tag. End-Tag und dem Elementinhalt. Insofern ist alles zusammen zwar ein Element, kann aber nicht als Wrapper um sich selbst dienen. Genau genommen hätte es, die picture-Tags heißen müssen. In dem Fall habe ich es beim Singular belassen, es steht stellvertretend für das Start-Tag und das End-Tag.

Permanenter Link

Oliver
am 05.12.2014 - 16:17

Hallo,

was spricht dagegen mit Mobile-Detect zu gucken welches Gerät das Bild anfordert und dann das richtige Bild (welches der Redakteur im CMS erstellen kann aber nicht muss) für dieses Gerät auszuliefern? Das hätte meiner Meinung nach nur den Nachteil, dass wenn der Redakteur keine Alternativen erstellt hat das Bild geresized wird oder falls jemand seinen Browser zusammenschiebt evtl. nicht dass passende Bild angezeigt bekommt (viewport / zoom etc.). Na und?

LG
Oliver

Permanenter Link

Mirael
am 05.12.2014 - 20:39

Hi,
mit dem Cms Hut gesehen. :) Es müssen aus einem grossen 6 kleinere Bilder gerendert werden. Eine kleine Rechnung dazu . Das macht bei 20 Bilder pro Seite .120 kleinere Bilder. Bei angenomenen 300 Seiten im Cms. 36000 Bilder. Unberücksichtigt Sprachversionen. Wehe dem der den Cache löschen Button drückt :).

Vg
Mirael

Permanenter Link

Peter Müller
am 11.12.2014 - 15:51

Danke für den Beitrag. Spannendes Thema, und immer neue Aspekte. Was mir beim Lesen auffiel:

---
1. srcset x ist nur für nicht responsive Seiten sinnvoll
Grafiken nach Pixeldichte mit srcset x auszuliefern ist eigentlich nur als erste Hilfe für nicht-responsive Webseiten interessant, denn die Viewportbreite wird dabei nicht berücksichtigt. Andererseits ist die Abfrage der Pixeldichte in srcset w und sizes mit drin: Der Browser kennt die DPR des Bildschirms und berechnet einfach entsprechend mehr Pixel.

---
2. Bei img und srcset w entscheidet der Browser

Der Webworker kann da leider nicht eingreifen...

Wieso "leider"? Das ist doch das eigentlich Geniale an der Lösung. Der Browser kennt die Pixeldichte und die Viewportbreite, der Webworker gibt ihm die Bildbreite (w-Wert) und Darstellungsbreite (sizes). Damit hat der Browser alle benötigten Infos ohne dass er die Bilder herunterladen muss, und trifft dann eine Entscheidung. Das ist auch gut so, denn nur der Browser kennt die Umgebung in der das Bild letztlich dargestellt wird. Wer dem Browser die genaue Grafik vorschreiben will, nimmt picture und source ("art direction").

---
3. Das Bild wird nach wie vor mit img dargestellt

Die source-Elemente haben semantisch nicht den gleichen Status wie das Fallback-Bild im img-Element.

source ist nicht als Alternative zu img gedacht. source und srcset dienen nur dazu, einen Satz ("set") von Grafikdateien anzubieten. Der Browser wählt eine Grafikdatei und trägt sie intern im img-Element als Wert für src ein. Zur Darstellung der Grafik benutzt er nach wie vor img.

Das Thema wird uns noch eine ganze Weile beschäftigen, aber die CMSysteme sind auf einem guten Weg ;-)

Permanenter Link

alexander farkas
am 11.12.2014 - 23:29

Grundsätzlich entscheidet der browser immer bei srcset egal ob w oder ob x descriptor genommen wird.

Ich gebe dir zwar recht, daß es grunsätzlich super ist, daß der Browser entscheidet, aber ich muß dir leider darin widersprechen, dass der Browser alle nötigen Informationen hat, um eine gute Entscheidung zu treffen.

Ein Beispiel:
Die Gleichung x% mehr Pixeldichte führt bei jedem Bild zu einer wahrgenommen Qualitätssteigerung von y%, ist nämlich nicht gegeben.

Ein nicht fundiertes Zahlenspiel:
Ca. 70% aller Bilder sehen auf einem 2x Gerät mit um 1.5x genau so aus wie die 2x Variante. 10% sehen bereits mit 1.2x oder drunter so aus wie die 2x Variante und die restlichen brauchen dann tatsächlich die 2x.

Der Browser kennt diese dem Bild inne wohnende Eigenschaft nicht, es gibt kein Attribut um ihm dies mitzuteilen und da die Pixeldichten zum quadrat die Verfielfachung der zu übertragenden Bilddaten führt, ist das schon eine nicht zu unterschätzende Information.

Auf folgender Seite kannst du, ein hoch auflösendes Display vorausgesetzt, übrigens unterschiedliche Pixeldichten miteinander vergleichen (links die "optimumx" und rechts die 2x Variante):
http://afarkas.github.io/lazysizes/optimumx/

Und mach immer schön im Kopf mit was der jeweilig vorhandene oder eben überhaupt nicht sichtbare Qualitätsgewinn an zusätzlichen Daten bedeutet.

Permanenter Link

Peter
am 12.12.2014 - 09:22

Da hast du wohl Recht, denn der Browser kennt zwar die Pixeldichte, aber er ist auch nur eine Maschine und kein Grafikdesigner ;-) --- Könnte da der Autor der Webseite nicht nachhelfen, indem er bei srcset 2x eine Grafik angibt, die in Wirklichkeit z. B. nur 1.2x ist, um Pixel zu sparen?

Permanenter Link

Peter
am 12.12.2014 - 10:14

Ich hatte geantwortet, bevor ich auf der Github-Seite war, da gerade kein Retina-Gerät direkt verfügbar war. Das ist ja nicht nur ein Showcase, sondern gleichzeitig eine Lösung. Meinen vorherigen Kommentar ziehe ich hiermit zurück ;-)

Permanenter Link

alexander farkas
am 12.12.2014 - 11:02

Workaround ;-)

Permanenter Link

Peter
am 12.12.2014 - 11:06

So wie in »If you can't solve a problem, you "work around" it.« ;-)

Permanenter Link

Peter
am 12.12.2014 - 11:10

@alexander_farkas Wo du gerade hier bist: Besteht eine Chance, dass Picturefill und RespImage irgendwann gemergt werden? Oder werden das getrennte Projekte bleiben?

Permanenter Link

graste
am 21.12.2014 - 13:12

Zum Thema CMS und Redaktionen:
Thumbnails in allen möglichen Größen und für verschiedenste Einsatzszenarien beim Hochladen (oder direkt im Anschluss daran) zu erzeugen ist meiner Meinung nach nicht mehr zeitgemäß. Bei festgezurrten Vorgaben oder kleinen Websites mit einfachem CMS kann man natürlich diskutieren. Bei großen Seiten und Portalen ist das jedoch schnell schwierig (wie Mirael oben bereits angedeutet hat). Das Source-Bild muss auf jeden Fall immer erhalten bleiben um später wieder andere Formate erzeugen zu können (Änderungswünsche, Redesigns, neue Features).

Als praktische Variante für größere Projekte empfiehlt sich ein separater Bildserver: http://berlinonline.github.io/converjon/

Im CMS markiert man nur noch den interessanten – immer zu erhaltenen – Teil des Bilds (vgl. den Contao-Link des Artikels). Dieses AOI (area of interest) wird in die Bildmetadaten geschrieben und vom ausliefernden Bildserver beachtet. Wenn das CMS das nicht hergibt, wünscht man sich im Frontend ein AOI oder halt bestimmte Größen etc. direkt via URL-Parametern.

Im Demo unter http://berlinonline.github.io/converjon/demo/demo.html kann man sehen, dass selbst eine Automatik gute Ergebnisse erzeugen kann (AOI automatic cropping).

Vorteil der Entkopplung von Bildauslieferung und Bildanzeige in Frontends ist, dass man als Kunde/Entwickler bei Prototypen, Redesigns etc. sofort neue Größen und Use-Cases abbilden kann. Andere Größen oder Crops stehen sofort zur Verfügung. Der anfängliche Aufwand für die Einrichtung dieser Infrastruktur relativiert sich bei anstehenden Änderungen direkt und sofort. Ein Löschen des Bildcaches (des Bildservers) ist zudem kein großes Problem, da die wirklich benötigten Formate durch Seitenaufrufe automatisch nach und nach neu erzeugt werden. Bei stark frequentierten Seiten ist die Auslieferung der Bilder des Bildservers über einen Reverse-Proxy wie Varnish oder nginx empfehlenswert, da man so die dynamisch erzeugten Bilder besser cachen kann.

Permanenter Link

Die Kommentare sind geschlossen.