Eine kurze Geschichte der Bilder im Web

Ganz gleich, wie weit Sie schon in der Lernphase „Design und Entwicklung“ für das Web sind – das <img>-Element erfordert nur wenige Vorstellungen. <img> wurde 1993 in Netscape („Mosaic“, damals) eingeführt und 1995 der HTML-Spezifikation hinzugefügt. Seit Langem spielt <img> innerhalb der Webplattform eine einfache, aber wichtige Rolle. Der Entwickler fügt eine „Quellbilddatei“ mit dem Attribut src hinzu und stellt mit dem Attribut alt eine Textalternative bereit, falls das Bild nicht gerendert werden kann oder Unterstützungstechnologien eine Alternative anfordern. Dann hat der Browser nur noch einen Job: die Bilddaten abrufen und diese dann so schnell wie möglich rendern.

In den meisten Fällen der Webentwicklung war die Arbeit mit Bildern gar nicht viel komplizierter. Und trotz der Komplexität des modernen Internets hat sich die Grundlagen der Arbeit mit Bildern nicht geändert: Verwenden Sie ein für das Web geeignetes Bildformat, um Kompatibilität zu gewährleisten, eine sinnvolle Komprimierung, um Bandbreite zu sparen, und Abmessungen, die zu dem Platz passen, den das Bild im Seitenlayout einnehmen wird.

Die Verwendung von Layouts mit fester Breite, wie wir es damals getan haben, als wir dachten, mehr Einfluss darauf zu haben, wie Nutzer das Web erleben, machte dies zu einem unkomplizierten Prozess. Die Größe der Bildquelle konnte besonders einfach eingestellt werden. Für ein Bild, das einen Raum von 500 Pixeln breit und 300 Pixel hoch einnahm, war dies ein Fall der Angabe eines Quellbilds mit derselben Größe.

Bilder in einem responsiven Layout

Neben einem flexiblen Layout und der Verwendung von CSS-Medienabfragen sind „flexible Bilder und Medien“ einer der drei wesentlichen Facetten des responsiven Webdesigns. Um ein Bild flexibel zu machen, begannen Entwickler damit, mit CSS max-width: 100% für das Bild (oder alle Bilder auf der gesamten Website) festzulegen, um die Rendering-Engine des Browsers anzuweisen, ein Bild durch das Herunterskalieren daran zu hindern, dass ein Bild den übergeordneten Container überläuft. Das ist optisch einwandfrei: Das Herunterskalieren eines Rasterbildes ist visuell reibungslos. Mit ein oder zwei CSS-Zeilen sieht ein verkleinertes Bild immer so aus, als hätten wir eine Bildquelle angegeben, die in dieser Größe angezeigt werden sollte. Wenn Rendering-Engines mehr Bilddaten erhalten, als für den Platz, den das Bild in einem Layout einnimmt, erforderlich sind, können sie fundierte Entscheidungen darüber treffen, wie das reduzierte Bild gerendert wird, und zwar ohne visuelle Artefakte oder Unschärfen.

In der Regel möchten Sie ein Bild nicht hochskalieren, d. h., das <img> in einer Größe zu rendern, die größer als die eigentliche Größe des Quell-Images ist. Das Bild würde dann unscharf und körnig aussehen.

Bei Verwendung von img { max-width: 100% } werden Bilder bei Bedarf verkleinert, wenn die Größe des Containers angepasst wird. Anders als beim Festlegen eines starren width: 100% wird dadurch auch sichergestellt, dass das Bild nicht über seine ursprüngliche Größe hinaus skaliert wird. Lange Zeit galten die Regeln für die Arbeit mit Bildern: ein Format verwenden, das Browser verstehen, ein sinnvolles Maß an Komprimierung verwenden und Bilder niemals hochskalieren.

Aber so einfach und effektiv wie dieser Ansatz visuell war, war er mit hohen Leistungskosten verbunden. Da <img> nur eine einzige Quelle für die Bilddaten unterstützt hat, mussten wir ein Bild-Asset bereitstellen, dessen intrinsische Größe so groß war wie die größte Größe, in der es dargestellt werden konnte. Ein Bild, das einen Raum in einem Layout einnehmen soll, das je nach Größe des Darstellungsbereichs des Nutzers zwischen 300px und 2000px breit sein kann, erforderte eine Bildquelle mit einer intrinsischen Breite von mindestens 2000px. Bei einem Nutzer, der die Seite nur in einem kleinen Darstellungsbereich sieht, würde alles wie erwartet aussehen – das Bild würde entsprechend skaliert werden. Auf der gerenderten Seite würde ein großes, aber verkleinertes Quellbild nicht anders aussehen als ein angemessen verkleinertes Bild. Es würde jedoch trotzdem ein breites 2000px-Bild übertragen und gerendert, wobei eine enorme Bandbreite und Rechenleistung ohne spürbaren Vorteil verbraucht wurde.

Mit den ersten „Retina“-Geräten wurde alles noch schlimmer, da die Dichte der Anzeige neben der Größe des Darstellungsbereichs zum Problem wurde. Eine Bildquelle benötigt eine viel größere intrinsische Breite, um sich für ein hochauflösendes Display eignet. Einfach ausgedrückt benötigt eine Anzeige mit doppelter Dichte doppelt so viele Bildpixel, um das Bild so scharf wie möglich zu rendern.

Hier konnten sich die Entwickler wieder auf die Fähigkeit der Rendering-Engines verlassen, Bilder visuell zu verkleinern. Wenn Sie dem Browser ein 800px-breites Quellbild in src zur Verfügung stellen und dann mit CSS angeben, dass es in der Breite 400px angezeigt werden soll, entsteht ein Bild, das mit doppelter Pixeldichte gerendert wird:

Ein einzelnes Quellbild, das für den größtmöglichen Platz in Ihrem Layout und hochauflösenden Displays geschnitten ist, funktioniert natürlich für alle Nutzer visuell. Eine große Bildquelle mit hoher Auflösung, die auf einem kleinen Bildschirm mit niedriger Dichte gerendert wird, sieht wie jedes andere kleine Bild mit niedriger Dichte aus, wirkt aber viel langsamer. Der Nutzer trägt die gesamten Leistungskosten dieser riesigen, 4.000 Pixel breiten Bildquelle ohne Nutzen.

Lange Zeit hat <img> hauptsächlich eines gemacht: „Es wurden Bilddaten erhoben und auf dem Bildschirm angezeigt“. Mit Sicherheit war das recht gut gelungen, aber <img> war nicht in der Lage, die radikalen Veränderungen im Browser-Kontext zu berücksichtigen. Responsives Webdesign wurde zwar zur Mainstream-Entwicklung, aber Browser haben die Leistung von img fast zwanzig Jahre lang optimiert. Für alle Nutzer mit Ausnahme der privilegierten Berechtigungen war der Bildinhalt von Seiten von Anfang an ineffizient. Unabhängig davon, wie schnell der Browser eine Bildquelle anfordern, parsen und rendern konnte, würde das Asset wahrscheinlich weit größer sein, als der Nutzer benötigt.