Bilder für eigene Internetseiten aufbereiten

Hinweis: Von diesem Artikel gibt es auch eine Kurzversion, die nur die wichtigsten Testbilder enthält und auf die ausführlichen Erklärungen verzichtet.

Seit sich das World Wide Web in den 1990er-Jahren als Massenmedium etabliert hat, gab es fürs Webdesign immer wieder neue Ansätze. Auch beim Einbinden von Fotos und Grafiken muss man heute ganz andere Dinge beachten als damals. Das betrifft z. B. die Verwendbarkeit bestimmter Dateiformate, die Bedeutung von Auflösung und Dateigröße oder den Umgang mit dem Thema Skalierung.

Auf dieser Seite geht es schwerpunktmäßig um die Aufbereitung der Bilddateien, die in Internetseiten eingebunden werden sollen. Stellenweise werden dazu auch ein paar Zeilen HTML- und CSS-Code gezeigt, aber diese sind nur als Beispiele und Anregungen zu verstehen. Diese Seite hat nicht den Anspruch, eine Einführung in das Thema Web-Programmierung und Responsive Webdesign zu sein. Dafür gibt es ja bereits gute und umfangreiche Quellen wie selfhtml.org oder w3schools.com.

Dateiformate für Web-Bilder

Zwei Grafikformate aus den Anfangsjahren des Word Wide Web sind bis heute mit jedem Browser kompatibel geblieben: JPEG und GIF. Wenig später kam dann noch das PNG-Format hinzu. Nur diese drei Formate werden von 100 % der Bestandsbrowser weltweit untestützt. Wer sich Fallback-Lösungen komplett sparen und trotzdem ganz sicher sein will, dass seine Bilder in allen (auch sehr alten) Browsern zu sehen sind, muss nach wie vor bei diesen drei Formaten bleiben.

Versuche von Firmen und Interessengruppen, neuere und bessere Dateiformate für Webbilder zu etablieren, gab es seither viele. Die meisten Formate sind schnell wieder verschwunden. Die meisten sind nicht an mangelnder Qualität gescheitert, sondern an ihren restriktiven Lizenzbedingungen – denn weder Webseitenbetreiber noch Browserhersteller hatten Lust, für die Nutzung eines geringfügig verbesserten Formates Geld zu bezahlen.
Die Auswahl hier in dieser Aufzählung beschränkt sich daher bewusst auf Formate, die frei verwendbar sind und auch schon eine gute Browser-Unterstützung aufweisen können. Natürlich gibt es immer auch noch wesentlich neuere (Nachfolge-)Formate, die vielleicht vielversprechend sind – aber mit denen man als Webseitenbetreiber trotzdem noch nichts anfangen kann.

Achtung: Die folgenden Charakterisierungen der Dateiformate beziehen sich auf die Nutzung innerhalb von Internetseiten. Vor- und Nachteile dieser Formate für andere Nutzungsarten (Aufnahme, Archivierung, Druck, Social Media, Messenger, E-Mail-Anhänge etc.) sind ein völlig anderes Thema und spielen hier bewusst keine Rolle.

JPEG

Man kann das seit 1992 existierende JPEG-Format („Joint Photographic Experts Group“) aufgrund seiner Verbreitung als den ungekrönten König der Grafikformate bezeichnen. Trotz seines – für Computer-Verhältnisse – biblischen Alters von über 30 Jahren ist es für Fotos und die meisten anderen Arten von Web-Bildern nach wie vor gut geeignet. Neuere Formate mit etwas effizienterer Kompression konnten sich noch nicht auf breiter Front gegen JPEG durchsetzen. Das Argument der Kompatibilität von JPEG wog bisher stets schwerer.

Tatsächlich ist die JPEG-Kompression für Fotos auch heute noch recht brauchbar, solange man die Kompressionsrate nicht zu hoch treibt. Bekannte Schwächen hat sie allerdings bei Strichgrafiken und einfach aufgebauten Farbgrafiken; diese werden in JPEG nur sehr ineffektiv komprimiert bzw. mit unnötig vielen Artefakten dargestellt. Auch einen Alphakanal (Transparenz) kennt das JPEG-Format leider nicht.

GIF

Das GIF-Format („Graphics Interchange Format“) wurde in einer ersten Version bereits im Jahr 1987 vorgestellt, als die Grafikfähigkeiten von Computern noch sehr beschränkt waren. Es kann maximal 256 Farben darstellen und ist deshalb für Fotos nicht gut geeignet – denn selbst bei kluger Vorauswahl der Farbtöne wird man irgendwo Tonwertabrisse sehen. Obwohl GIF bis zum Jahr 2006 einigen Patenten unterlag und nicht lizenzfrei verwendbar war, wurde es mangels Alternative im frühen World Wide Web gern für glatte Grafiken eingesetzt. Da GIF eine 1-Bit-Transparenz bietet (d. h. man kann ganze Pixel transparent machen), wurden GIF-Dateien auch häufig für „Text als Grafik“ missbraucht (was schon damals als Notlösung galt und im heutigen Webdesign gänzlich verpönt ist).

Seit das PNG-Format eine ausreichende Browserunterstützung gefunden hatte, wurde GIF so gut wie gar nicht mehr für nicht-animierte Bilder und Grafiken benutzt. Weiterhin verwendet wurde GIF jedoch für einfache Animationen (Bildfolgen), die sich trotz der besagten Beschränkung auf 256 Farben einer großen Beliebtheit erfreuten. Vielen Leuten ist GIF heute noch als Format für Animationen geläufig, und es werden teilweise sogar noch neue Animationen im GIF-Format erstellt. Inzwischen bieten aber WebP und AVIF eine vergleichbare Funktion mit weniger Einschränkungen, so dass GIF-Animationen inzwischen nicht mehr (oder allenfalls noch als Fallback) zu empfehlen sind.

PNG

Das PNG-Format („Portable Network Graphics“) entstand ab 1995 in mehreren Versionen als lizenzfreie Alternative zu GIF. Es überwand auch gleich dessen Einschränkungen: Es leidet nicht an beschränkter Farbauswahl und bietet eine 8-Bit-Transparenz, die teiltransparente Stellen sowie weiche Übergänge zum Hintergrund ermöglicht.
Dank verlustfreier Kompression zeigen Bilder im PNG-Format keinerlei Artefakte. Das macht es ideal für Grafiken mit glatten Kanten und Strichgrafiken, die in JPEG nicht gut aussehen und/oder zuviel Speicherplatz brauchen würden. Für normale Fotos gilt allerdings genau das Umgekehrte: Hierfür wird man eher bei JPEG bleiben, weil dann PNG unnötig viel Speicherplatz braucht.
Ein Spezialfall sind Bilder, die transparente Bereiche enthalten. Da JPEG das nicht kann, war hierfür PNG lange Zeit alternativlos – große Dateien hin oder her. Heute kann man dafür WebP und/oder AVIF verwenden, aber PNG wird dann noch gern als Fallback genutzt.

Mit dem sogenannten APNG-Format wurde 2004 eine animierbare Variante von PNG nachgereicht, die sich aber nie gegen animiertes GIF durchsetzte. Bis heute kann nicht jeder Browser, der einfaches PNG darstellen kann, automatisch auch APNG-Dateien abspielen. Zwar hat APNG gegenüber GIF der Vorteil der vollständigen Farbpalette, aber es verursacht wegen der verlustfreien Kompromierung mächtig große Dateien, die man auf Webseiten nicht so gern hat. Wenn man heute animierte Sequenzen in guter Qualität und erträglicher Dateigröße erstellen will, würde man das WebP-Format und/oder das AVIF-Format verwenden.

Anhand der folgenden kleinen APNG-Datei kann man testen, ob der eigene Browser die Animation (hier ein leichtes Blinken der Textdicke alle drei Sekunden) wiedergibt. Wenn die Datei gar nicht angezeigt werden kann, erscheint ein Ersatzbild mit dem Hinweis „funktioniert leider nicht“:

WebP

Von allen alternativen Formaten für Web-Bilder hat es WebP („Web Picture“ oder „Weppy“) bisher am weitesten gebracht und ist in Sachen Browser-Kompatibilität nah an die etablierten Formate herangerückt. Es gibt kommerzielle Webseiten, auf denen WebP inwischen in größerem Umfang verwendet wird (z. B. ein Teil der Vorschaubilder auf eBay, Amazon, YouTube oder Google Play).
Das WebP-Format stammt aus dem Jahr 2010. Es basiert auf dem Videocodec VP8 und wurde von Google entwickelt. WebP ist lizenzfrei nutzbar und wird seit einigen Jahren in allen aktuellen Browsern unterstützt: in Chrome seit 2014, in Edge seit 2018, in Firefox seit 2019 und in Safari seit 2020. Fallback-Lösungen braucht man (Stand September 2026) nur noch für 3 % der Bestandsbrowser – Tendenz weiter sinkend. Wer sich an ein eher junges Publikum wendet und/oder damit leben kann, dass die Bilder auf älteren iPhones, auf sehr alten Android-Phones sowie auf wenigen uralten Computern nicht zu sehen sind, kann sich das Fallback für WebP mittlerweile ganz sparen.

Anhand der folgenden kleinen WebP-Dateien kann man den eigenen Browser testen.

Das bekannteste Argument für WebP ist seine effektivere Kompression im Vergleich zu JPEG. Offiziell geht man von etwa 30 % aus, praktisch kann man mit guter Software schon 50 % erreichen. Der konkrete Qualitätsvergleich ist leider rein subjektiv, weil die Kompression von WebP ganz anders arbeitet als die von JPEG: Statt Klötzchen produziert WebP eher Unschärfen. Von daher kann man über den genauen Prozentsatz der Verbesserung stets streiten (und natürlich hängt sie auch stark von der verwendeten Software und deren Einstellung ab).

Eine „nur“ 50-prozentige Ersparnis nicht in jedem Fall ein Argument für WebP-Nutzung als Ersatz für JPEG. Der wahre Vorteil von WebP liegt in Anwendungsbereichen, für die man früher GIF oder PNG verwendet hätte: Glatte Grafiken kann man mit WebP deutlich datensparsamer darstellen als mit PNG oder mit JPEG. Außerdem bietet WebP volle 8-Bit-Transparenz – und das im Gegensatz zu PNG auch in Verbindung mit verlustbehafteter Kompression. Wenn Fotos transparente Bereiche haben sollen, kommt WebP gegenüber PNG also mit einem Bruchteil der Dateigröße aus.

Ein weitere interessante WebP-Option sind einfache Animationen (Bildfolgen), die im Gegensatz zu GIF-Animationen nicht mehr unter beschränkter Farbabstufung leiden und dank effektiver Kompression nicht zu größeren Dateien führen. Das macht WebP heute zum bevorzugten Format für einfache Animationen.

AVIF

Erst 2019 vorgestellt und somit ein paar Jahre jünger als WebP ist das AVIF-Format („AOMedia Video 1 Image Format“). Es basiert, wie der ausgeschriebene Name schon andeutet, auf dem Videocodec AOMedia Video 1. Das AVIF-Format hat technische Ähnlichkeit mit dem in neueren Kameras und Smartphones verwendeten HEIC-Format – kann im Gegensatz zu diesem aber lizenzfrei genutzt werden. AVIF wurde von der „Alliance For Open Media“ entwickelt, der u. a. Apple, Microsoft, Google, Samsung, Netflix und Meta angehören.

Bisher gibt es noch nicht ganz so viele Programme und PlugIns, die AVIF erzeugen können. Die Browserunterstützung für AVIF ist aber inzwischen gegeben: in Chrome seit 2020, in Edge seit 2024, in Firefox seit 2021 und in Safari seit 2023. Unter Bestandsbrowsern geht man von etwa 7 % aus, die AVIF noch nicht darstellen können und deshalb auf Fallbacks angewiesen sind.

Hier die passenden AVIF-Dateien zum Testen des eigenen Browsers:

Da das AVIF-Format Transparenz beherrscht, kann es wie WebP als datensparende Alternative zu transparentem PNG eingesetzt werden. Auch einfache Animationen (Bildfolgen) sind mit AVIF möglich.
Gegenüber JPEG soll man mit AVIF mindestens 50 % der Dateigröße einsparen können – und mit Weiterentwicklung der AVIF-Encoder wahrscheinlich in Zukunft noch etwas mehr.

SVG

Mit SVG („Scalable Vector Graphics“) steht für Webseiten ein vektorbasiertes Grafikformat zur Verfügung. Für glatte, am Computer erstellte Grafiken ist das von Vorteil, weil sich Vektorgrafiken beliebig skalieren lassen und nie richtig unscharf bzw. pixelig werden. Auch Transparenz ist mit SVG kein Problem.
Darüber hinaus lassen sich im SVG-Format auch Vektor-Animationen speichern, die sich technisch mit Bildabfolgen in GIF, WebP oder AVIF nur bedingt vergleichen lassen. Das ist aber wirklich eine Spezialanwendung und wird in der Praxis wenig genutzt.

Im Prinzip wird SVG von allen aktuellen Browsern und auch von den meisten älteren Browsern unterstützt.
Allerdings ist das SVG-Format ziemlich vielschichtig und nicht in allen Details klar dokumentiert, so dass es im Ausnahmefall (bestimmte Sorten von Animationen) noch zu Inkompatibilitäten mit alten Browsern kommen kann. Ob sich für diese seltenen Probleme noch ein Fallback lohnt, ist fraglich. Für einfache SVGs ohne Animation braucht man auf keinen Fall mehr ein Fallback.

Hier sind drei bewusst sehr einfach gehaltene SVG-Dateien. Damit kann man testen, ob der eigene Browser grundsätzlich SVG versteht:

In der Theorie sollten SVG-Grafiken ja immer perfekt aussehen, aber praktisch hängt das auch von ihrer Verarbeitung im Browser ab. Manchmal geschieht das Rendering noch nicht optimal, wodurch z. B. schräge Linien etwas stufig erscheinen können (Aliasing) oder feine Linien zu dick aussehen. Und ab einer gewissen Anzahl der Vektorpunkte braucht SVG auch ziemlich viel Speicherplatz. Es bedarf also immer einer Abwägung oder praktischer Tests, wann man Vektorgrafiken auf einer Webseite tatsächlich vektorbasiert als SVG zeigt und wann man sie lieber in ein Pixelformat konvertiert.

Konkrete Empfehlungen für Dateiformate

Die folgenden Tabellen machen Vorschläge, welches Dateiformat bzw. welche Fallback-Folge von Dateiformaten aktuell für welchen Bildinhalt besonders gut geeignet ist. Je nach Anspruch und Inhalt der Webseite wird man unterschiedlich vorgehen.

(A) Nur etablierte Formate, kein Fallback, sichere Darstellung in 100 % der Bestandsbrowser

(B) Moderne Formate, kein Fallback, Darstellung in mindestens 95 % der Bestandsbrowser

(C) Schwerpunkt auf etablierte Formate, sichere Darstellung in 100 % der Bestandsbrowser

(D) Schwerpunkt auf moderne Formate, Darstellung in mindestens 95 % der Bestandsbrowser

Ob Fallback-Lösungen lohnen, muss im Einzelfall abgewägt werden. Dort, wo der Qualitätsgewinn oder Speicherplatzvorteil den zusätzlichen Aufwand nicht rechtfertigt, wird man darauf verzichten und entweder nur das sichere/alte Format verwenden oder damit leben, dass wenige Nutzer sehr alter Browser die Bilder nicht zu sehen kriegen.

Auflösung und Skalierung

In den Anfangsjahren des Internets galt der Grundsatz: Bilder soll man immer in genau der Auflösung anlegen, in der sie im Browser angezeigt werden. Browser waren nämlich notorisch schlecht darin, Bilder umzuskalieren. Zudem wollte man unnötig große Dateien vermeiden. Setzte jemand ein Foto in nicht exakt passender Auflösung in eine Internetseite ein, erkannte man das sofort an der schlechten Skalierungsqualität. Sowas galt als der sichere Beweis, dass hier ein Webdesign-Stümper am Werk war.

Kaum ein Grundsatz des Webdesigns hat sich so komplett gewandelt wie dieser. Heute ist das Skalieren von Bildern durch den Browser die normalste Sache der Welt – und heutige Browser machen das durchweg sehr gut.

Skalieren im responsiven Webdesign

Ein wichtiger Grund für Skalierung liegt im heute üblichen „responsiven“ Webdesign, also der Anpassbarkeit von Internetseiten an ganz verschiedene Bildschirmgrößen. Schon auf herkömmlichen PCs und Notebooks kann man nicht mehr in jedem Fall von fixen Größen ausgehen, weil Leute das Browserfenster nicht immer in voller Bildschirmbreite nutzen. Auf den unterschiedlich großen und unterschiedlich ausgerichteten Displays von Smartphones und Tablets ist Skalierung sowieso ein integraler Bestandteil; hier weicht die Darstellung praktisch immer von einer „pixelgenauen“ Ansicht ab.

Das Panoramabild ist lediglich als kleines Beispiel gedacht. Es ist so eingebunden, dass es auf einem großen Bildschirm die gesamte Textbreite einnimmt (die ihrerseits eine bestimmte Maximalbreite hat), sich aber auf kleineren Bildschirmen zusammen mit dem Text an die zur Verfügung stehende Breite anpasst. Wenn Sie die Seite auf einem normalen PC bzw. Notebook lesen, können Sie testweise mal das Browserfenster verschmälern, um die Anpassung live zu sehen. Ersatzweise können Sie Ihr Smartphone oder Tablet vom Hoch- ins Querformat drehen, um unterschiedliche Textbreiten zu bekommen; auch hier sollte sich die Breite des Panoramabildes entsprechend anpassen.

Monitore mit höherer Pixeldichte

Ein weiterer Grund für die Notwendigkeit von Skalierungen liegt in der hohen Pixeldichte vieler moderner Monitore, die für ausreichend große Darstellung eine dauerhafte Skalierung im Betriebssystem erfordern.
Man geht laut Standard davon aus, dass man bei einer Monitor-Pixeldichte von 96 ppi gerade noch ohne Skalierung auskommt (wobei das natürlich auch von Sehstärke und Gewohnheit des Benutzers abhängt). Diese 96 ppi wurde jedenfalls als offizieller Grenzwert definiert.
Bei allen Pixeldichten über 96 ppi (Apple nennt solche Monitore/Displays dann „Retina“, herstellerübergreifend spricht man neutral von „High-PPI“) würden die Texte und Bedienelemente ohne eine Skalierung zu klein dargestellt. Das betrifft heute schon die meisten Notebook-Displays, aber auch für größere/stationäre Monitore sind hohe Pixeldichten im Kommen.
Auch Smartphones und Tablets arbeiten intern mit Skalierungsfaktoren; die Pixeldichten dort liegen teilweise schon über 400 ppi.

Browser übernehmen für ihre Inhalte standardmäßig die Skalierung, die im Betriebssystem voreingestellt ist. Die im HTML-Code definierten Pixelgrößen („CSS-Pixel“) haben in diesem Moment nur noch virtuellen Charakter. Diese etwas seltsame Pixel-Definition, die von der Zahl der physikalischen Monitorpixel abweichen kann, mag eine Verständnishürde für Webdesign-Einsteiger sein.
Wenn im Betriebssystem z. B. der Monitor auf 150 % Skalierung gestellt ist und das Bild ist im HTML-Code mit 200 x 200 Pixeln Größe definiert, wird es in der tatsächlichen Monitorauflösung auf 300 x 300 Pixel gebracht. Die klassische pixelgenaue Darstellung gibt es in diesem Moment nicht mehr.

Ein Problem dabei: Wenn Bilder mit ursprünglich pixelgenau abgestimmmter Auflösung auf die tatsächliche Bildschirmauflösung hochskaliert werden, sehen sie natürlich nicht mehr optimal scharf aus. Sie werden zwar im Vergleich zu „normal auflösenden“ Monitoren nicht wirklich weniger scharf, aber der Betrachter orientiert sich jetzt unbewusst an der viel feineren Detailauflösung seines High-PPI-Monitors. Schon allein der Vergleich mit der (vektorbasierten) Schrift, die auf dem High-PPI-Monitor sehr fein wirkt, lässt ein hochskaliertes Bild etwas verschwommen aussehen.
Die Lösung: Wenn man die hohe Pixeldichte des Monitors und die dadurch mögliche Detailschärfe von Bildern ausreizen will, muss man als Webdesigner den Bildern heute eine gewisse „Pixelreserve“ mitgeben. Darüber, wie groß diese Reserve sein muss, kann man diskutieren. Es wäre aber gar nicht möglich, die Bilder für jede denkbare Monitorskalierung genau passend zu liefern; eine zusätzliche Live-Skalierung im Browser ist also unumgänglich. (Es kann höchstens zufällig mal dazu kommen, dass der Zoom-Faktor des Bildschirms exakt mit der Pixelreserve des Bildes übereinstimmt und dort ein Bild dann wieder pixelgenau angezeigt wird.)

Für herkömmlich aufgelöste Monitore ist eine größere Bildauflösung kein sichtbarer Nachteil, weil die heutigen Browser sehr hochwertig skalieren. Und wie wir weiter unten noch sehen werden, muss so eine Pixelreserve auch keinswegs zu riesengroßen Dateien führen.

Als guten Kompromiss, damit Bilder auf hochauflösenden Monitoren nicht zu detailarm wirken, möchte ich den Auflösungsfaktor 2 für Breite und Höhe (also insgesamt eine Vervierfachung der Pixelzahl) vorschlagen. Die genaue Halbierung beim späteren Einbinden in den HTML-Code lässt sich leicht rechnen. Man sollte lediglich bei der Erstellung der Bilder drauf achten, dass die Pixelzahl in beiden Richtungen durch 2 teilbar bleibt.
Es gibt zwar mittlerweile auch Monitore/Displays mit extrem hohen Pixeldichten, die mit Skalierungen deutlich über 200 % arbeiten müssen – aber auch auf denen erweist sich der Faktor 2 für die Bilddateien meist als ausreichend. Die Auflösung des menschlichen Auges hat schließlich auch ihre Grenzen. Extrem hohe Pixeldichten von Displays dienen eher der Homogenität (Unsichtbarkeit der Pixelstege) und nicht unbedingt einer weiteren Steigerung des Detailreichtums.

An einem Beispiel soll das demonstriert werden. Die erste Version des Bildes liegt in 400 x 300 Pixel Größe vor und wurde auch in 400 x 300 Pixel Größe im HTML-Code dieser Seite eingebunden. Die zweite Version wurde ebenfalls in 400 x 300 Pixel Größe eingebunden, aber die dahinterstehende Datei ist 800 x 600 Pixel groß.

Wenn Ihr Bildschirm keine besonders hohe Pixeldichte hat und daher in 100 % (also ohne Skalierung) betrieben wird, werden die beiden Versionen nahezu gleich aussehen – denn Ihr Browser skaliert dann die zweite Version einfach auf dieselben 400 x 300 Pixel runter, die die erste Version schon von Haus aus hat. Wenn ihr Bildschirm jedoch auf eine Skalierung >100 % eingestellt ist, werden beide Versionen entsprechend im Browser rauf- bzw. runterskaliert; dann wird die zweite Version von der Pixelreserve profitieren und somit schärfer und detailreicher erscheinen.
Falls Sie die Seite auf einem Smartphone im Hochformat lesen, sehen Sie vielleicht trotz hoher Pixeldichte nicht viel Unterschied. Sie profitieren von der Pixelreserve aber trotzdem, sobald Sie das Bild ein Stück aufzoomen. Auch schon das Drehen ins Querformat erlaubt eine etwas größere Darstellung und somit eine bessere Beurteilung der Detailschärfe.

Datenkompression

Für die Größe von Bilddateien sind eigentlich zwei Faktoren zuständig: die Auflösung in Pixeln sowie die Kompression. Beide wollen sinnvoll aufeinander abgestimmt sein. Je nach Verwendung der Bilder kann man eher an der Pixelgröße sparen oder eher auf hohe Kompressionsfaktoren setzen.

Wenn Bilder nur klein als Illustration irgendwo von Text umflossen werden, müssen sie sicherlich weniger Pixel haben als Bilder, die im Rahmen einer Galerie als formatfüllende Hauptelemente der Seite dienen. Bei der Wahl der Auflösung muss man auch ganz grundsätzlich unterscheiden zwischen Bildern, die auf der Seite einen festen Platz und eine feste Größe haben, und Bildern, die für eine Vollbilddarstellung oder zumindest Skalierung auf die komplette Bildschirmbreite gedacht sind. Während man für Erstere die Pixelgröße immer klar benennen kann (ggfs. unter Einbeziehung eines Faktors für High-PPI-Monitore), unterliegen Letztere stets nur einer groben Abschätzung der benötigten Detailgenauigkeit. Für Bilder definierter Größe kann man auch die vertretbare Kompression besser eingrenzen als für Bilder, die ggfs. auch mal sehr groß zu sehen sind (wobei dann natürlich trotzdem keine Kompressionsartefakte zu sehen sein sollten).

Dateneffizienz

Ein vorrangiger Aspekt ist die Frage der Dateneffizienz. Wenn z. B. ein Fotograf seine Bilder als Eigenwerbung möglichst groß und hochauflösend anbietet, freuen sich darüber die Besitzer großer Monitore, die zuhause am schnellen Internetzugang sitzen. Betrachter, die so eine Seite unterwegs am Handy aufrufen, werden diese großen Bilddateien eher verfluchen – denn am Handy verursachen sie längere Ladezeiten, zehren am mobilen Datenvolumen und können aufgrund der geringen Bildschirmgröße ohnehin nicht ausgereizt werden. Es gilt dann, einen tragbaren Kompromiss zu finden – oder aber den verschiedenen Anwendergruppen gezielt unterschiedliche Bildversionen zu liefern (siehe Selektives Laden von Größen und Formaten).

Kompressionsartefakte

Wie weit man mit der Kompressionsrate gehen kann, hängt nicht zuletzt vom verwendeten Dateiformat ab. Im JPEG-, WebP- und AVIF-Format bekommt man bei gleicher Dateigröße durchaus sehr unterschiedliche Bildqualität bzw. bei vergleichbarer Bildqualität sehr unterschiedliche Dateigrößen. Viele Bildbearbeitungsprogramme bieten im Speichern-Dialog einen Direktvergleich zwischen unkomprimiertem Original und aktueller Kompressionseinstellung. Damit kann man sich schön an die Grenzen herantasten, ab der Artefakte tatsächlich störend werden.
Insgesamt kann man wohl sagen, dass AVIF ein bisschen effektiver ist als WebP, das seinerseits klar effektiver als JPEG ist. Dafür dauert das Encodieren in WebP und AVIF aufgrund der Komplexität der Verfahrens auch ein bisschen länger (was natürlich nur für sehr große Stapelverarbeitungen und/oder sehr langsame Rechner relevant ist). Und eventuell braucht man für die neueren Formate immer noch Fallbacks, so dass ihre Verwendung bei einer kleinen Anzahl Bilder gar nicht immer lohnt.
In Beschreibungen wird ja gern kategorisch behauptet, Format B sei um soundsoviel Prozent effektiver als Format A. Manche Webdesigner nehmen diese Zahl dann einfach als gegeben hin und überprüfen sie nicht selbst. Aber in Wirklichkeit haben die Artefakte in JPEG, WebP und AVIF jeweils ganz eigene Chakteristiken. Das erschwert den Direktvergleich und macht es eigentlich unmöglich, eine allgemein gültige Prozentzahl zu errechnen. Dazu kommen dann noch die Einflüsse der verwendeten Software und deren Einstellungen.
Dass WebP und AVIF grundsätzlich gegenüber JPEG einen gewissen Vorteil haben, steht aber heute außer Zweifel (gute Software vorausgesetzt).

Es folgen nun zur Demonstration Varianten eines kleines Bildausschnittes, die jeweils in JPEG, WebP und AVIF mit unterschiedlichen Kompressionsraten behandelt wurden (in diesem Fall ohne Pixelreserve und in 100 % Größe eingebunden, damit man die Artefakte auf allen Monitoren gut sieht).
Um einen fairen Direktvergleich zwischen den Formaten zu bieten, gebe ich hier nicht die einstellbaren Kompressionsstufen an (die sind nicht zwischen Programmen vergleichbar), sondern habe mich an den tatsächlich erzielten Kompressionsraten orientiert und für alle Formate jeweils die nächste Näherung der entsprechenden Dateigröße eingestellt. (Bezugspunkt ist immer die unkomprimierte Größe nach der Formel „Pixelzahl x 3 Byte“.) Die Kompressionsrate gilt so natürlich nur für diesen konkreten Bildausschnitt, weil die Effektivität einer Bildkompression stets vom Bildinhalt abhängt.

Kompression ca. 1:4 – JPEG/WebP/AVIF

Kompression ca. 1:10 – JPEG/WebP/AVIF

Kompression ca. 1:20 – JPEG/WebP/AVIF

Kompression ca. 1:40 – JPEG/WebP/AVIF

Kompression ca. 1:80 – JPEG/WebP/AVIF

Die Angabe der Kompressionsraten hier dient einem leichteren Vergleich zwischen JPEG, WebP und AVIF. Außerdem kriegt man dadurch eine Vorstellung, wie leistungsfähig so eine Kompression ist. Etwa der Faktor 1:20 bedeutet, dass man gegenüber dem unkomprimierten Original bereits 95 % des Speicherplatzes und der Übertragungszeit spart. Dafür sieht selbst das JPEG, finde ich, noch erstaunlich gut aus.

Im Bildbearbeitungsprogramm stellt man natürlich nicht direkt die Kompressionsrate ein, sondern eine Qualitätsstufe. Die Qualitätsstufen der Programme nehmen sich für komplexere Bildinhalte automatisch mehr Speicherplatz (d. h. sie erzielen eine schlechtere Kompressionsrate) als für Bildinhalte mit wenigen Details. Das ist sehr praxisgerecht. So muss man nicht für jedes einzelne Bild überlegen, ob es aufgrund seines Inhalts wohl mehr oder weniger Kompression verträgt.
Mit der Zeit wird man ungefähr im Kopf haben, welche Qualitätssstufe des eigenen Bildbearbeitungsprogramms für welchen Zweck taugt bzw. ab welcher Stufe zu viele Artefakte auftreten können. Man muss dann also nicht mehr für jedes einzelne Bild die Einstellungen optimieren – was auch rationelle Stapelverarbeitungen größerer Bildermengen erlaubt.

Welcher Umfang an Artefakten störend ist, hängt natürlich von der genauen Verwendung der Bilder ab. Wenn es die besagte bildschirmfüllende Galerie ist, die evtl. auch mal auf auf die volle Breite/Höhe eines sehr großen Monitors skaliert wird, wird man jedes sichtbare Kompressionsartefakt verhindern wollen. Wenn aber das Bild nur in definierter Größe eingebunden werden soll und ein Teil der Auflösung sowieso nur Schärfe-Reserve für Monitore mit hoher Pixeldichte ist, kann man die Kompression ruhig aggressiver betreiben.

PPI-Pixelreserve durch Kompression ausgleichen?

Das folgende Beispiel zeigt dasselbe Bild zuerst konventionell in 400 x 300 Pixeln Größe und dann in 800 x 600 Pixeln Größe (aber trotzdem in die Seite eingebunden in 400 x 300, d. h. mit einem Pixelfaktor 2 in beiden Richtungen). So einen ähnlichen Vergleich hatten wir auch schon weiter oben, aber diesmal wurde die Dateigröße beider Versionen vollständig angeglichen: Zunächst wurde die JPEG-Qualität der 400er-Version gerade so eingepegelt, dass es kaum noch sichtbare Artefakte gibt – also dass man einen guten Kompromiss aus Qualität und Dateigröße kriegt. Das Bild kommt damit (inkl. sRGB-Profil) auf eine Größe von knapp über 45 kB. Anschließend wurde die Kompression der 800er-Version ohne Rücksicht auf die Bildqualität so weit hochgeschraubt, dass die Datei ebenfalls knapp über 45 kB groß ist.

Wir haben jetzt also den direkten Vergleich zwischen niedrigaufgelöster und hochaufgelöster Version bei identischer Dateigröße. Würde man beide Versionen aufzoomen, sähe man in der stark komprimierten 800er-Version natürlich viel mehr JPEG-Artefakte (Kästchenbildung an kontrastreichen Kanten etc.). Aber eingebunden in die Webseite verhält sich die Sache ganz anders: Auf einem Monitor mit normaler Pixeldichte (Bildschirmskalierung 100 %) sehen die beiden Versionen wieder nahezu gleich aus. Wer kritisch hinschaut, bemerkt vielleicht in der stark komprimierten 800er-Version ein klein wenig mehr Unsauberkeiten (besonders im gleichmäßigen Verlauf des Himmels – wie stark das auffällt, hängt auch vom Kontrastumfang des Monitors bzw. Displays ab), aber die meisten JPEG-Artefakte werden bereits durch das Herunterskalieren im Browser unsichtbar. Auf einem Monitor mit hoher Pixeldichte kann man die Artefakte noch sehen – jedoch sind die meisten dort so klein, dass sie aus normaler Betrachtungsdistanz nicht ins Gewicht fallen. Und trotz der nicht zu leugnenden Unsauberkeiten profitiert die 800er-Version ganz klar von der höheren Detailschärfe. Auflösung schlägt hier Artefaktfreiheit.

Das Beispiel soll zeigen, dass ein Verdoppeln der Auflösung in beiden Richtungen, solange es nur für Detailschärfe auf hochauflösenden Monitoren sorgen soll, nicht unbedingt zu größeren Dateien führen muss. In manchen Abhandlungen zu dem Thema wird es ja so dargestellt, als führe die vierfache Pixelzahl gleich zur vierfachen Dateigröße – was ich hiermit als widerlegt betrachte. Aufwendige Browserweichen, die je nach Bildschirmsorte unterschiedliche Bildauflösungen ausliefern (siehe Selektives Laden von Größen und Formaten), kann man sich zumindest in diesem Anwendungsszenario sparen.

Wenn man sich allzu sehr an den Artefakten stört, kann man der hochauflösenden Version z. B. 50 % mehr Dateigröße gönnen. Das wäre ein Kompromiss, der einen großen Teil der Artefakte bereits verschwinden lässt. Von einer drohenden Vervierfachung der Dateigröße ist man dann immer noch weit entfernt.
Zur Verdeutlichung hier noch der Vergleich dazu. Zunächst nochmal die bereits gezeigte 800er-Version mit gut 45 kB Dateigröße, dann zum Vergleich dasselbe mit entsprechend höher eingestellter JPEG-Qualität und knapp 68 kB Dateigröße:

Im Direktvergleich erkennt man in der ersten (45 kB) Version definitiv noch ein paar Artefakte und insbesondere die Stufen im Himmelsverlauf, die es in der zweiten Version (68 kB) kaum noch gibt. Eine noch weitere Steigerung der JPEG-Qualität hätte wohl keinen großen Effekt mehr und würde nur noch die Dateigröße aufblähen.

Kompression für glatte Grafik

Mit „glatter Grafik“ im Sinne dieses Abschnitts sind Bilder gemeint, die in einem Grafikprogramm erstellt wurden und nur wenige Farbabstufungen enthalten. Sie verhalten sich beim Komprimieren etwas anders als natürlich aufgenommene Fotos (für die das JPEG-Format eigentlich gemacht ist). Zur besseren Demonstration gibt es hier zunächst Beispiele in 100 % Auflösung, also ohne Pixelüberschuss.

PNG/JPEG/WebP/AVIF

Die JPEG-, WebP- und AVIF-Varianten wurden für diesen Vergleich jeweils auf die Dateigröße der PNG-Datei gebracht (hier ca. 13 kB inkl. sRGB-Profil). Im JPEG-Format zeigen sich bei dieser Dateigröße bereits störende Kompressionsartefakte an den Kanten der grafischen Elemente. Um diese Grafik im JPEG-Format sauber zu komprimieren, müsste die Dateigröße gegenüber dem PNG deutlich erhöht werden – und das, obwohl die Kompression im PNG verlustfrei ist und normalerweise viel platzraubender sein sollte.
WebP und AVIF kommen dem PNG-Original näher und würden notfalls noch etwas höhere Kompression vertragen, ohne dass es zu den bei JPEG sichtbaren Artefakten kommt. Wegen des schlechteren Farb-Subsamplings sind sie im Vergleich zum PNG trotzdem nicht perfekt – zu sehen z. B. an der senkrechten roten „Blutrinne“ des Schwertes. (Im AVIF-Format kann man das Farb-Subsampling eigentlich abschalten. Das von mir benutzte Programm bot diese Option aber noch nicht.)

Diese Zahlen gelten erst mal nur für die hier gezeigte Mini-Grafik und müssen auf andere Bilder nicht exakt genauso zutreffen, aber eine Tendenz bleibt erkennbar. Das JPEG-Format holt gegenüber PNG erst auf, wenn die Grafik mehr Farbtöne (z. B. Strukturen oder Verläufe) enthält und somit nicht mehr „glatt“ ist.

Wenn man dieselbe Grafik nun mit einem Pixelüberschuss von Faktor 2 anlegt, verringern sich die Nachteile von JPEG gegenüber PNG etwas (Dateigröße im Beispiel jetzt jeweils ca. 27 kB).

PNG/JPEG/WebP/AVIF

Auf einem herkömmlich auflösenden Monitor verschwinden die Unterschiede zwischen PNG und JPEG jetzt weitgehend. Auf einem High-PPI-Monitor sieht das JPEG aber immer noch nicht ganz schön aus. Die neueren Formate WebP und AVIF sind erneut klar im Vorteil. Anders als bei 100 % Auflösung oben spielt jetzt dank Pixelreserve auch das Farb-Subsampling keine sichtbare Rolle mehr.

Zusätzlich zeige ich die Grafik im Vergleich zur PNG-Datei noch als SVG-Vektorgrafik, die ja in jeder Skalierung und auf Bildschirmen jeder Pixeldichte richtig gut aussehen sollte.

PNG/SVG

Das klappt in diesem Fall tatsächlich sehr gut – und die SVG-Datei ist hier mit 20 kB sogar etwas kleiner als die PNG-Datei.

Es gibt aber auch Gegenbeispiele von Grafiken, bei denen das SVG-Rendering im Browser nicht so perfekt funktioniert, die Datei unnötig groß wird und/oder aufgrund ihrer Komplexität im Browser lange Aufbauzeiten hat. Wer SVG-Grafik einsetzen will, sollte sie also vorher in verschiedenen Browsern und auch auf verschieden schnellen Rechnern testen.

Kompression für Grafik mit Transparenz

Eine Transparenz-Ebene (technisch als Alphakanal bezeichnet) braucht man für grafische Elemente ohne eigenen Hintergrund sowie für Bilder, die auf der Webseite nicht exakt rechteckig erscheinen sollen (z. B. freigestellte Objekte). Dafür kommen das PNG-Format, das WebP-Format und das AVIF-Format in Frage (für computergenerierte Grafik evtl. auch das SVG-Format).

PNG/WebP/AVIF

Die Kompression von WebP und AVIF wurde hier so eingestellt, dass möglichst keine sichtbaren Artefakte bleiben (das ist natürlich ein subjektives Herantasten). Die Kompression von PNG ist ohnehin verlustfrei. Das führt aber auch zu einem ganz erstaunlichen Größenunterschied der Dateien: Während die PNG-Version für dieses kleine Bildchen schon satte 363 kB benötigt, kommen die WebP-Version und die AVIF-Version jeweils mit rund 40 kB aus. Sobald eine Seite mehr Bilder oder größere Bilder mit Transparenz enthält, wirkt sich das gewählte Dateiformat also ganz erheblich auf die Ladezeiten aus.

Früher hätte man für sowas vielleicht das GIF-Format benutzt, aber das kann man aufgrund seiner beschränkten Farbenzahl (die ein Banding in Farbübergängen bewirkt) und der 1-Bit-Transparenz (die keine sanften Übergänge zum transparenten Bereich erlaubt) heute nicht mehr empfehlen. Auf den ersten Blick mag man mit GIF im Vergleich zu PNG etwas Speicherplatz sparen – aber wenn man die Farbenanzahl im PNG-Format ebenfalls auf 256 reduziert, braucht man noch weniger Speicher. Auch wenn es Motive geben mag, die unter den GIF-Einschränkungen weniger leiden als andere, spricht doch sachlich betrachtet nichts mehr für GIF.

Wenn die Webseite einen einfarbigen Hintergrund hat (so wie diese hier), kann man sich die Transparenz auch sparen und einfach den umgebenden Bereich des Bildes in genau dieser Hintergrundfarbe anlegen. Dann kommt eine Speicherung in JPEG in Betracht. Es kann allerdings in manchen Browsern durch das Farbmanagement zu leichten Farbabweichungen zwischen Hintergrundfläche und Bilddatei kommen, so dass der Trick ungewollt sichtbar wird. Außerdem wäre man dann an die Hintergrundfarbe der Webseite gebunden und könnte sie nicht mehr ändern, ohne dass man gleichzeitig auch alle betroffenen Bilder ändert. Für Webseiten mit strukturiertem Hintergrund (per Hintergrundgrafik) klappt der Trick sowieso nicht. Eine Datei mit Transparenz ist also immer die flexiblere Lösung.

Kompression für Animationen

Mit GIF, WebP, AVIF und APNG stehen Bildformate zur Verfügung, die selbstablaufende Animationen (Abfolgen von Bildern) enthalten können. Während GIF mit einer Reduzierung der Farbtiefe auf maximal 256 Farben arbeitet und nur verlustfrei komprimiert, bieten WebP und AVIF die volle Farbpalette in Verbindung mit einer verlustbehafteten Kompression. Vereinfacht gesagt, kommt man mit WebP und AVIF bei gleicher Dateigröße auf eine deutlich bessere Bildqualität (besonders, wenn die Animation aus echten Fotos oder Videoframes besteht).
APNG kennt zwar die volle Farbpalette, komprimiert aber nur verlustfrei (d. h. man bekommt unnötig große Dateien). SVG eignet sich nur für Vektorgrafik-Animationen und stellt insofern einen Sonderfall dar.

Einfache GIF-Animationen (und heute vermehrt WebP-Animationen) kann man praktisch überall zeigen, wo Bilddateien eingebunden werden können – auch in manchen sozialen Netzwerken. Die manuelle Einbindung in den HTML-Code einer Webseite erfolgt wie bei einer normalen Bilddatei. Das ist verblüffend einfach.

Allerdings haben diese selbstablaufenden Animationen, die sich meist endlos wiederholen und nicht abstellen lassen, auch einen hohen Nervfaktor und lenken schnell vom eigentlichen Inhalt einer Seite ab. Sobald sie etwas umfangreicher werden, ergeben sich auch gleich sehr große Dateien, die das Download-Volumen einer Seite aufblähen. Das Problem ist, dass die Benutzer der Seite sich nicht aussuchen können, ob sie so eine große Animations-Grafikdatei herunterladen und sehen möchten.
Man sollte also sehr zurückhaltend mit der Nutzung von einfachen Animationen sein. Aus den genannten Gründen habe ich auch darauf verzichtet, hier auf dieser Seite Beispiele zu zeigen (mit Ausnahme der eingangs gezeigten, sehr dezenten Animationen zum Testen der Browserkompatibilität).

Wenn man etwas umfangreichere bewegte Inhalte zeigen will, deren Ablauf auch durch den Benutzer steuerbar sein soll, sind echte Videoformate weit besser geeignet. Web-Videos brauchen zwar trotz guter Kompression eine Menge Datenvolumen, aber man kann es dann dem Benutzer der Seite überlassen, ob (und ggfs. wann) er das Video laden möchte. Man kann Videodateien selbst hosten und als HTML5-Video einbinden oder man nutzt die Einbettungsoptionen von Videoportalen wie YouTube, Dailymotion oder Vimeo. Aber Web-Video ist ja nicht Thema dieser Seite.

Kompressions-Einstelloptionen

Eine erste Optimierung der Dateigröße erzielt man bereits durch Weglassen aller unnötigen Zusatzinformationen wie EXIF- und IPTC-Daten. Auch eingebettete Vorschaubilder haben in einer Bilddatei, die für Einbindung in eine Internetseite gedacht ist, nichts verloren. Am sichersten klappt das, wenn das Bildbearbeitungsprogramm eine spezielle Web-Export-Funktion hat; dort sind solche Details automatisch gewährleistet.

Der in der Datei angelegte PPI-Wert (oft irreführend als DPI-Wert bezeichnet) kann einfach auf Voreinstellung belassen bzw. beliebig gewählt werden. Das hat keinerlei Einfluss auf Dateigröße, Darstellungsgröße und/oder Bildqualität – weil sämtliche Browser den PPI-Wert ignorieren. Die Darstellungsgröße von Bildern auf Internetseiten orientiert sich nur an der Größe, die im HTML-Code steht – oder, wenn sie nicht explizit angegeben wird, an der Pixelgröße des Bildes.

JPEG-Kompression

Im einfachsten Fall gibt es für den JPEG-Export nur einen schlichten Qualitätsregler, der z. B. von 0 bis 100 oder oder von 1 bis 12 gehen kann. Manche Bildbearbeitungsprogramme bieten aber noch weitere Einstelloptionen, um die Dateigröße im JPEG-Format im Detail zu regulieren.

Zum Beispiel kann man zwischen verschiedenen DCT-Methoden wählen. Hier sollte man immer die langsamste Methode nehmen, die das Bild am besten analysiert und dann bei gegebener Datenrate die wenigsten Artefakte erzeugt. Den zusätzlichen Zeitaufwand für die Berechnung merkt man an modernen Rechnern ohnehin kaum noch.

Wenn die Option geboten wird, die sogenannte Huffman-Tabelle zu optimieren, sollte man das ebenfalls nutzen. Stark vereinfach gesagt geht es darum, Häufungen bestimmter Bilddetails individuell für jedes Bild zu bestimmen und nicht nach festen, allgemeinen Tabellen. Die individuelle Bestimmung verfeinert die Effizienz der Bildkompression.

Wenn man ein progressives JPEG auswählt, verbessert das zwar nicht die Dateneffizienz, aber es hat für Web-Bilder einen anderen Vorteil: Wird die Seite an einem eher langsamen Internetzugang aufgerufen, baut sich das Bild stufenweise von grob bis fein auf – also man bekommt schneller einen ersten Überblick über das Bild. Als man noch mit Modems ans Internet ging und teils minutenlang auf Bilder warten musste, war das sehr wertvoll. Heute ist die Option meist entbehrlich und wird daher nur noch selten genutzt.

Eine weitere Wahlmöglichkeit betrifft das Farb-Subsampling. Da geht es darum, ob man komplette Farbinformationen für jeden einzelnen Pixel speichert oder nur für jeden zweiten oder jeden vierten. (Das beruht auf der Erfahrung, dass das menschliche Auge die Farbtöne nicht so fein auflöst wie Kontraste.) Für Bilder, die klassisch in 100 % Pixelgröße eingebunden werden, kann sich die pixelgenaue Farbverarbeitung (die dann je nach Software "4:4:4“ oder "Beste Qualität“ heißen kann) lohnen. Für Bilder, die im Hinblick auf High-PPI-Monitore mit Pixelreserve angelegt sind, kann man auch ruhig die niedrigeren Stufen wählen; das lässt dann bei gegebener Dateigröße mehr Spielraum für andere Qualitätsaspekte und senkt z. B. die Wahrscheinlichkeit stufiger Farbübergänge.

Wenn die Software keine dieser feineren Einstellmöglichkeiten bietet, sind sie entweder automatisch aktiv (z. B. wird sowieso immer mit der besten DCT-Methode gearbeitet) oder sie sind fest in die wählbaren Stufen integriert (z. B. unterhalb einer gewissen Stufe schaltet sich automatisch auch das Farb-Subsampling herunter).

PNG-Kompression

Überraschenderweise gibt es auch für das PNG-Format – trotz verlustfreier Kompression – ein paar Einstellmöglichkeiten.

Eine dieser Einstellungen ist der Kompressionsgrad – der aber keinen Einfluss auf die Bildqualität hat, weil PNG immer verlustfrei arbeitet. Stattdessen wählt man hier, wie intensiv das Packen erfolgen soll. Das geht von unkomprimierter Speicherung bis hin zu einer sehr starken Kompression. Manche Programme bieten 10 Stufen, manche nur 3 grobe Stufen, manche lassen den Anwender gar nicht entscheiden. Für Web-Zwecke empfiehlt sich immer die höchstmögliche Kompression – auch wenn dann das Speichern etwas länger dauert.
Wieviel Platz die Kompression bestenfalls spart, hängt enorm vom Bildinhalt ab. Im Vergleich zur unkomprimierten Speicherung kann die Dateigröße eines detailreichen Fotos gerade mal 10 % kleiner werden, die Dateigröße einer einfachen glatten Grafik aber um mehr als 90 %.

Für Webbilder wird man immer ein PNG mit 8 Bit Farbtiefe pro Kanal erstellen. Falls man das Bild zuvor in 16 Bit Farbtiefe bearbeitet hat, sollte man es also vor dem Speichern auf 8 Bit reduzieren.  Die Web-Export-Funktionen der Bildbearbeitungsprogramme tun das meist automatisch. Manchmal gibt es dafür auch ein separates Kästchen zum Ankreuzen.

In der Regel werden zusätzliche Maßnahmen zur Größenoptimierung der PNG-Datei angeboten. Diese haben dann Einfluss auf die Bildqualität und sollten nur sehr vorsichtig angewendet werden. Eine dieser Möglichkeiten ist die Reduzierung der Zahl der Farbtöne; für glatte Grafiken kann das ein vertretbarer Kompromiss sein (muss man am konkreten Beispiel ausprobieren), aber für Fotos keinesfalls. Eine weitere Möglichkeit ist das Ersetzen der Transparenz durch eine feste Farbe – was natürlich absurd wäre, wenn man das PNG-Format schon eigens wegen seiner Transparenz gewählt hat.

Die Option, eine PNG-Datei „interlaced“ zu speichern, lässt sich vergleichen mit der progressiven Speicherung von JPEGs: Das Bild wird beim Laden der Webseite auf langsamen Internetzugängen in mehreren Stufen zunächst vergröbert aufgebaut, so dass der Betrachter schon früh eine Vorstellung vom Bildinhalt bekommt. Leider führt die Interlaced-Option beim PNG-Format zu insgesamt etwas größeren Dateien, weshalb man im Zweifelsfall eher darauf verzichten sollte.

WebP-Kompression

Die meisten bisher verfügbaren Exportfunktionen und Export-PlugIns packen noch alle Parameter in einen einzigen Qualitätsregler, der von 0 bis 100 reicht. Auch die Option einer verlustfreien Komprimierung ist möglich. Gelegentlich gibt es dazu eine Einstellung für den Rechenbedarf, also das Verhältnis aus Berechnungs-Zeitaufwand und Effektivität der Kompression; hier wird man als Webdesigner, der nicht in Echtzeit rendern muss, meist auf langsamere/bessere Stufen gehen.

Manchmal kann man die Komprimierung des Alphakanals (Transparenz) getrennt von den übrigen Farbkanälen regeln. Für Anwendungen, die komplexe Transparenzverläufe haben und dennoch keine hohe Genauigkeit der Transparenz brauchen, lässt sich mit dieser Einstellung etwas Dateigröße einsparen.

In besseren WebP-Encodern kann man zusätzlich diverse Verhaltensweisen der Eingangsfilter konfigurieren, die auf das Bild angewendet werden. Das dient der zielgenaueren Abstimmung des Kompressionsverfahrens auf den Bildinhalt, erfordert aber eine Einarbeitung in die genaue Wirkungsweise dieser Filter. Längerfristig wird es wohl eher Presets geben, die passende Einstellungen für z. B. Porträt, Landschaft, Strichgrafik etc. zusammenfassen. Es geht hier ohnehin nur um letzte Feinheiten, wenn man die Dateigröße knapp halten und dennoch viel Qualität rauskitzeln will.

Übrigens: Wenn man allerbeste Qualität ohne Rücksicht auf die Dateigröße will, hat WebP gegenüber JPEG sogar einen kleinen Nachteil – denn man kann in WebP im Gegensatz zu JPEG das Farb-Subsampling nicht abschalten. Für Web-Bilder, die ja ohnehin einen Qualitätskomprimiss eingehen müssen, spielt das sicherlich nur eine sehr untergeordnete Rolle.

AVIF-Kompression

Auch für AVIF gibt es bisher meist nur einen simplen Qualitätsregler – manchmal noch ergänzt durch die Option der verlustfreien Komprimierung.

Weitere Einstellmöglichkeiten, sofern vorhanden, regeln die Schwerpunkte der Kompression. Sie können, wenn man sich damit auskennt oder experimentierfreudig ist, bei knapper Dateigröße zur besseren Abstimmung auf den Bildinhalt genutzt werden (ähnlich wie die Filtereinstellungen für WebP). Man kann fürs AVIF-Format auch das Farb-Subsampling in mehreren Stufen einstellen (wie man das schon von JPEG kennt).
Im Gegensatz zu WebP kann AVIF auch höhere Farbtiefen als 8 Bit pro Kanal verwenden, nämlich 10 Bit und 12 Bit. Aber für Bilder, die in Internetseiten eingebundenen werden, ist das unnötig.

Einbinden von Bildern auf Webseiten

Wie schon eingangs erwähnt, soll das hier keine generelle Einführung in die Web-Programmierung sein. Im Webdesign gibt es zu fast jedem Detail unterschiedliche Meinungen. Was der Eine als bewährte Methode betrachtet, ist für den Anderen total veraltet und sollte in modernen Webseiten nicht mehr benutzt werden. Allein schon die Frage, welche Formatierungen man im HTML-Code machen sollte und welche über CSS, kann man lange diskutieren. Gleiches gilt für die Frage, wann man Größenangaben in Pixeln, Prozent oder em (d. h. relativ zur Textgröße) definieren soll.
Ich zeige hier lediglich ein paar einfache Möglichkeiten zum Einbinden und Formatieren von Bildern, die so funktionieren – was nicht heißt, dass es nicht auch zig andere Varianten gibt.

Formatierungen lassen sich am einfachsten auf ganz altmodische, nicht-dynamische Internetseiten anwenden, deren Quellcode man komplett selber schreibt oder zumindest mit einem flexiblen HTML-Editor erstellt. Ein großer Teil der modernen Webseiten basiert jedoch auf Content-Management-Systemen (CMSs) wie Joomla, Typo3 oder WordPress (oder einem „Homepage-Baukasten“ des Providers). Dort kann man nicht direkt auf den HTML-Code Einfluss nehmen und muss beim Einbinden von Bildern gewisse Vorgaben einhalten.
Man kann ein CMS über Anpassung der Templates und/oder Verwendung von PlugIns für fast jeden Bedarf einrichten. Wer bestimmte Optionen vermisst (Unterstützung neuerer Bildformate, Pixelreserve, Anpassung an kleine Bildschirme, Fallback-Strategien etc.) und selber keinen Zugriff auf die Administrationsebene hat, muss sich an den technischen Administrator seines CMS wenden. Aber selbst dafür ist es hilfreich, die Wünsche genau benennen und ggfs. passende Beispiele zeigen zu können.

Einbinden mit dem IMG-Element

Die absolute Standardmethode, um Bilder auf HTML-Internetseiten einzubinden, ist das sogenannte IMG-Element. Man kann es für alle Bild-Dateiformate nutzen. Das sieht im HTML-Code dann ungefähr so aus:

<img src="meinbild.jpg" height="200" width="300" alt="Meine Beschreibung">

