Gutenberg und variable Bildgrößen

Über Gutenberg eingebundene Bilder sind nicht immer automatisch für verschiedene Auflösungen optimiert – achten Sie auf die Fallstricke!

Responsive Webdesign

Es gibt verschiedene Webtechniken, die in aktuellen Browsern dafür sorgen, dass Bilder in den richtigen Auflösungen geladen werden – Gutenberg unterstützt sie teilweise – eine Bestandsaufnahme.

One Size Fits All? Leider nicht.

Früher musste eine Bildauflösung für verschiedene Endgeräte reichen – eine immerwährende Suche nach dem Kompromiss zwischen hohen Bilddetails und hoher Performance. Beispiel:

<img src="image.png">

Es ist offensichtlich, dass eine Bilddatei nicht alle Auflösungsformate abbilden kann, sondern stets nur eins. Ob Retina-Smartphone, quer- oder hochformat, Tablet, Ultrabook, Desktop-Monitor oder 4k Fernseher: Es gibt unzählige unterschiedliche Geräte und damit Auflösungen. Im Responsive-Design wird das Layout der Website fließend an die verschiedenen Formate angepasst – und trotzdem immer ein gleich großes Bild geladen – das muss besser gehen.

Nehmen Sie unsere Website als Beispiel: Das nötige Format für Desktop oder Mobilauflösung ist für das Beitragsbild völlig unterschiedlich: Auf Desktop wird eine andere Auflösung benötigt, als auf Mobil.

Bildgrößen abhängig von der Bildschirmauflösung

Um Bilder für verschiedene Bildschirmgrößen zu laden, gibt es inzwischen die Möglichkeit, abhängig von der Bildschirmgröße dem Browser verschiedene Bildauflösungen zu übermitteln – er lädt dann möglichst das Bild passend zur Auflösung:

<img src="image.png" srcset="image.png 1500w, image-1000x500.png 1000w, image-500x250.png 500w, image-250x125.png 250w">

Das srcset-Attribut listet weitere Alternativgrößen des Bildes auf. In diesem Beispiel gibt es an, dass die Original image.png 1500 Pixel breit ist, die image-1000×500.png 1000 Pixel und so weiter. Der Browser weiß daher schon vor dem Laden der Bilder, in welchen verschiedenen Auflösungen sie vorliegen. Belassen wir es bei diesen Angaben, wird die Breite des Bildes mit der Breite der Bildschirmauflösung abgeglichen – so wird zumindest möglichst ein Bild geladen, das nicht größer als die Bildschirmbreite ist. Für ein Header-Bild in Bildschirmbreite völlig ausreichend.

Bildgrößen abhängig von Slotbreite

Leider hilft uns die Bildschirmauflösung allein als Schwellenwert oft nicht weiter. Dieser Weg funktioniert im Grunde nur, wenn es keine unterschiedlichen Layouts gibt, also z.B. alle Bilder immer eine gleiche Breite haben und diese sich nur an die Bildschirmauflösung anpassen müssen.

Auf vielen Websites sind Bilder aber unterschiedlich gelayouted. Eine Sidebar könnte auf manchen Unterseiten aktiv sein, auf manchen nicht. Bilder könnten die gesamte Bildschirmbreite einnehmen (Full Width) oder aus der Breite des Inhalts ausbrechen (Wide Width). Aber auch wenn Bilder nicht größer sind, als die Breite des Fließtextes, können sie in Spalten strukturiert sein.

Spaltenbreite

Gerade die Verwendung von Spalten im Layout des Inhalts verkompliziert alles: In Desktop-Auflösung werden die Spalten nebeneinander angezeigt, haben also jeweils eine geringere Breite, als auf Mobil, wo sie umbrechen und in voller Breite untereinander angezeigt werden.

Fließtextbreite

Die Bilder im oben genannten Beispiel sind auf Mobil daher größer und so müsste hier auf Mobil ein höher aufgelöstes Bild geladen werden, auf Desktop reicht eine kleinere Variante.

Mit Desktop-Auflösung hat ein Bild durch die Spaltenansicht eine Breite von 172 Pixeln.
Mit Mobil-Auflösung werden die Spalten untereinander dargestellt und erhalten so eine Breite von 335 Pixeln.

Slotbreite festlegen

