Responsive Bilder, Video & Audio

Bilder machen im Schnitt rund die Hälfte des Datenvolumens einer Webseite aus – und die meisten davon werden falsch ausgeliefert. Das 4K-Foto, das auf einem alten Smartphone im Funkloch geladen wird, ist genauso ein Fehler wie das briefmarkenkleine Bild, das auf einem Retina-Display verwaschen wirkt. HTML löst dieses Dilemma mit einer Handvoll eleganter Attribute, die erstaunlich wenige Menschen wirklich beherrschen. In dieser Lektion lernst du sie alle – und dazu, wie du Video und Audio so einbettest, dass sie auf jedem Gerät funktionieren und niemand ausgeschlossen wird.

Als <img src="foto.jpg"> erfunden wurde, sahen alle Bildschirme ungefähr gleich aus. Heute liegt zwischen den Geräten, die deine Seite besuchen, ein gewaltiger Spagat:

• Retina- und High-DPI-Displays packen zwei bis drei physische Pixel in einen CSS-Pixel. Ein Bild, das exakt in seiner Anzeigegröße ausgeliefert wird, wirkt dort unscharf – es bräuchte die doppelte oder dreifache Auflösung.
• Mobilfunkverbindungen sind langsam, teuer oder beides. Wer einem Smartphone im 3G-Netz ein 2.500 Pixel breites Foto schickt, das dort 360 Pixel breit angezeigt wird, verschwendet über 90 Prozent der übertragenen Daten.
• Riesige Desktop-Displays wollen dagegen genau diese 2.500 Pixel – alles andere sieht auf einem 27-Zoll-Monitor pixelig aus.

Ein einzelnes src kann nur eine dieser Welten bedienen. Die Lösung ist nicht, sich für eine zu entscheiden, sondern dem Browser mehrere Kandidaten anzubieten und ihn wählen zu lassen. Denn nur der Browser kennt im Moment des Ladens die Displaydichte, die Viewport-Breite und teils sogar die Netzqualität des Geräts. Genau dafür gibt es srcset, sizes und <picture>.

Für flexible Bilder – also solche, die je nach Layoutbreite unterschiedlich groß dargestellt werden – nutzt du Breiten-Deskriptoren. Das Prinzip in vier Schritten:

1. Du legst dieselbe Grafik in mehreren Breiten ab, z. B. 480, 960 und 1440 Pixel breit.
2. Im srcset listest du alle Kandidaten auf und verrätst dem Browser hinter jeder URL die tatsächliche Pixelbreite der Datei: foto-960.jpg 960w. Das kleine w steht für die intrinsische Breite – der Browser müsste sie sonst erst durch Herunterladen ermitteln.
3. Im sizes-Attribut sagst du, wie breit das Bild im Layout erscheint. Und zwar deshalb, weil der Browser Bilder aus Geschwindigkeitsgründen schon lädt, bevor er dein CSS ausgewertet hat – er kann die spätere Anzeigebreite schlicht noch nicht wissen. sizes ist dein Versprechen an ihn: „Unter 600 Pixel Viewport-Breite füllt das Bild die volle Breite, darüber ist es 600 Pixel breit.“
4. Der Browser rechnet: Anzeigebreite mal Displaydichte ergibt die benötigte Pixelzahl – und er lädt den kleinsten Kandidaten, der genügt. Ein Retina-Handy mit 360 CSS-Pixel Viewport braucht 720 physische Pixel und greift zur 960er-Datei, nicht zur 1440er.

Lies das sizes-Attribut von links nach rechts: Der Browser nimmt die erste zutreffende Media-Bedingung; der letzte Eintrag ohne Bedingung ist der Standardwert. Das src-Attribut bleibt als Fallback für uralte Browser stehen, und width/height geben das Seitenverhältnis an, damit der Browser den Platz reservieren kann und die Seite beim Laden nicht springt (Stichwort Layout-Shift). Probiere das Zusammenspiel jetzt live aus. Ein praktischer Hinweis für alle Bild-Experimente in den Live-Editoren dieses Kurses: Diese Seite stellt dir unter /assets/beispiel/… eigene Testbilder in mehreren Größen und Formaten bereit – sie funktionieren direkt in der Vorschau, ganz ohne fremde Dienste. Die Testbilder unten tragen ihre eigene Breitenstufe als Beschriftung, du siehst also genau, welchen Kandidaten dein Browser gewählt hat:

Nicht jedes Bild ist flexibel. Ein Logo, ein Avatar oder ein Icon wird auf jedem Gerät in derselben CSS-Breite angezeigt – variabel ist nur die Displaydichte. Für diesen Fall gibt es die einfachere Variante mit Dichte-Deskriptoren: 1x für normale, 2x für hochauflösende Displays. Ein sizes-Attribut brauchst du hier nicht, denn die Anzeigebreite steht ja fest.

Die Faustregel für die Wahl zwischen beiden Welten: Ändert sich die Anzeigebreite mit dem Layout, nimm w plus sizes; ist sie fix, nimm x. Mischen darfst du beide Deskriptor-Arten innerhalb eines srcset nicht.

srcset lässt den Browser zwischen Größen desselben Bildes wählen. Das <picture>-Element geht einen Schritt weiter: Es lässt dich grundsätzlich verschiedene Dateien anbieten. Dafür gibt es zwei klassische Anwendungsfälle.

Erstens: der Format-Fallback. Moderne Formate wie AVIF und WebP sind bei gleicher Qualität deutlich kleiner als JPEG – aber du willst niemanden aussperren, dessen Browser sie nicht kennt. Also bietest du sie gestaffelt an: Der Browser geht die <source>-Elemente von oben nach unten durch und nimmt das erste Format, dessen type er unterstützt. Deshalb steht das effizienteste Format zuerst – wer AVIF ans Ende stellt, verschenkt es an alle Browser, die schon vorher bei WebP fündig wurden. Das abschließende <img> ist Pflicht: Es liefert den JPEG-Fallback und trägt alt, width, height und die Lade-Attribute.

Zweitens: Art Direction. Manchmal reicht Skalieren nicht – auf dem Smartphone soll ein enger Bildausschnitt erscheinen, auf dem Desktop das Panorama. Dafür bekommen die <source>-Elemente ein media-Attribut mit einer Media Query. Anders als bei sizes ist media hier verbindlich: Trifft die Bedingung zu, wird genau diese Quelle genommen.

Und so sieht der Format-Fallback in Aktion aus – auch hier verraten die Testbilder per Beschriftung, welches Format dein Browser gewählt hat:

Drei kleine Attribute entscheiden darüber, ob deine Seite sich schnell anfühlt:

• loading="lazy" lädt ein Bild erst, wenn es in die Nähe des sichtbaren Bereichs scrollt. Für Bilder weit unten auf der Seite ist das ein Geschenk: Der erste Seitenaufbau muss sie gar nicht erst abwarten.
• decoding="async" erlaubt dem Browser, das Dekodieren der Bilddaten vom Aufbau der restlichen Seite zu entkoppeln – ein sanfter Hinweis, kein Befehl.
• fetchpriority="high" hebt die Ladepriorität eines Bildes an. Reserviere das für ein Bild: das große Hero-Bild ganz oben, das der Nutzer als Erstes sieht.

Warum diese Arbeitsteilung? Das größte sichtbare Element beim ersten Seitenaufbau – meist eben jenes Hero-Bild – bestimmt den Messwert Largest Contentful Paint (LCP), an dem Suchmaschinen und Nutzer die gefühlte Ladezeit festmachen. Ein lazy geladenes Bild bekommt vom Browser niedrige Priorität und startet spät. Genau das Gegenteil von dem, was dein wichtigstes Bild braucht.

Das <video>-Element bringt einen kompletten Player mit – ganz ohne JavaScript oder Plugins. Die wichtigsten Attribute:

• controls blendet die Bedienelemente des Browsers ein (Play, Lautstärke, Vollbild). Ohne dieses Attribut hat der Nutzer keinerlei Kontrolle – lass es praktisch nie weg.
• poster zeigt ein Vorschaubild, bevor das Video startet. Ohne poster bleibt je nach Browser ein schwarzes Rechteck oder das erste Frame.
• preload steuert, wie viel vorab geladen wird: none (nichts), metadata (nur Dauer und Abmessungen – meist die beste Wahl) oder auto.
• Mehrere <source>-Elemente funktionieren wie bei <picture>: Der Browser nimmt das erste Format, das er abspielen kann.

Und Autoplay? Alle großen Browser blockieren automatisch startende Videos mit Ton – zu viele Seiten haben das Vertrauen der Nutzer verspielt. Autoplay funktioniert zuverlässig nur stummgeschaltet, also in der Kombination autoplay muted playsinline (Letzteres verhindert auf dem iPhone den erzwungenen Vollbildmodus). Das ist für dekorative Hintergrundvideos in Ordnung – für alles mit Inhalt gilt: Der Nutzer drückt selbst auf Play.

Das <audio>-Element funktioniert nach demselben Muster, nur ohne Bildfläche: <audio controls preload="none" src="folge-12.mp3"></audio> genügt für einen Podcast-Player. Bei mehreren Audio-Elementen auf einer Seite ist preload="none" Pflicht der Höflichkeit – sonst lädt der Browser womöglich alle Folgen gleichzeitig an.

Bleibt das wichtigste Element des ganzen Medien-Kapitels: <track>. Es verknüpft Video oder Audio mit einer Textspur im WebVTT-Format – Untertitel, die der Browser passgenau einblendet. Das ist keine Kür, sondern gelebte Barrierefreiheit: Gehörlose und schwerhörige Menschen sind auf Untertitel angewiesen, und alle anderen profitieren in der lauten Bahn oder im leisen Büro gleich mit. Über kind unterscheidest du subtitles (Übersetzung/Mitlesen) von captions (schließt Geräusch-Beschreibungen wie „[Tür knallt]“ ein – gedacht für Menschen, die den Ton nicht hören). Eine WebVTT-Datei ist dabei erfreulich simpel – eine Textdatei mit Zeitmarken:

In der nächsten Lektion widmen wir uns einem Thema, das viele unterschätzen: komplexe, zugängliche Tabellen. Du lernst, wie scope, headers und caption aus einem Datengitter eine Struktur machen, die auch Screenreader souverän vorlesen können.