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.
Seit den Anfangsjahren des Word Wide Web stehen zwei Grafikformate zur Verfügung, die bis heute mit jedem Browser kompatibel geblieben sind: JPEG und GIF. Etwas später kam dann noch das PNG-Format hinzu. Wer sich Fallback-Lösungen sparen will, muss nach wie vor bei diesen drei „alten“ 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. Sie sind oft 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 gewisse Browser-Unterstützung aufweisen können. Natürlich gibt es auch noch wesentlich neuere (Nachfolge-)Formate, die vielleicht vielversprechend sind – aber mit denen man als Webseitenbetreiber trotzdem noch nichts anfangen kann.
Die folgenden Charakterisierungen der Dateiformate beziehen sich ausschließlich auf die Nutzung innerhalb von Internetseiten. Vor- und Nachteile dieser Formate für andere Nutzungsarten (Aufnahme, Archivierung, Druck etc.) sind ein völlig anderes Thema und spielen hier bewusst keine Rolle.
Man könnte JPEG („Joint Photographic Experts Group“) aufgrund seiner Verbreitung fast als den König der Grafikformate bezeichnen. Trotz seines – für Computer-Verhältnisse – biblischen Alters von rund 30 Jahren ist es für Fotos und die meisten anderen Arten von Web-Bildern nach wie vor sehr gut geeignet. Neuere Formate mit etwas effizienterer Kompression konnten sich noch nicht 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. Schwächen hat sie 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 nicht.
Das GIF-Format („Graphics Interchange Format“) kann maximal 256 Farben darstellen und ist schon deshalb für Fotos nicht gut geeignet – denn selbst bei kluger Vorauswahl der Farbtöne wird man irgendwo Banding/Tonwertabrisse sehen. Bevor sich PNG etablierte, wurde GIF jedoch gern für glatte Grafiken eingesetzt, die im JPEG-Format nicht so gut rauskamen. Zudem bietet GIF eine 1-Bit-Transparenz (d. h. man kann ganze Pixel transparent machen). Gerade für „Text als Grafik“ (was im heutigen Webdesign verpönt ist) war die GIF-Transparenz früher oft das Mittel der Wahl.
Mit Verfügbarkeit des PNG-Formates wurde GIF zu 99 % überflüssig. Die einzigen GIF-Anwendungen, die PNG nicht überall ersetzen konnte, sind einfache Animationen. Ein vergleichbare Funktion mit viel weniger Einschränkung bieten mittlerweile auch WebP und AVIF, so dass GIF-Animationen bald nur noch als Fallback sinnvoll sind.
Dank verlustfreier Kompression zeigen Bilder im PNG-Format („Portable Network Graphics“) keinerlei Artefakte. Das macht es ideal für Grafiken mit glatten Kanten, die in JPEG nicht gut aussehen und/oder zuviel Speicherplatz brauchen würden. Für normale Fotos wird man aber eher bei JPEG bleiben, weil PNG hier unnötig große Dateien verursacht. Eine Ausnahme sind Fotos, die irgendwelche transparenten Bereiche enthalten. Selbst wenn man zu solchen Zwecken heute bereits WebP und/oder AVIF verwendet, wird PNG immer noch als Fallback gebraucht.
Theoretisch könnten irgendwo noch Uralt-Browser im Einsatz sein, die keine PNG-Transparenz unterstützen. Ein GIF-Fallback für transparentes PNG, so wie es vor Jahren empfohlen wurde, lohnt sich aber trotzdem nicht mehr. Denn erstens betrifft fehlende PNG-Transparenz nur noch eine verschwindend kleine Zahl von Anwendern und zweitens geht dort lediglich die Transparenz verloren; das Bild wird dann eben auf neutralgrauem Hintergrund angezeigt.
Mit dem sogenannten APNG-Format gibt es mittlerweile eine animierbare Variante von PNG. Leider ist deren Browserunterstützung nicht so umfangreich wie die des herkömmlichen PNG-Formats. Dass sich APNG als Ersatz für animiertes GIF noch in größerem Umfang durchsetzt, ist unwahrscheinlich. Wann immer man gut komprimierte Dateien will, würde man heute eher das WebP-Format in Verbindung mit GIF-Fallback 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“:
Von allen alternativen Formaten für Web-Bilder hat es WebP („Web Picture“ oder „Weppy“) bisher am weitesten gebracht. Es gibt sogar schon erste kommerzielle Webseiten, auf denen WebP in größerem Umfang verwendet wird (z. B. ein Teil der Vorschaubilder auf eBay, Amazon, YouTube oder Google Play).
WebP ist lizenzfrei nutzbar und wird inzwischen in allen aktuellen Browsern unterstützt. Fallback-Lösungen braucht man (Stand April 2021) noch für etwa 20 bis 25 % der Bestandsbrowser – Tendenz sinkend. Anhand der folgenden kleinen WebP-Dateien kann man den eigenen Browser testen.
Das bekannteste Argument für WebP ist seine effektivere Kompression im Vergleich JPEG. Dieser Vorteil ist aber nicht riesig: Allgemein geht man von etwa 30 % aus, subjektiv kann man mit guter Software vielleicht 50 % erreichen. Solange man für WebP noch Fallbacks benötigt, ist eine so geringe Ersparnis bzw. ein so geringer Qualitätsgewinn meist noch kein Argument für umfassende WebP-Nutzung als Ersatz für JPEG (es sei denn, man hat die Fallbacks irgendwie automatisiert).
Der wahre Vorteil von WebP liegt heute in Anwendungsbereichen, für die man bisher GIF oder PNG verwendet hätte. Glatte Grafiken kann man mit WebP etwas 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 größere Fotos transparente Bereiche haben sollen, kommt WebP gegenüber PNG also mit einem Bruchteil der Dateigröße aus.
Ein weitere WebP-Option sind einfache Animationen, die im Gegensatz zu GIF-Animationen nicht unter beschränkter Farbabstufung leiden und dank effektiver Kompression nicht zu größeren Dateien führen.
Nochmal ein paar Jahre jünger und moderner als WebP ist das AVIF-Format („AOMedia Video 1 Image Format“). Es hat technische Ähnlichkeiten mit dem in neueren Kameras und Smartphones verwendeten HEIC-Format, kann im Gegensatz dazu aber lizenzfrei genutzt werden. Bisher gibt es (Stand April 2021) noch nicht so viele Programme und PlugIns, die AVIF erzeugen können. Die Browserunterstützung für AVIF ist aber bereits recht ordentlich – wenngleich noch nicht so breit wie die für WebP. 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 sind mit AVIF möglich.
Gegenüber JPEG soll man mit AVIF rund 50 % der Dateigröße einsparen können. Der konkrete Qualitätsvergleich ist leider ein Stück weit subjektiv, weil die Kompression von AVIF ganz anders arbeitet als die von JPEG: Statt Klötzchen produziert AVIF eher Unschärfen. Von daher kann man über den genauen Prozentsatz der Verbesserung stets streiten. Dass aber bei gleicher Dateigröße AVIF eine klare Verbesserung gegenüber JPEG (und auch eine kleine Verbesserung gegenüber WebP) darstellt, steht außer Zweifel.
Man muss dem Format vielleicht noch Zeit geben, zu reifen. Die wenigen bisher verfügbaren Programme, die AVIF erzeugen können (Stand April 2021), haben noch die eine oder andere Kinderkrankheit.
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 komplexe Vektor-Animationen speichern, die sich technisch mit Bildabfolgen in GIF, WebP oder AVIF nur bedingt vergleichen lassen.
Im Prinzip wird SVG von allen aktuellen Browsern und auch von den meisten älteren Browsern unterstützt. Fallbacks braucht man nur noch für ganz wenige, ziemlich alte Bestandsbrowser. Wenn das Bild nur zierenden Charakter hat und fürs Verständnis der Seite nicht zwingend nötig ist, wird man auf ein Fallback ganz verzichten.
Allerdings ist das SVG-Format ziemlich vielschichtig und nicht in allen Details klar dokumentiert, so dass es noch zu teilweisen Inkompatibilitäten kommen kann. Einfache statische Grafiken sind kein Problem, aber komplexere Bildelemente und bestimmte Sorten von Animationen werden vielleicht nicht in allen alten Browsern korrekt angezeigt.
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 – trotz interner ZIP-Kompression.
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.
Die folgende Tabelle zeigt, welches Dateiformat bzw. welche Fallback-Folge von Dateiformaten aktuell für welchen Bildinhalt besonders gut geeignet ist. Das sind natürlich keine festen, unumstößlichen Zuordnungen, sondern lediglich Empfehlungen unter Berücksichtigung von Formateigenschaften, Browserkompatibilität und Erfahrungswerten. Im Zweifelsfall sollte man es am jeweiligen Bild ausprobieren.
| Fotos ohne Transparenz | JPEG |
| Fotos mit Transparenz | WebP mit PNG-Fallback |
| Grafiken mit vielen Farbnuancen, aber ohne Transparenz | JPEG |
| Grafiken mit vielen Farbnuancen und Transparenz | WebP mit PNG-Fallback |
| Strichgrafiken mit/ohne Transparenz | WebP oder SVG mit PNG-Fallback |
| Grafiken mit glatten Kanten, einfarbigen Flächen und evtl. Transparenz | WebP oder SVG mit PNG-Fallback |
| Einfache, selbstablaufende Animationen | WebP mit GIF-Fallback |
Ob die Fallback-Lösungen lohnen, muss im Einzelfall abgewogen werden. Dort, wo der Qualitätsgewinn oder Speicherplatzvorteil den zusätzlichen Aufwand nicht rechtfertigt, wird man auf WebP/SVG mit Fallback verzichten und gleich nur das „sichere“ Format verwenden.
Das AVIF-Format habe ich in dieser Tabelle bewusst nicht berücksichtigt, weil (Stand April 2021) nur wenige Programmes es erzeugen können und die Browserunterstützung auch noch nicht optimal ist.
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.
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.
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. Bei Pixeldichten über 100 ppi (man spricht dann von High-PPI-Monitoren oder Retina-Displays) würden die Texte und Bedienelemente sonst zu klein dargestellt. Auch Smartphones und Tablets arbeiten intern mit Skalierungsfaktoren; die Pixeldichten dort liegen teilweise schon weit über 300 ppi.
Browser übernehmen für ihre Inhalte standardmäßig die Skalierung, die im Betriebssystem voreingestellt ist. Die im HTML-Code definierten Pixelgrößen haben in diesem Moment nur noch virtuellen Charakter. 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 pixelgenaue Darstellung gibt es ab diesem Moment nicht mehr.
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 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 daneben etwas verschwommen aussehen.
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 nicht 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.
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 (wo dann natürlich trotzdem keine Kompressionsartefakte zu sehen sein sollten).
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 lange 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).
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 relevant ist). Und natürlich braucht man für die neueren Formate immer noch Fallbacks, so dass ihre Verwendung bei einer kleinen Anzahl Bilder gar nicht immer lohnt.
Dabei haben die Artefakte in JPEG, WebP und AVIF jeweils eigene Chakteristiken. Das erschwert den Direktvergleich. Dass WebP und AVIF grundsätzlich gegenüber JPEG einen gewissen Vorteil haben, steht aber außer Zweifel (gute Software vorausgesetzt - mit schlechten Programmen schrumpft der mögliche Vorteil zusammen).
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 ohnehin 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
In der höchsten gezeigten Qualität (Kompressionsrate ca. 1:4) sind die drei Formate mit bloßem Auge nicht vom Original unterscheidbar – weshalb ich mir gespart habe, zusätzlich das unkomprimierte Original als Referenz zu zeigen.
Mit 1:10 bilden sich im JPEG leichte Artefakte in den Feinheiten der Häuser und an den Kontrastkanten zwischen Dächern und Wolkenhimmel. Das ist aber für die meisten Zwecke noch okay. WebP- und AVIF-Version zeigen praktisch noch gar keine Verschlechterung.
Wird mit einer Rate von 1:20 komprimiert, sind die JPEG-Artefakte an den Hausfassaden und an der Kontrastkante zwischen Dächern und Himmel schon recht deutlich. Auch die WebP-Version zeigt nun erste Artefakte – aber immer noch weniger als JPEG bei 1:10. Die AVIF-Version ist immer noch nahezu perfekt; nur bei sehr kritischer Betrachtung kann man erste kleine Unschärfen finden.
Muss man auf eine Kompression von 1:40 gehen, ist die JPEG-Version nicht mehr akzeptabel. Auch WebP und AVIF haben jetzt merkliche Artefakte und unscharfe Bereiche, aber im Gegensatz zum JPEG könnte man sie bei niedrigen Qualitätsansprüchen immer noch verwenden. AVIF ist gegenüber WebP leicht im Vorteil.
Komprimiert man 1:80, sieht das JPEG einfach nur noch grausam aus. Auch WebP und AVIF sind wegen der starken Unschärfen und Artefakte nicht mehr schön, aber nicht ganz so übel wie das JPEG. Ernsthaft brauchbar sind alle drei nicht mehr. Ich habe diese starke Kompression nur als abschreckendes Beispiel mit dazugenommen und würde sie ganz bestimmt nicht für Bilder auf Internetseiten empfehlen.
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 % der 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.
Die Qualität einer Kompression hängt nicht nur vom Format und den Einstellungen ab, sondern auch von der verwendeten Software und deren (teils internen und für den Nutzer gar nicht zugänglichen) Einstellungen. Selbst wenn zwei Programme auf dieselbe Compression Library zurückgreifen, können die Bildergebnisse stark abweichen. Bei der Arbeit für diese Seite habe ich mehrere Programme getestet und erstaunliche Unterschiede gesehen. Die obigen Beispiele wurden übrigens mit dem Online-Tool Squoosh erstellt, das bereits mit Standardeinstellungen relativ gut arbeitet.
Das JPEG-Format hat generell den Vorteil, schon sehr lange auf dem Markt zu sein. Die Software-Kompressoren für JPEG wurden immer weiter verfeinert und liefern heute bei gleicher Dateigröße sichtbar bessere Qualität als Software aus den frühen Jahren. Die Unterschiede, die mit verschiedenen Programmen erzielt werden, sind inzwischen gering. Es tauchen trotzdem immer wieder Spezialprogramme am Markt auf, die versprechen, das JPEG-Format auf wundersame Weise ganz besonders effektiv zu nutzen. Bei genauerer Betrachtung werden diese Versprechen aber nicht erfüllt. Der Effekt beruht nur auf einem konventionellen Kompressions-Algorithmus in Verbindung mit dem Weglassen sämtlicher Metadaten. Sowas kann auch jeder kostenlose Open-Source-Bildbetrachter, wenn man ihn mit etwas Sachverstand entsprechend einstellt.
Ganz anders sieht das bei den neueren Formaten aus, die noch nicht ausentwickelt sind. Hier kann es immer noch enorme Qualitätsunterschiede je nach Software und/oder Softwaregeneration geben. Es gibt durchaus Programme, deren WebP-und AVIF-Ergebnisse kaum besser sind als durchschnittliche JPEGs. Daraus sollte man keine vorschnellen Schlüsse ziehen. Wenn man Dateigröße und Qualität wirklich optimieren will, führt kein Weg daran vorbei, die Ergebnisse verschiedener Programme zu vergleichen.
Welcher Umfang an Artefakten störend ist, hängt natürlich von der genauen Anwendung 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 – und am Ende sogar einen großen Teil des zusätzlichen Datenaufkommens, das durch die erhöhte Pixelzahl droht, durch die Kompression wieder „reinholen“.
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 Qualität der 800er-Version ohne Rücksicht auf die Bildqualität so weit runtergedreht, 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.
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 „Blutlinie“ 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 dieselben 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.
Falls Sie sich fragen, was denn das Besondere an einer Vektorgrafik ist, zoomen* Sie einfach mal die Darstellung in Ihrem Browser ein Stück auf und vergleichen Sie dann die Detailschärfe von PNG- und SVG-Version.
*An mobilen Geräten: mit zwei Fingern aufziehen
An normalen Computern: durch mehrfaches Drücken von Strg|+ zoomen, zurück zu 100 % mit Strg|0
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.
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.
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. SVG eignet sich mehr für Vektorgrafik-Animationen und stellt insofern einen Sonderfall dar.
Einfache GIF-Animationen (und heute vermehrt WebP-Animationen mit GIF-Fallback) 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.
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.
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).
Ü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.
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.
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.
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.
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 eher 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 (zumindest melden die Browser deswegen 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.
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).
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 was 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 somit JPEG als Fallback verwenden.
Für die Entscheidung spielt sicherlich auch die Frage eine Rolle, wieviele Leute überhaupt noch auf die Fallbacks angewiesen sind.
WebP wird zwar von allen aktuellen Browsern angezeigt, aber laut Statistik greifen (Stand April 2021) noch etwas mehr ein Fünftel der Nutzer mit älteren Browsern aufs Internet zu, die kein WebP können (z. B. mit Apple Safari vor Version 14 oder mit dem Internet Explorer).
AVIF funktioniert heute bereits in Google Chrome (der allein schon weltweit einen Marktanteil von 65 % hat) und Opera. Demnächst sollen Firefox und Microsoft Edge dazukommen. Für Apple Safari, der auf weltweit immerhin knapp 20 % Marktanteil kommt (besonders auf iPhones), ist AVIF-Unterstützung leider noch nicht in Aussicht.
Die SVG-Unterstützung umfasst neben den ganzen aktuellen Browsern auch neue und ältere Safari-Versionen. Nur stark veraltete Browser wie der Internet Explorer vor Version 9 können noch kein SVG anzeigen.
Das animierte APNG liegt irgendwo zwischen WebP und SVG, also es wird von allen aktuellen und teils auch etwas älteren Browsern unterstützt.
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.
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 auch schon fertige PlugIns, die die Einrichtung des automatischen Bilder-Fallbacks etwas vereinfachen können.
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 srcset-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 also 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.
Leider gibt es noch Browser, 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. Ihr Anteil wird mit jedem Monat 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 (GIF-)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.
Speziell für SVG-Fallbacks besser geeignet ist daher das OBJECT-Element. Dessen Syntax ist ein bisschen anders und würde so aussehen::
<object data="meinegrafik.svg" type="image/svg+xml" hight="200" width="300">
<param name="src" value="meinegrafik.svg">
<img src="pics/meinegrafik.png" height="200" width="300" alt="Meine Grafikbeschreibung">
</object>
Letztlich funktioniert es dann im Browser wieder nach dem bekannten Schema: Kennt der Browser SVG nicht, greift er auf den Eintrag unter src im IMG-Element zurück – also hier das PNG-Bild.
Das Fallback-Bild wird bei Verwendung von OBJECT leider in jedem Fall mitgeladen. Man sollte es also so weit wie möglich datenreduzieren (ggfs. JPEG statt PNG nutzen).
Je nach Anwendungsfall kann man vielleicht sogar auf OBJECT verzichten. Man bindet die SVG-Grafik einfach nur per IMG-Element ein und verlässt sich als Fallback auf den alt-Text. Es betrifft ja im Fall des SVG-Formates wirklich nur noch wenige, sehr alte Browser.
Eine kleine Fehlermöglichkeit bei Verwendung der Elemente PICTURE und OBJECT ist die notwendige Angabe des sogenannten Mime-Typs für das jeweilige Bildformat. In manchen Browsern funktioniert PICTURE bzw. OBJECT 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).
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.
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 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 (Smartphones und Tablets 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.
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 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.
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.
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 was 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.
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 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.
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.
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 selbst unter den Lesern von fotovideotec.de (also einer Seite, die sich mit Fototechnik befasst und einen großen Schwerpunkt auf das Thema Farbmanagement setzt) verfügt bisher nur eine Minderheit der Leser über profilierte Monitore.
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 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.
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.
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: Mai 2021
IMPRESSUM
DATENSCHUTZERKLÄRUNG