Wenn wir also wissen, wie breit die einzelnen Slots sein werden, in denen Bilder dargestellt werden sollen, können wir diese über das sizes-Attribut festlegen:

Mithilfe des sizes-Attributs können Media-Queries genutzt und abhängig davon Schwellen festgelegt werden. Diese definieren die Größe einzelner Slots, die die Bilder unter den Auflösungen einnehmen werden. Für die Slot-Größe können Einheiten, wie Viewport (vw), Pixel (px) oder em (relative Größe), nicht aber Prozent gewählt werden.

<img src="image.png" srcset="image.png 1500w, image-1000x500.png 1000w, image-500x250.png 500w, image-250x125.png 250w" sizes="(max-width: 250px) 250px,(max-width: 500px) 500px,(max-width: 1000px) 1000px, 1500px">

IMG sizes erklärt

Anhand des gezeigten Codes erkennt man folgendes:

4 Bilder liegen als Ressourcen (srcset) vor.

  • 1500 Pixel Breite
  • 1000 Pixel Breite
  • 500 Pixel Breite
  • 250 Pixel Breite

Außerdem wird für drei verschiedene Auflösungsschwellen (sizes) festgelegt, welches Bild geladen werden soll:

  • Bildschirmbreite maximal 250 Pixel: Lade 250 Pixel Bild
  • Bildschirmbreite maximal 500 Pixel: Lade 500 Pixel Bild
  • Bildschirmbreite maximal 1000 Pixel: Lade 1000 Pixel Bild
  • Ansonsten wird wieder das Originalbild geladen, also das 1500 Pixel breite Bild

Das löst jedoch nicht das Slot-Problem, denn das oben genannte Verhalten wäre auch das Standard-Verhalten des Browsers, wenn nur srcset ohne sizes definiert gewesen wäre. In der Desktop-Auflösung würde wegen der Spaltenansicht schließlich kleinere Bilder reichen. Ein optimiertes Loading könnte also wie folgt aussehen:

Slotbreiten berechnen

Die Breakpoints im sizes-Attribut sollten nicht nur exakt denen in unserem Responsive-Design entsprechen – sondern auch sinnvolle Bildgrößen nutzen. Wenn unser Webdesign also bei maximal 1000 Pixeln Breite auf mobil umbrechen sollte, müssten wir für das Desktop-Layout (>1000 Pixel Bildschirmbreite) festlegen, wann das Bild nicht mit den vollen 1500 Pixeln geladen werden soll. Solange es sich also um kein Full-Width-Bild handelt, müssen wir den Wert für Desktop anpassen. Wir müssen jetzt also wissen, welche Layoutfunktionen die Breite des Bildes beeinflussen könnten. Der Entscheidungspfad am Beispiel der Spalten:

  • Das Bild nimmt keine volle Breite ein
  • Das Bild nimmt keine weite Breite ein
  • Das Bild befindet sich innerhalb des Inhaltsbereichs und hat daher maximal dessen Breite
  • Das Layout hat keine Sidebar und daher hat sich die Breite des Inhaltbereichs nicht geändert
  • Das Bild befindet sich in einer Spalte und nimmt daher nicht die volle Breite des Inhaltbereichs ein
  • Es sind 3 Spalten, daher sollte des Bild ein Drittel so breit, wie die Breite des Inhaltsbereichs sein.
  • Ggf. noch Abzug von Abständen (Margins) innerhalb der Spalten
<img src="image.png" srcset="image.png 1500w, image-1000x500.png 1000w, image-500x250.png 500w, image-300x150.png 300w, image-250x125.png 250w" sizes="(max-width: 250px) 250px,(max-width: 500px) 500px,(max-width: 1000px) 1000px, 300px">

Die neuen Schwellen wären also:

  • Bildschirmbreite maximal 250 Pixel: Lade 250 Pixel Bild
  • Bildschirmbreite maximal 500 Pixel: Lade 500 Pixel Bild
  • Bildschirmbreite maximal 1000 Pixel: Lade 1000 Pixel Bild
  • Bei über 1000 Pixel Bildschirmbreite wird das Desktop-Layout angezeigt und damit die Spaltenansicht. Der Contentbereich hat dann eine maximale Breite von 1000 Pixeln, so dass bei drei Spalten die Bilder in einer Auflösung von 300 Pixeln geladen werden sollen. Zusätzlich haben wir eine zusätzliche Stufe für das srcset eingerichtet, da wir öfter dreispaltiges Layout nutzen und die Zwischenstufe daher passgenau ausliefern möchten.