Das wichtigste Attribut ist natürlich src, womit die Bilddatei verlinkt wird. Es kann sich um einen bloßen Dateinamen, um einen relativen Pfad (z. B. bilderordner/meinbild.jpg) oder um eine vollständige Adresse (z. B. https://meinedomain.de/bilderordner/meinbild.jpg) handeln.

Das Attribut alt definiert einen Text, der angezeigt wird, wenn das Bild aus irgendeinem Grund nicht geladen werden kann. Früher hat man das oft als primitiven Fallback-Ersatz für neue Formate genutzt („Ihr Browser kann das XYZ-Format leider nicht anzeigen.“). Heute nimmt man es nur noch für den barrierefreien Zugang: Man kann hier eine Beschreibung für Sehbehinderte unterbringen, die das Bild nicht oder nur schlecht sehen können. Zur Not kann man alt jedoch auch weglassen (was offiziell nicht empfohlen wird – aber die Browser melden deswegen auch keinen Fehler).

Die Attribute height und width definieren die Größe des Bildes in Pixeln. Diese Angaben sind optional (und werden von manchen Webdesignern sogar als völlig veraltet betrachtet), aber aus zwei Gründen zu empfehlen: Erstens bewirken sie ein sofortiges Freihalten des Platzes und verhindern, dass die Seite nach dem Laden des tatsächlichen Bildes nochmal „springt“ (was für Leser sehr nervig sein kann). Zweitens bieten sie eine simple Möglichkeit, das Bild mit Pixelreserve für High-PPI-Monitore einzubinden (indem man der Bildatei mehr Pixel gibt als die definierte Pixelgröße im IMG-Element).

Es gibt für IMG noch mehr mögliche Attribute, die in bestimmten Situationen nützlich sein können. Unter SelfHTML gibt es die komplette Liste.

Format-Fallbacks

Auch jüngere Formate wie WebP, AVIF oder SVG lassen sich direkt per IMG-Element einbinden. Allerdings werden sie dann in älteren Browsern, die diese Formate noch nicht kennen, nicht gezeigt. Man braucht also ein Möglichkeit, in solchen Fällen das Bild in einem alternativen Format zu laden (auch wenn dieses dann Nachteile hat wie schlechtere Bildqualität, fehlende Transparenz und/oder größeren Speicherbedarf).

Fallback-Strategien

Bevor man sich für die Verwendung eines Dateiformat-Fallbacks entschließt, sollte man natürlich wissen, warum man das tut – und ob es sich lohnt. Wenn man es einfach nur als Selbstzweck und aus Lust am Experimentieren macht, ist das ja ganz nett. Aber die meisten Webdesigner werden sich so eine zusätzliche Arbeit nur aufhalsen, wenn es in der Praxis etwas bringt.

Meist geht es bei der Verwendung neuerer Bildformate darum, Speicherplatz bzw. Übertragungsvolumen zu sparen. Das macht man aus Rücksicht auf Leute, die langsame Internetzugänge haben und/oder mit begrenztem Übertragungsvolumen auskommen müssen (besonders im mobilen Internet). Für normale Bilder kann man das natürlich auch erreichen, indem man nur die JPEG-Kompression bis zur Schmerzgrenze hochschraubt. Eine Lösung mit neuerem Format und Fallback lohnt also erst, wenn man auch noch die Bildqualität im Blick hat und hier den bestmöglichen Kompromiss sucht.
Für Seiten mit ungewöhnlich großflächigen und/oder extrem vielen Bildern lohnt so ein Aufwand früher als für Seiten mit gerade mal fünf Mini-Bildchen. Für Bilder mit Transparenz lohnt es schon wesentlich früher, weil man dann die platzfressenden PNGs vermeidet.

Geht es um Transparenz, kann man sich auch noch überlegen, was hierfür eine angemessene Fallback-Strategie ist. Damit die Seite in älteren Browsern exakt gleich aussieht, bleibt praktisch nur das PNG-Format. Man könnte aber auch sagen: Das perfekte Webdesign ist auf alten Browsern nicht so wichtig. Hauptsache, die Dateigrößen bleiben überschaubar und das Bild irgendwie sichtbar. Dann könnte man auch die Transparenz durch eine neutrale Hintergrundfarbe ersetzen und JPEG als Fallback verwenden.

Für die Entscheidung spielt sicherlich die Frage eine Rolle, wieviele Leute überhaupt noch auf die Fallbacks angewiesen sind.
WebP wird schon seit Jahren von allen aktuellen Browsern angezeigt. Laut den einschlägigen Statistik-Seiten greifen noch etwa drei Prozent der Nutzer mit älteren Browsern aufs Internet zu, die kein WebP können (z. B. mit Apple Safari vor Version 14, mit sehr frühen Android-Browsern oder mit dem Internet Explorer).
AVIF funktioniert inzwischen ebenfalls in sämtlichen aktuellen Browsern, aber der Bestand an nicht mit AVIF kompatiblen Bestandsbrowsern ist mit 7 % noch etwas höher.
Die SVG-Unterstützung umfasst bereits nahezu alle Bestandsbrowser. Nur stark veraltete Browser wie der Internet Explorer vor Version 9, die heute nur noch im Pomille-Bereich zu finden sein dürften, können SVG noch nicht anzeigen.

Man könnte auf die „pädagogische“ Idee kommen, per Fallback-Einblendung oder Alt-Text die Nutzer alter Browser auf die Defizite aufmerksam zu machen und sie zur Installation eines neueren Browsers aufzufordern. In der Praxis klappt das aber kaum, weil es gerade die technisch wenig erfahrenen Nutzer betrifft. Sie installieren dann also keinen neuen Browser, sondern klicken einfach nur verärgert weg.

Serverbasierte Fallbacks

Es gibt für Fallbacks komplexe Lösungen, die oft mit Scripts direkt auf dem Server arbeiten. So kann z. B. der verwendete Browser abgefragt und bei Bedarf die Dateiendung der angeforderten Bilddatei automatisch geändert werden. Man muss dann nur noch dafür sorgen, dass jede Bilddatei auch namensgleich im alternativen Format bereitsteht. Oder man kann die Sache sogar noch weiter automatisieren und die nötigen Fallback-Formate dynamisch auf dem Server erzeugen lassen; so spart man sich das Hochladen des zweiten Formates (wenn auch auf Kosten der Qualität, weil die Bilder dann nacheinander zweimal komprimiert werden).
Dass solche Lösungen für den Gelegenheits-Webdesigner nicht so einfach umzusetzen sind, versteht sich von selbst. Die Beschäftigung damit lohnt sich daher nur, wenn es eine wirklich große Zahl von Bildern betrifft.
Für gängige Content-Management-Systeme gibt es fertige PlugIns, die die Einrichtung des automatischen Bilder-Fallbacks etwas vereinfachen können.

HTML-Fallback

An dieser Stelle möchte ich noch eine wesentlich einfachere Methode zeigen, die sich für „handgemachte“ Seiten eignet, in denen nur eine begrenzte Zahl von Bildern ein Fallback erfordert. Diese Lösung wird direkt im HTML-Code eingebaut und benötigt noch nicht mal PHP oder Javascript.
Man verwendet dazu das PICTURE-Element, das ein IMG-Element umschließt und ihm zusätzliche Bildvarianten zuweist. Dafür, wann diese Varianten genutzt werden sollen, kann man allerlei Bedingungen formulieren – was für ein simples Format-Fallback aber gar nicht nötig ist. Da genügt es, das Fallback-Format ins IMG-Element einzubauen und ergänzend ein weiteres Format zu definieren, das weiter oben in der Liste steht.

Zum Beispiel eine Fallback-Abfolge für AVIF, WebP und JPEG kann dann so aussehen:

<picture>
<source srcset="meinbild.avif" type="image/avif">
<source srcset="meinbild.webp" type="image/webp">
<img src="meinbild.jpg" height="200" width="300" alt="Meine Bildbeschreibung">
</picture>

Grundlage ist immer das IMG-Element, das im PICTURE-Element eingeschlossen ist (hier die vorletzte Zeile). Über vorangestellte source-Einträge werden dafür zusätzliche Quellen-Varianten definiert. Der Browser würde im obigen Beispiel also bevorzugt das AVIF-Format verwenden. Kennt der Browser das nicht, nimmt er das nächste Format in der Liste – hier das WebP-Bild. Kennt der Browser auch WebP nicht, greift er auf den Eintrag zurück, der tatsächlich unter src im IMG-Element steht – hier die JPEG-Version. 

Besonders genial am PICTURE-Element ist, dass es verträglich mit älteren Browsern ist, die PICTURE noch gar nicht verarbeiten können. Die ignorieren dann einfach das ganze ihnen unbekannte Drumherum und verwerten nur das IMG-Element. Auch so kommt das (unterste) Fallback-Format zur Anwendung.
Die Browser sind (hoffentlich) auch klug genug, beim Server jeweils nur die benötigte Bilddatei anzufordern. So ist gewährleistet, dass man wirklich Übertragungsvolumen spart und es nicht etwa durch unnötige Mehrfachdownloads vergrößert.

Es mag gelegentlich noch Browser geben, die das Fallback-Bild aus dem IMG-Element in jedem Fall mit runterladen – auch wenn sie eigentlich eines der neueren Formate nutzen, die weiter vorn in der Liste stehen. Das ist natürlich nicht Sinn der Sache. Man kann den entstehenden Nachteil nur etwas abmildern, indem man das Fallback-Bild möglichst kompakt hält. Zum Beispiel kann man es in einfacher Auflösung anlegen (ohne Pixelreserve für High-PPI-Monitore), auf Transparenz verzichten (immer JPEG statt PNG benutzen) und zusätzlich die JPEG-Kompression sehr weit hochschrauben. Es geht ja beim Fallback in erster Linie darum, dass die Benutzer sehr alter Browser überhaupt noch ein Bild sehen können. Bei ihnen handelt es sich mutmaßlich nicht um sehr anspruchsvolle Nutzer und ihr Anteil wird mit jedem Jahr geringer, so dass man auf sie immer weniger Rücksicht nehmen muss.

Falls APNG-Bilder per PICTURE-Element mit einem Fallback versehen werden sollen, ist es wichtig, dass sie tatsächlich die Dateiendung APNG tragen. Nur dann werden sie von älteren Browsern wunschgemäß ignoriert, so dass das Fallback greifen kann. Würde man die Dateiendung PNG benutzen, könnte der Browser sie von statischem PNG nicht unterscheiden und würde sie auf jeden Fall anzeigen – auch wenn man dann vielleicht nur ein Standbild sieht.
Umgekehrt kann man diese Eigenschaft natürlich auch für Anwendungen nutzen, wo das Standbild als Fallback bereits ausreicht. Dann kann man der APNG-Datei die Endung PNG geben und sie direkt als IMG-Element (also ohne PICTURE drumherum) verwenden.

Für WebP, AVIF und APNG funktioniert das Fallback mit PICTURE bestens. Nur mit dem SVG-Format bekommt man ein kurioses Problem: Es gibt ältere Browser, die bereits SVG-Grafiken darstellen können, aber das PICTURE-Element noch nicht kennen. Eine Lösung wie oben gezeigt würde dazu führen, dass dann trotz SVG-Fähigkeit gleich das Fallback angezeigt würde. Ist nicht schlimm, aber auch nicht Sinn der Sache.
Ich würde empfehlen, ganz auf das Fallback zu verzichten. Benutzer, deren Browser noch keine SVG-Bilder darstellen können, sind wirklich extrem selten geworden.

Eine kleine Fehlermöglichkeit bei Verwendung des Elements PICTURE ist die notwendige Angabe des sogenannten Mime-Typs für das jeweilige Bildformat. In manchen Browsern funktioniert PICTURE sogar ohne diese Angabe, aber andere Browser machen dann Probleme und können das Format nicht anzeigen. Man geht also auf Nummer sicher, wenn man den Mime-Typ auch für bekanntere Formate stets korrekt angibt.
Der Mime-Typ lautet "image/jpeg" für JPEG-Bilder, "image/gif" für GIF-Bilder, "image/png" für PNG-Bilder, "image/svg+xml" für SVG-Dateien, "image/webp" für WebP-Bilder, "image/avif" für AVIF-Bilder sowie "image/apng" für animierte PNG-Bilder.
Wenn ganz neue Bildformate auf den Markt kommen, findet man deren Mime-Typen noch gar nicht in den einschlägigen Tabellen. Aber meist entspricht der Teil hinter dem Schrägstrich einfach der Dateiendung. Muss man im Zweifelsfall einfach ausprobieren (sobald es einen Browser gibt, der das Format unterstützt).

Selektives Laden nach speziellen Kriterien

In den obigen Beschreibungen zum Fallback überlässt man die Auswahl des Bildformates komplett dem Browser und dessen Fähigkeiten. Je nach Ausgestaltung des Webdesigns kann es aber auch gewünscht sein, ein Bild nach vorher festgelegten Kriterien zu laden. Dabei muss es sich nicht immer um unterschiedliche Dateiformate handeln, sondern man kann auch z. B. mehrere JPEGs desselben Motivs in unterschiedlichen Pixelgrößen und/oder mit unterschiedlichen Inhalten liefern.

Anwendungsfälle

Ein gängiges Kriterium ist die Breites des sogenannten Viewports. Man kann Grenzen definieren, ab welcher Viewport-Breite z. B. eine höher aufgelöste Bildversion genutzt werden soll.

Unter Viewportbreite versteht man im einfachsten Fall die Breite des Bildschirms bzw. des Browserfensters in Pixeln. Für High-PPI-Monitore wird allerdings nicht die tatsächliche Auflösung herangezogen, sondern die Größe in sogenannten CSS-Pixeln. Das ist eine virtuelle Pixelzahl, die die Bildschirmskalierung sozusagen rausrechnet. Praktisches Beispiel: Ein 24″-UHD-Monitor hat eine Auflösung von 3840 Pixeln in der Breite und im Betriebssystem sind dafür 200 % Skalierung eingestellt. Die Viewport-Breite wird dann für einen bildschirmfüllenden Browser mit 1920 px angegeben. Oder sollte der Benutzer das Browserfenster z. B. nur auf 2000 Monitorpixel Breite aufgezogen haben, ist die Viewport-Breite unter Berücksichtigung der 200prozentigen Skalierung eben 1000 px groß.
Bei Mobilgeräten ist der Viewport nicht immer ganz so klar zu errechnen wie bei Notebook-Displays und externen Monitoren (iOS und Android haben in Sachen Skalierung gewisse Eigenheiten), aber grundsätzlich arbeiten auch sie mit der Viewport-Definition.

Ein anderes mögliches Kriterium wäre die Pixeldichte des Monitors, die der Browser ebenfalls berücksichtigen kann. Man könnte dann z. B. ab einer Pixeldichte von 100 ppi automatisch eine höher auflösende Bildversion laden und bei niedrigerer Pixeldichte die normal aufgelöste Version belassen (auch wenn so eine Unterscheidung nur in Spezialfällen sinnvoll ist – wir haben ja oben gesehen, dass man die Dateigrößen auch per Kompression schön niedrig halten kann).

Darüber hinaus gibt es noch einige weitere Kriterien, die man für das Laden unterschiedlicher Bildversionen heranziehen kann. Dazu gehört etwa die Höhe (statt Breite) des Viewports, die Orientierungen Hochformat/Querformat oder das Seitenverhältnis des Bildschirms.

Selektives Laden in HTML

Auch zu diesem Zweck gibt es natürlich serverbasierte Lösungen sowie PlugIns für Content-Management-Systeme. Ich will aber auch diesmal nur eine einfache, HTML-basierte Variante zeigen.

Damit gerade Smartphones und kleine Tablets die Inhalte nicht sinnlos verkleinert darstellen, muss zunächst der Viewport per Meta-Tag eindeutig definiert sein. Hierzu fügt man auf jeder Seite in den Headbereich (d. h. noch vor </head>) folgende Zeile ein:

<meta name="viewport" content="width=device-width">

Die häufigste Anwendung ist also das Laden unterschiedlich großer Bildversionen je nach Breite des Viewports. Dafür kann man auch wieder das PICTURE-Element benutzen.

<picture>
<source media="(min-width: 950px)" srcset="meinbild-gross.jpg" type="image/jpeg" height="600" width="900">
<source media="(min-width: 650px)" srcset="meinbild-mittel.jpg" type="image/jpeg"  height="400" width="600">
<img src="meinbild-klein.jpg" height="200" width="300" alt="Meine Bildbeschreibung">
</picture>

Hier würde der Browser zuerst prüfen, ob der Viewport mindestens 950 Pixel breit ist. Wenn ja, würde er die Datei meinbild-gross.jpg laden und in 600 x 900 Pixel Größe darstellen.
Falls der Viewport schmäler als 950 aber mindestens 650 Pixel breit ist, würde der Browser die Datei meinbild-mittel.jpg laden und in 400 x 600 Pixeln Größe darstellen.
Sollte der Viewport kleiner als 650 Pixel breit sein (oder der Browser so alt sein, dass er PICTURE nicht versteht), wird auf jeden Fall meinbild-klein.jpg geladen und in 200 x 300 Pixeln Größe dargestellt.

Die Zahlen aus dem Beispiel ergeben so jetzt nicht unbedingt viel Sinn. Es geht hier nur darum, die grundsätzliche Syntax zu zeigen. Ob und wann man so eine Konstruktion wählt, muss individuell entschieden werden.
Ich möchte sogar davon abraten, für mobile Geräte (schmale Viewports) generell kleinere Bilddateien einzubinden. Herunterskaliert auf Handy-Breite sind die Bilder zwar klein und kämen mit weniger Pixeln aus, aber Handynutzer zoomen Bilder auch gern mal auf. Dann sind sie dankbar für etwas mehr Pixelreserve – solange die Dateigrößen nicht ins Uferlose gehen.
Das Laden unterschiedlicher Pixelgrößen ist in der Praxis eher sinnvoll im Hinblick auf sehr große Viewports. So kann man den (wenigen) Besitzern großer Monitore hochauflösende Bildversionen zukommen lassen, ohne für die übrigen Nutzer das Datenvolumen in die Höhe zu treiben.

Man kann, wie erwähnt, auch in Abhängigkeit von der Pixeldichte des Monitors unterschiedliche Bilder laden. Das lohnt sich zwar nicht für kleinere Bilder, aber kann z. B. für sehr große, auf volle Bildschirmbreite gezoomte Panoramen interessant werden. Man kann es sogar noch mit der Viewport-Breite (siehe oben) kombinieren, damit eine extragroße Bilddatei wirklich nur auf sehr großen und gleichzeitig hochauflösenden Monitoren zum Einsatz kommt.

<picture>
<source media="(min-resolution: 100dpi) and (min-width: 1600px)" srcset="meinpanorama-hoch.jpg" type="image/jpeg">
<img src="meinpanorama-normal.jpg" style="width: 100%" alt="Meine Panoramabeschreibung">
</picture>

Der Browser prüft hier, ob der Monitor mindestens 100 ppi (hier in HTML leider fälschlich dpi genannt) Auflösung hat und gleichzeitig der Browser eine Viewport-Breite von mindestens 1600 Pixeln vorweisen kann. Nur dann lädt er die hochaufgelöste Version meinpanorama-hoch.jpg. In allen anderen Fällen kommt er auf die normal aufgelöste Version meinpanorama-normal.jpg im IMG-Element zurück. Die Bildbreite ist hier übrigens bewusst nicht in Pixeln definiert, sondern als 100 % (denn das Panorama soll ja quer über das Browserfenster reichen).

Jetzt noch ein kleines Beispiel, um abhängig vom Seitenverhältnis des Bildschirms bzw. Browserfensters unterschiedliche Bilder zu laden. Das ist z. B. nützlich, wenn man Leuten, die ihr Handy im Hochformat halten, ein etwas anderes (speziell vom Ausschnitt her angepasstes) Bild zeigen will. Um möglichst zu verhindern, dass die Regel dann auch für hochformatig hingezogene Browserfenster auf großen Monitoren gilt, kann man sie zusätzlich auf handytypische Viewportbreiten einschränken:

<picture>
<source media="(orientation: portrait) and (max-width: 450px)" srcset="meinbild-hoch.jpg" type="image/jpeg" height="300" width="200">
<img src="meinbild-quer.jpg" height="200" width="300" alt="Meine Bildbeschreibung">
</picture>

In diesem Fall wird durch das Medienmerkmal 'orientation: portait' (Hochformat) in Verbindung mit einer maximalen Viewportbreite von 450 Pixeln die spezielle Hochformat-Bilddatei meinbild-hoch.jpg definiert – und dieser auch eine eigene Pixelgröße für Höhe und Breite zugewiesen. Für Situationen, wo dies nicht zutrifft (d. h. alle Querformat-Bildschirme sowie Hochformat-Browserfenster über 450 Pixel Viewportbreite), wird über das IMG-Element die Querformat-Version meinbild-quer.jpg geladen und ihr auch die passende Querformat-Pixelgröße zugewiesen. Ältere Browser, die kein PICTURE verstehen, zeigen immer das Querformat.

Strategien für kleine Bildschirme

Das responsive Webdesign, also die Anpassung von Internetseiten an unterschiedlichste Bildschirmgrößen, betrifft alle Arten von Inhalten gleichermaßen. Das Passendmachen von Bildern allein hilft nichts, wenn sich nicht auch Textboxen, Menüleisten etc. mit allen Displaygrößen vertragen. Für eine gründlichere Beschäftigung empfehle ich das Tutorial auf SelfHTML. An dieser Stelle folgen nur Überlegungen und erste Hinweise, wie man dabei speziell mit den Bildern umgehen kann.

Automatisches Skalieren von Bildern

Es gibt verschiedene Möglichkeiten, wann und wie Bilder skaliert werden sollen. Eine speziellere Variante, nämlich das Skalieren eines Panoramas quer über das gesamte Browserfenster, wurde ja oben schon gezeigt. Manche Webdesigner sind sogar der Ansicht, im Responsive Webdesign sollten generell nur relative Werte benutzt werden (z. B. indem man Bildgrößen auf Prozent der Seitenbreite skaliert). Man kann aber auch absolute Maximalgrößen festlegen, die nicht überschritten werden sollen. Solange das Bild auf einem größeren Monitor im Text eingebettet wird (evtl. auch vom Text umflossen), hat es eine definierte Größe. Erst wenn der Viewport zu schmal für diese Darstellung wird, wird das Bild passend herunterskaliert. (Macht man gar nichts, behält jedes Bild eine komplett starre Größe. Auf schmalen Bildschirmen wird dann der überstehende Teil einfach abgeschnitten. Das ist nur selten erwünscht.) 

Wenn Bilder relativ flach und breit sind (z. B. Panoramen wie das oben gezeigte), kann man darüber streiten, ob eine Skalierung auf die Bildschirmbreite von Handys noch sinnvoll ist – schließlich kann man in so einem schmalen Bildstreifen kaum noch etwas erkennen. Aber Handynutzer kommen auch in solchen Fällen schnell auf die Idee, das Bild aufzuzoomen. Die „versteckte“ Auflösung dient also auch hier wieder als sinnvolle Pixelreserve.

Bevorzugt löst man das nicht mit einem Style-Element direkt im HTML-Code, sondern in der verknüpften CSS-Datei. Dort kann man die Formatierung einmal anlegen und dann auf viele Bilder anwenden. Im einfachsten Fall macht man es gleich als Elementstil für alle Bilder:

img {
max-width: 100%;
height: auto;
}

Die Prozentangabe unter 'max-width' bezieht sich hier auf die Pixelbreite, die man separat für jedes Bild im IMG-Element des HTML-Codes angegeben hat. Das Bild wird also nach Möglichkeit so groß dargestellt wie in HTML definiert. Nur dort, wo der Bildschirm zu schmal wird, geht der Browser auf Werte unter 100 % runter. Falls Text um das Bild herumfließt (was man ggfs. in CSS mit 'float' einstellt), würde bei sinkender Viewportbreite zunächst der Text neben dem Bild in eine immer schmälere Spalte gepresst. Das Bild bliebe noch gleich groß.

Statt als Elementstil kann man das Ganze natürlich auch als Klassenstil anlegen, den man den zu skalierenden Bildern einzeln zuweist.
Man kann in der CSS-Datei auch sogenannte Media Queries anlegen, die Bilder je nach Viewportbreite unterschiedlich behandeln (z. B. bei schmäleren Bildschirmen auf den Textumlauf verzichten). Das funktioniert ganz ähnlich wie mit den oben gezeigten Kriterien im PICTURE-Element.

Anordnung der Bilder

Gibt es mehrere Bilder neben- oder übereinander, hätte man sie früher starr angeordnet – vielleicht gar mit Hilfe einer HTML-Tabelle. Das verträgt sich natürlich gar nicht gut mit einer fließenden Anpassung. Man könnte zwar die Tabelle per CSS so formatieren, dass sie sich an die Breite kleinerer Bildschirme anpasst, aber dann können die einzelnen Bilder schon arg klein werden. Zweckdienlich ist das allenfalls für "echte“ Tabellen – also wenn die Bilder tatsächlich inhaltlich in zwei Achsen sortiert sein müssen. Dann könnte man davon ausgehen, dass interessierte Betrachter die Bilder bei Bedarf entsprechend aufzoomen.

Wer Formatierungen heute bevorzugt in CSS-Klassenstile verlagert, findet damit eine Menge Optionen zum Anordnen von Bildern – gern auch gestaffelt nach Viewportbreiten mit Hilfe von Media Queries.

Ist die Form der Anordnung nur eine optische Frage und muss nicht zwingend auf allen Bildschirmgrößen gleich sein, kann man sie auch ein Stück weit dem Browser überlassen. Die allereinfachste Variante wäre, sie innerhalb eines Absatzes hintereinander zu platzieren. Dazwischen kann man jeweils ein Leerzeichen setzen, wenn die Bilder nicht direkt zusammenkleben sollen.

<p>
<img src="meinbild-1.jpg" height="200" width="300" alt="Meine erste Bildbeschreibung">
<img src="meinbild-2.jpg" height="200" width="300" alt="Meine zweite Bildbeschreibung">
</p>

Das ist primitiv, funktioniert für zweckorientierte Seiten aber erstaunlich gut. Man muss nicht immer tief in die CSS-Trickkiste greifen. Statt mit einfachen IMG-Elementen kann man dasselbe übrigens auch mit ganzen PICTURE-Elementen machen.
Die Anordnung erfolgt hier nach einer simplen Regel: Solange die Bilder des Absatzes in voller definierter Größe in eine Zeile passen, stehen sie nebeneinander. Wird der Viewport zu eng, schlüpfen sie übereinander. Die Anordnung hat dabei Vorrang vor einer eventuellen Skalierung; skaliert wird erst, wenn das einzelne Bild bereits zu breit für den Viewport ist.

Farbmanagement für Web-Bilder

Es wäre so schön, wenn wir im Internet jedezeit exakte Farben sehen könnten – also wenn ein Bild bei jedem Nutzer farblich genauso rauskäme wie beim Ersteller des Bildes. Fotokünstler könnten sich darauf verlassen, dass Betrachter die Farben so sehen wie von ihnen beabsichtigt. Onlinehändler könnten realistische Materialmuster zeigen und müssten nicht eigens davor warnen, dass Farben am Bildschirm von der Realität abweichen können. Technisch wäre das längst möglich. Praktisch klappt es jedoch nicht.

Gesenkte Erwartungen

Bemühungen um planbare Farbwiedergabe im Internet sind nach wie vor eine ziemlich undankbare Sache. Zwar beherrschen zumindest die Browser heute zum größten Teil echtes ICC-Farbmanagement, aber das ist ja nur die halbe Miete. Die Grundvoraussetzung, damit die Farben im Rahmen des Farbmanagements wirklich „stimmen“ können, ist eine messtechnische Kalibrierung und Profilierung der Monitore – und die fehlt bei geschätzten 99 % aller Nutzer. Eine Ausnahme mag sein, wenn man eine Webseite speziell für Fotografen oder Grafiker betreibt, die mit dem Thema vertraut sind. Aber 100 % ist die Quote der kalibrierten/profilierten Monitore auch hier nicht – vermutlich nicht mal 50 %.

Der Großteil aller für Internetzugang verwendeten Monitore ist also nicht individuell vermessen und hat daher eine aus Sicht des Browsers unbekannte Farbwiedergabe. Mit viel Glück ist vielleicht ein generisches Monitorprofil des Herstellers installiert oder der Monitor ist auf sRGB „werkskalibriert“. Unter macOS gibt es immerhin die Möglichkeit, ein Profil aus den Farbdaten des Monitors zu generieren. Aber das erfasst die farblichen Eigenschaften des Monitorexemplars natürlich nur grob.

Unter Windows ist, solange der Anwender es nicht von sich aus ändert, das einfache sRGB-Profil als Default-Monitorprofil eingestellt. Und tatsächlich ist die Farbwiedergabe vieler heutiger Monitore „irgendwie im weitesten Sinne an sRGB angelehnt“. Aber manche treffen sRGB besser, manche schlechter. Ohne individuelle Messung wird man es nie sicher wissen. Der Nutzer gewöhnt sich an die Farben seines eigenen Monitors und hinterfragt sie bald nicht mehr – es sei denn, er hat mehrere Geräte direkt nebeneinander und bemerkt die Unterschiede.
Es gibt auch sogenannte Wide-Gamut-Monitore, die von vornherein einen viel größeren Farbraum als sRGB haben und daher noch dringender ein passendes Monitorprofil brauchen. Werden sie mit sRGB als Monitorprofil betrieben, zeigen sie Farben viel zu stark gesättig an – was der Laie vielleicht sogar auf den ersten Blick gut findet. Nur mit Farbgenauigkeit hat das dann nichts zu tun.

Auf mobilen Geräten sieht es nicht besser aus. Mit jüngeren Versionen von iOS und Android wurde immerhin ein vereinfachtes, auf sRGB basiertes Farbmanagement eingeführt. Doch mehr als ein „grob an sRGB orientiertes“ Display und ein Browser, der alles auf sRGB umrechnet, ist das letztlich auch nicht. Immerhin ist es schon eine kleine Verbesserung zu vorher, als sich Mobilgeräte überhaupt noch nicht um Farbgenauigkeit bemühten.

Zusammenfassend kann man sagen: Auf den allermeisten Monitoren und Displays, auf denen Internetseiten betrachtet werden, ist die Farbwiedergabe ein Stück weit oder komplett Zufall. Als Webseiten-Ersteller haben wir darauf keinen Einfluss – so wünschenswert das auch wäre. Es gibt auch keinen genialen Trick, der das Problem irgendwie lösen könnte. Zeitweise hatte sich die Vorstellung verbreitet, mit Bildern im sRGB-Farbraum könne man auf wundersame Weise das Farbmanagement umgehen und auf allen Monitoren immer korrekte Farben sehen. Wenn man sich ein bisschen mit Farbmanagement beschäftigt, wird jedoch schnell klar: Das ist rein physikalisch gar nicht möglich. Denn wenn der Monitorfarbraum von sRGB abweicht und der Browser diesen abweichenden Farbraum nicht genau kennt, kann er die Farben nicht passend umrechnen. Wenn es anders ginge, wäre ein kompliziertes Umrechnungssystem wie das ICC-Farbmanagement nie erfunden worden.

Lohnt sich Web-Farbmanagement?

Vor dem Hintergrund dieser ernüchternden Bestandsaufnahme hat man als Webdesigner nicht unbedingt Lust, noch irgendeinen Beitrag zur Farbgenauigkeit zu leisten. Wenn die Farbwiedergabe eh nicht planbar ist, kann man sie auch gleich dem Zufall überlassen. Wenn jemand sich bisher nicht speziell mit Medientechnik befasst und noch nie etwas mit Farbmanagement zu tun hatte, mag es in der Tat nicht lohnen, dies ausgerechnet für die Erstellung von Bildern auf Internetseiten nachzuholen. Für „allgemeine“ Bilder auf „allgemeinen“ Seiten ist Farbgenauigkeit wahrscheinlich der unwichtigste Aspekt. Da investiert man seine Zeit lieber in Verbesserung der HTML- und CSS-Kentnisse (oder was man sonst noch braucht, um die eigenen Internetseiten am Laufen zu halten).

Ist man mit Farbmanagement bereits vertraut und betreibt man Webseiten, die im weitesten Sinne mit Fotografie oder Drucktechnik zu tun haben (so dass auch auf Leserseite bereits ein Grundverständnis für das Thema besteht), sieht es anders aus. Dann ist es durchaus zu empfehlen, den Farbraum seiner Bilder bewusst zu wählen und auf das Einbetten des passenden Profils zu achten. Es besteht dann zumindest die Chance, dass ein gewisser Teil der Nutzer es zu schätzen weiß.

Wenn man beim Aufnehmen und Bearbeiten der Bilder ohnehin schon mit farbmanagementfähiger Software arbeitet, ist der Mehraufwand für den korrekten Export denkbar gering. Insofern hat man nichts zu verlieren, wenn man es gleich richtig macht.

Web-Bilder für Farbmanagement fit machen

Auch wenn die Verwendung des sRGB-Farbraums allein noch keine korrekten Farben garantiert, ist doch sRGB für Bilder im Internet nach wie vor eine gute Wahl. Es gibt nach wie vor viele Monitore, deren Farbraum sich zumindest grob an sRGB annähert. Dann erhöhen sRGB-Bilder auch in älteren Browsern, die noch kein Farbmanagement können, die Wahrscheinlichkeit einer halbwegs passenden Darstellung. Hat man die Bilder in einem anderen/größeren Farbraum als sRGB bearbeitet, sollte man sie beim Export also nach sRGB konvertieren. Arbeitet man sowieso in sRGB, entfällt dieser Schritt.

Fürs Monitor-Farbmanagement braucht man immer zwei Profile: das Arbeitsfarbraum-Profil der Bilddatei sowie ein möglichst genau passendes Monitorprofil. Darauf, ob Letzteres beim Betrachter der Webseite vorhanden ist, haben wir ja leider keinen Einfluss. Aber wir können unseren Teil tun und dafür sorgen, dass schon mal das Arbeitsfarbraum-Profil (also in den meisten Fällen das sRGB-Profil) eingebettet wird.
Eigentlich sollten farbmanagementfähige Browser so voreingestellt sein, dass sie profillose Bilder automatisch als sRGB interpretieren – wodurch ein Einbetten des sRGB-Profils überflüssig wird. Aber leider gibt es immer noch einzelne Browser, die Bilder ohne eingebettetes Profil ganz vom Farbmanagement ausnehmen. Deswegen ist die Einbettung des sRGB-Profils unbedingt zu empfehlen. Die Web-Export-Funktionen der Bildbearbeitungsprogramme tun das meist schon von sich aus. (Da das einfache sRGB-Profil gerade mal 3 kB groß ist, erhöht es nicht spürbar die Dateigröße.)

Die Nutzung von sRGB fürs Web ist meist zu empfehlen, aber nicht obligatorisch. Wer z. B. eine anspruchsvolle Fotogalerie-Seite betreibt und den Nutzern von Wide-Gamut-Monitoren etwas Gutes tun will, kann die präsentierten Bilder ruhig im AdobeRGB-Farbraum anlegen (und dann natürlich beim Speichern/Exportieren das AdobeRGB-Profil einbetten). Die meisten aktuellen Browser haben ja Farbmanagement und interpretieren auch AdobeRGB korrekt. Auf den älteren Browsern sind die Bilder dann halt eine Spur blasser – aber längst nicht so, dass durchschnittlichen Nutzern dies ohne Direktvergleich auffallen würde. Vielen Fotografen ist sogar lieber, wenn ihre Bilder im Zweifel eher zu blass als zu stark gesättigt gezeigt werden.

Autor: Andreas Beitinger
Letzte Änderung: September 2026
IMPRESSUM
DATENSCHUTZERKLÄRUNG