Es ist also technisch machbar, dem Browser die richtige Bildgröße zu übermitteln – warum wird das in Gutenberg dann (noch) nicht gemacht?

Das ganze bitte automatisch

Bisher hat auch das WordPress-Gutenberg-Team hierfür noch keine finale Lösung gefunden: Wie wird dann jeweils für jedes Bild die Slotbreiten berechnet? Am Besten wären die Browser selbst dazu geeignet: Sobald eine Website gerendert ist, weiß der Browser, wie breit der Slot ist und könnte aus den unter srcset definierten Bildern das passende wählen.

Die Browser wissen nur leider zu diesem Zeitpunkt noch gar nicht die Slotbreite: Bis hierhin wird das HTML vom Browser gelesen, aber noch nicht die Styles (CSS) – gleichwohl sollen schon die Bilder in den richtigen Größen angefragt werden, noch bevor der Browser weiß, wie groß sie später tatsächlich dargestellt werden sollen.

Da WordPress bzw. Gutenberg also das HTML-Markup erstellt, müssen diese bereits festlegen, welche Breite die Bilder je nach Media-Breakpoint haben sollen – abhängig von den genannten Layout-Faktoren.

Der Grund, warum die Slotbreitenberechnung für die Auslieferung der Bilder nicht durch die Browser durchgeführt wird ist ein Performancevorteil: Etwa 20% Prozent soll der Seitenaufbau schneller sein – theoretisch, denn wenn viel zu große Bilder geladen werden, ist der Performancevorteil schnell dahin.

Gutenberg: Responsive unvollständig.

Gutenberg vermeidet aktuell effektiv, dass kaum ein über den Image-Block eingebundenes Bild viel größer ist, als die Bildschirmgröße – das war es dann aber auch schon. An folgendem Screenshot sieht man, dass man bei drei Spalten in der Desktop-Auflösung leicht ein Bild lädt, das um den Faktor 10 zu groß sein kann.

Werden zusätzlich Spalten verwendet, wird die Diskrepanz noch größer – Briefmarkengroße Bilder werden in voller Auflösung geladen. In diesem Beispiel das ca. 1500 Pixel große Original. Zur Verfügung stünde zwar auch eine Version mit 250 Pixeln Breite – doch die wird nur geladen, wenn das Browserfenster maximal 250 Pixel breit ist.

Zwar erlaubt der Bilder-Block die Auswahl der Bildgröße in den Blockeinstellungen – aber genau das ist nicht Responsive, schließlich ist bei dieser Auswahl nicht bekannt, welches Endgerät die Seite besucht und somit welche Bildgröße korrekt gewesen wäre.

An einer Lösung wird gearbeitet

Wenn Sie möchten, beteiligen Sie sich gern an einer Lösung des Problems, eine der Hauptdiskussionen finden Sie auf GitHub, es gibt aber noch viele weitere Tickets, die sich sich mit dem Responsive Media Sizes Problem in Gutenberg befassen. Dies sind derzeit die größten Hürden:

  • Der Gutenberg-Editor hat meist eine andere Breite, als das Frontend, daher lässt sich das sizes-Attribut nicht im Editor via Javascript berechnen.
  • Alternativ müssten beim speichern eines Posts für jedes Bild media-sizes berechnet werden, abhängig vom Layout, also ob Full Width / Wide Width / Content Width / Content Width – Sidebar / Column Width und bei Column Width auch noch die Anzahl der Columns oder deren Breite. Beliebig verschachteln ließen sich Columns noch mit dem Groups-Block.
  • Die Entwickler versuchen also eine möglichst allgemeingültige Berechnungsgrundlage zu finden, die mit Millionen von WordPress-Websites, die den Gutenberg-Editor nutzen, harmoniert.

Interimslösung: Legen Sie z.B. mit Imagify eine maximale Breite für alle Bilder fest, manuell für jedes Bild einzeln geht das in der Mediathek. So verhindern Sie zumindestens das Schlimmste, z.B. 4.000 Pixel Breite Bilder.

Wenn Sie sich für das Thema interessieren und noch tiefer eintauchen möchten: