HTML Responsive Images Guide

Dieser Leitfaden befasst sich mit der HTML-Syntax für responsive Bilder (und ein wenig CSS zur Abrundung). Bei der Syntax für responsive Bilder geht es darum, ein Bild aus mehreren Optionen basierend auf Regeln und Umständen bereitzustellen. Es gibt zwei Formen von responsiven Bildern, und sie dienen zwei verschiedenen Zwecken

<img
  srcset=""
  src=""
  alt=""
>

<picture>
  <source srcset="" media="">
  <source srcset="" media="">
  <img src="" alt="">
</picture>

Hier gibt es viel zu besprechen, also gehen wir beide Syntaxen, alle zugehörigen Attribute und Werte durch und sprechen dabei einige verwandte Themen an, wie z. B. Tools und Browser.

Verwendung von srcset

Die Syntax <img srcset="" src="" alt=""> dient zur Bereitstellung von unterschiedlich großen Versionen desselben Bildes. Sie könnten versuchen, mit dieser Syntax völlig unterschiedliche Bilder bereitzustellen, aber Browser gehen davon aus, dass alles in einem srcset visuell identisch ist und wählen die Größe, die sie für am besten hält, auf eine für Sie unvorhersehbare Weise. Daher würde ich es nicht empfehlen.

Vielleicht ist die einfachst-mögliche Syntax für responsive Bilder das Hinzufügen eines srcset-Attributs mit x-Deskriptoren zu den Bildern, um sie für Displays mit unterschiedlicher Pixeldichte zu kennzeichnen.

<img 
  alt="A baby smiling with a yellow headband."
  src="baby-lowres.jpg"
  srcset="baby-highres.jpg 2x"
>

<img 
  alt="A baby smiling with a yellow headband."
  src="baby-lowres.jpg"
  srcset="
    baby-high-1.jpg 1.5x,
    baby-high-2.jpg 2x,
    baby-high-3.jpg 3x,
    baby-high-4.jpg 4x,
    baby-high-5.jpg 100x
  "
>

Verwendung von srcset / w + sizes

Das ist der eigentliche Knackpunkt. Dies macht etwa 85 % der Nutzung responsiver Bilder im Web aus. Wir stellen immer noch dieselbe Bilddatei in mehreren Größen bereit, nur dass wir dem Browser mehr Informationen geben, damit er sich sowohl an die Pixeldichte als auch an die Layoutgröße anpassen kann.

<img 
  alt="A baby smiling with a yellow headband."
  srcset="
    baby-s.jpg  300w,
    baby-m.jpg  600w,
    baby-l.jpg  1200w,
    baby-xl.jpg 2000w
  "
  sizes="70vmin"
>

Erstellung genauer sizes

Die Erstellung von sizes-Attributen kann knifflig sein. Das sizes-Attribut beschreibt die Breite, in der das Bild innerhalb des Layouts Ihrer spezifischen Website angezeigt wird, was bedeutet, dass es eng mit Ihrem CSS verbunden ist. Die Breite, in der Bilder gerendert werden, ist layoutabhängig und nicht nur ansichtfensterabhängig!

Werfen wir einen Blick auf ein eher einfaches Layout mit drei Breakpoints. Hier ist ein Video, das dies demonstriert

Die Breakpoints werden mit Media Queries in CSS ausgedrückt

body {
  margin: 2rem;
  font: 500 125% system-ui, sans-serif;
}
.page-wrap {
  display: grid;
  gap: 1rem;
  grid-template-columns: 1fr 200px;
  grid-template-areas:
    "header header"
    "main aside"
    "footer footer";
}

@media (max-width: 700px) {
  .page-wrap {
    grid-template-columns: 100%;
    grid-template-areas:
      "header"
      "main"
      "aside"
      "footer";
  }
}
@media (max-width: 500px) {
  body {
    margin: 0;
  }
}

Das Bild ist bei jedem Breakpoint unterschiedlich groß. Hier ist eine Aufschlüsselung aller Teile, die die Layoutbreite des Bildes beim größten Breakpoint beeinflussen (wenn das Ansichtsfenster breiter als 700 Pixel ist)

• Bei der größten Größe: gibt es 9rem expliziten Abstand, sodass das Bild calc(100vw - 9rem - 200px) breit ist. Wenn diese Spalte eine fr-Einheit anstelle von 200px verwenden würde, wären wir hier ziemlich in Schwierigkeiten.
• Bei der mittleren Größe: wird die Seitenleiste darunter verschoben, sodass weniger Abstand zu berücksichtigen ist. Dennoch können wir calc(100vw - 6rem) verwenden, um die Ränder und Abstände zu berücksichtigen.
• Bei der kleinsten Größe: wird der Körperrand entfernt, sodass calc(100vw - 2rem) ausreicht.

Puh! Um ehrlich zu sein, fand ich es ein wenig herausfordernd, das durchzudenken, und habe ein paar Fehler gemacht, als ich es erstellt habe. Am Ende hatte ich das

<img 
  ...  
  sizes="
    (max-width: 500px) calc(100vw - 2rem), 
    (max-width: 700px) calc(100vw - 6rem),
    calc(100vw - 9rem - 200px)
  "
/>

Warten Sie jetzt! Trommelwirbel! 🥁🥁🥁Das ist immer noch falsch. Ich verstehe nicht genau warum, denn für mich sieht das so aus, als würde es zu 100 % das beschreiben, was im CSS-Layout passiert. Aber es ist falsch, weil Martin Auswögers RespImageLint es sagt. Wenn man dieses Tool über das isolierte Demo laufen lässt, werden keine Probleme gemeldet, außer der Tatsache, dass das sizes-Attribut für einige Ansichtsfenstergrößen falsch ist und sein sollte

<img
  ...
  sizes="
    (min-width: 2420px) 2000px, 
    (min-width: 720px) calc(94.76vw - 274px), 
    (min-width: 520px) calc(100vw - 96px), 
    calc(100vw - 32px)
  "
>

Ich weiß nicht, wie das berechnet wird, und es ist von Hand absolut nicht wartbar, aber es ist korrekt. Martins Tool passt die Seite programmgesteuert mehrmals an und gibt ein sizes-Attribut aus, das die tatsächliche beobachtete Breite des Bildes über einen großen Bereich von Ansichtsfenstergrößen beschreibt. Es sind Computer, die Mathematik machen, also ist es richtig. Wenn Sie also ein super-genaues sizes-Attribut wünschen, empfehle ich, zuerst ein falsches einzugeben, dieses Tool auszuführen und das richtige herauszukopieren.

Für eine noch tiefere Auseinandersetzung mit all dem sehen Sie sich Eric Portis' w-Deskriptoren und sizes: Unter der Haube an.

Entspannter Umgang mit sizes

Eine weitere Option ist die Verwendung der Horseshoes & Hand Grenades Methode™ für sizes (oder, anders ausgedrückt, nah genug ist gut genug). Dies wird sehr empfohlen.

Zum Beispiel sagt sizes="96vw": „Dieses Bild wird auf der Seite ziemlich groß sein – fast die volle Breite –, aber es wird immer einen kleinen Rand geben, also nicht ganz. Oder sizes="(min-width: 1000px) 33vw, 96vw" sagt: „Dieses Bild befindet sich auf großen Bildschirmen in einem Drei-Spalten-Layout und ansonsten fast bildschirmfüllend.“ Praktisch gesehen kann dies eine sinnvolle Lösung sein.

Sie stellen möglicherweise fest, dass einige automatisierte Lösungen für responsive Bilder, die Ihr Layout nicht kennen, eine Schätzung vornehmen – so etwas wie sizes="(max-width: 1000px) 100vw, 1000px". Dies bedeutet einfach: „Hey, wir kennen dieses Layout nicht wirklich, aber wir versuchen eine Schätzung und sagen, im schlimmsten Fall ist das Bild bildschirmfüllend, und hoffen wir, dass es niemals größer als 1000 Pixel gerendert wird.“

Abstrahieren von sizes

Ich bin sicher, Sie können sich vorstellen, wie einfach es ist, sizes nicht nur falsch zu setzen, sondern es auch im Laufe der Zeit falsch werden zu lassen, wenn sich Layouts auf Ihrer Website ändern. Es kann sinnvoll sein, es mithilfe einer Vorlagensprache oder eines Inhaltsfilters zu abstrahieren, damit Sie den Wert bei all Ihren Bildern einfacher ändern können.

Ich spreche im Wesentlichen davon, einen sizes-Wert einmal in einer Variablen festzulegen und diese Variable in einer Reihe von verschiedenen <img>-Elementen auf Ihrer Website zu verwenden. Natives HTML bietet das nicht, aber jede Backend-Sprache schon; zum Beispiel PHP-Konstanten, Rails-Konfigurationsvariablen, die React-Context API, die für eine globale Zustandsvariable verwendet wird, oder Variablen in einer Vorlagensprache wie Liquid können alle verwendet werden, um sizes zu abstrahieren.

<?php
  // Somewhere global
  $my_sizes = "";
?>

<img
  srcset=""
  src=""
  alt=""
  sizes="<?php echo $my_sizes; ?>"
/>

„Browser-Auswahl“

Nachdem wir nun ein sizes-Attribut haben, weiß der Browser, welche Größe das Bild (oder annähernd) anzeigen wird und kann seine Magie wirken. Das heißt, er kann einige Berechnungen durchführen, die die Pixeldichte des Bildschirms und die Größe, in der das Bild angezeigt wird, berücksichtigen, und dann das am besten geeignete Bild auswählen.

Die Mathematik ist zunächst ziemlich einfach. Nehmen wir an, Sie möchten ein Bild anzeigen, das auf einem 1200 Pixel breiten Ansichtsfenster auf einem 2x Pixeldichte-Bildschirm 40vw breit ist. Das perfekte Bild wäre 960 Pixel breit, also wird der Browser nach dem nächstgelegenen suchen, das er hat. Der Browser berechnet immer eine Zielgröße, die er basierend auf dem Ansichtsfenster und den Pixeldichte-Situationen *bevorzugt*, und was er aus sizes weiß, und vergleicht dieses Ziel mit dem, was er in srcset zur Auswahl hat. Wie Browser die Auswahl treffen, kann jedoch etwas seltsam werden.

Ein Browser könnte weitere Faktoren in diese Gleichung einbeziehen, wenn er sich dafür entscheidet. Zum Beispiel könnte er die aktuellen Netzwerkgeschwindigkeiten des Benutzers berücksichtigen oder ob der Benutzer eine „Datensparmodus“-Einstellung aktiviert hat. Ich bin mir nicht sicher, ob Browser so etwas tatsächlich tun, aber sie können es, wenn sie möchten, da die Spezifikation so geschrieben wurde. Was einige Browser manchmal tun, ist, aus dem Cache zu ziehen. Wenn die Berechnung ergibt, dass sie ein 300-Pixel-Bild verwenden sollten, sie aber bereits ein 600-Pixel-Bild im lokalen Cache haben, werden sie einfach dieses verwenden. Clever. Raum für solche Dinge ist eine Stärke der srcset/sizes-Syntax. Das ist auch der Grund, warum Sie immer unterschiedlich große Versionen desselben Bildes innerhalb von srcset verwenden: Sie haben keine Möglichkeit zu wissen, welches Bild ausgewählt wird. Es ist die Wahl des Browsers.

Das ist seltsam. Weiß der Browser das nicht schon?

Sie denken vielleicht: „Ähm, warum muss ich dem Browser sagen, wie groß das Bild gerendert wird, weiß er das nicht?“ Nun, das tut er, aber erst nachdem er Ihren HTML- und CSS-Code heruntergeladen und alles angeordnet hat. Das sizes-Attribut dient der Geschwindigkeit. Es gibt dem Browser genügend Informationen, um eine intelligente Entscheidung zu treffen, sobald er Ihr <img> sieht.

<img
  data-sizes="auto"
  data-srcset="
    responsive-image1.jpg 300w,
    responsive-image2.jpg 600w,
    responsive-image3.jpg 900w"
  class="lazyload" 
/>

sizes kann größer als das Ansichtsfenster sein

Kurzer Hinweis zu sizes. Sagen wir, Sie haben einen Effekt auf Ihrer Website, bei dem ein Bild beim Anklicken „hineingezoomt“ wird. Vielleicht dehnt es sich aus, um das gesamte Ansichtsfenster auszufüllen, oder es zoomt sogar noch weiter, damit Sie mehr Details sehen können. Früher mussten wir vielleicht src beim Klicken austauschen, um zu einer höher aufgelösten Version zu wechseln. Aber jetzt, vorausgesetzt, eine höher aufgelöste Quelle ist bereits im srcset vorhanden, können Sie einfach das sizes-Attribut auf etwas Riesiges ändern, wie z. B. 200vw oder 300vw, und der Browser sollte die super-hoch aufgelöste Quelle automatisch für Sie herunterladen. Hier ist ein Artikel von Scott Jehl über diese Technik.

↩️ Zurück nach oben

Verwendung von <picture>

Hoffentlich haben wir es zur Genüge wiederholt, dass <img srcset="" sizes="" alt=""> dazu dient, unterschiedlich große Versionen desselben Bildes bereitzustellen. Die <picture>-Syntax kann das auch, aber der Unterschied hier ist, dass der Browser die von Ihnen festgelegten Regeln einhalten muss. Das ist nützlich, wenn Sie mehr als nur die Auflösung des geladenen Bildes ändern möchten, um es an die Situation des Benutzers anzupassen. Diese beabsichtigte Änderung des Bildes wird üblicherweise als „Art Direction“ bezeichnet.

Art Direction

<picture>
  <source 
    srcset="baby-zoomed-out.jpg"
    media="(min-width: 1000px)"
  />
  <source 
    srcset="baby.jpg"
    media="(min-width: 600px)"
  />
  <img 
    src="baby-zoomed-in.jpg" 
    alt="Baby Sleeping"
  />
</picture>

Hier ist eine Demo, geschrieben in Pug, um die repetitive Natur von <picture> zu abstrahieren.

Art Direction kann mehr als nur Zuschneiden

Obwohl das Zuschneiden und Zoomen auf diese Weise die bei weitem häufigste Form der Art Direction ist, können Sie damit viel mehr machen. Sie können zum Beispiel

• Bilder dunkel machen für Benutzer im Dark Mode,
• animierte GIFs vermeiden an Benutzer mit der Barrierefreiheitspräferenz „reduzierte Bewegung bevorzugen“,
• Bildinhalte neu anordnen, damit sie auf kurzen Ansichtsfenstern alle „above the fold“ passen,
• eine maximale Auflösung festlegen, um Benutzern auf Geräten mit 3x oder höherer Auflösung viele Bytes zu sparen,
• statische, hochauflösende, monochrome Bilder senden an Drucker und E-Ink-Geräte.

Der Himmel ist wirklich die Grenze.

Kombination von source und srcset

Da <source> ebenfalls die srcset-Syntax verwendet, können sie kombiniert werden. Das bedeutet, dass Sie immer noch die Leistungsvorteile von srcset nutzen können, auch wenn Sie visuell unterschiedliche Bilder mit <source> austauschen. Es wird jedoch ziemlich wortreich!

<picture>
  <source 
    srcset="
      baby-zoomed-out-2x.jpg 2x,
      baby-zoomed-out.jpg
    "
    media="(min-width: 1000px)"
  />
  <source 
    srcset="
      baby-2x.jpg 2x,
      baby.jpg
    "
    media="(min-width: 600px)"
  />
  <img 
    srcset="
      baby-zoomed-out-2x.jpg 2x
    "
    src="baby-zoomed-out.jpg"
    alt="Baby Sleeping"
  />
</picture>

Fallbacks für moderne Bildformate

Das <picture>-Element ist einzigartig geeignet, um „Fallbacks“ zu verarbeiten. Das heißt, Bilder in hochmodernen Formaten, die nicht alle Browser unterstützen, mit alternativen Formaten für Browser, die das bevorzugte, schicke Format nicht laden können. Sagen wir zum Beispiel, Sie möchten ein Bild im WebP-Format verwenden. Es ist ein ziemlich großartiges Bildformat, oft die leistungsfähigste Wahl, und es wird überall unterstützt, wo das <picture>-Element unterstützt wird, außer im Safari. Sie können diese Situation selbst handhaben, wie hier

<picture>
  <source srcset="party.webp">
  <img src="party.jpg" alt="A huge party with cakes.">
</picture>

Hier ist ein Beispiel für ein Foto (von mir) in exakt derselben Größe, bei dem die WebP-Version etwa 10 % (!!!) der Größe des JPEGs ausmacht.

Wie erstellen Sie ein WebP-Bild? Nun, es ist umständlicher, als Sie möchten, das ist sicher. Es gibt Online-Konverter, Kommandozeilen-Tools und einige moderne Design-Software wie Sketch hilft Ihnen beim Export in diesem Format. Meine Präferenz ist die Verwendung eines Bild-Hosting-CDN-Dienstes, der Bilder automatisch im perfekten Format für den anfragenden Browser bereitstellt, was all dies überflüssig macht (da Sie einfach img/srcset verwenden können).

WebP ist nicht der einzige Akteur dieser Art. Safari unterstützt kein WebP, aber unterstützt ein Format namens JPG 2000, das einige Vorteile gegenüber JPEG hat. Internet Explorer 11 unterstützt zufällig ein Bildformat namens JPEG-XR, das unterschiedliche Vorteile hat. Um also alle drei zu treffen, könnte das so aussehen

<picture>
  <source srcset="/images/cereal-box.webp" type="image/webp" />
  <source srcset="/images/cereal-box.jp2" type="image/jp2" />
  <img src="/images/cereal-box.jxr" type="image/vnd.ms-photo" />
</picture>

Estelle Weyl behandelte diese Idee auch in einem Blogbeitrag von 2016 über Bildoptimierung.

↩️ Zurück nach oben

Woher bekommen Sie die unterschiedlich großen Bilder?

Sie können sie selbst erstellen. Selbst die kostenlose Vorschau-App auf meinem Mac kann ein Bild in der Größe ändern und „Speichern unter“.

Aber das ist Arbeit. Es ist wahrscheinlicher, dass die Erstellung von Variationen dieser Bilder irgendwie automatisiert wird (siehe unten) oder Sie verwenden einen Dienst, der es Ihnen ermöglicht, Variationen durch einfaches Manipulieren der URL zum Bild zu erstellen. Das ist eine sehr häufige Funktion jedes Bild-Hosting-/Bild-CDN-Dienstes. Um nur einige zu nennen

• Cloudinary bietet es an
• Netlify bietet es an
• imgix bietet es an
• Image Optim bietet es an
• Filestack bietet es an
• Cloudflare bietet es an

Diese Dienste bieten nicht nur Bildgrößenänderung nach Bedarf, sondern oft auch zusätzliche Funktionen wie Zuschneiden, Filtern, Hinzufügen von Text und alle möglichen nützlichen Features, ganz zu schweigen von der effizienten Auslieferung von Assets von einem CDN und automatisch in Next-Gen-Formaten. Das macht sie für praktisch jede Website zu einer sehr guten Wahl, würde ich sagen.

Hier spricht Glen Maddern in einem wirklich großartigen Screencast darüber, wie nützlich Image CDNs sein können

Design-Software wird sich zunehmend bewusst, dass wir oft mehrere Kopien von Bildern benötigen. Zum Beispiel ist die Exportoberfläche von Figma ziemlich gut, wo jede beliebige Auswahl exportiert werden kann. Sie ermöglicht mehrere Exporte gleichzeitig (in verschiedenen Größen und Formaten) und merkt sich, was Sie beim letzten Export getan haben.

Automatisierte responsive Bilder

Die Syntax von responsiven Bildern ist so komplex, dass die manuelle Erstellung oft außer Frage steht. Ich empfehle dringend, so viel wie möglich zu automatisieren und zu abstrahieren. Glücklicherweise ist sich die meiste Tooling, die Ihnen beim Erstellen von Websites hilft, dessen bewusst und bietet eine gewisse Unterstützung dafür. Ich finde das großartig, denn das ist es, was Software für uns tun *sollte*, insbesondere wenn es sich um etwas handelt, das vollständig programmgesteuert ist und besser von Code als von Menschen erledigt werden kann. Hier sind einige Beispiele ...

• Cloudinary hat dieses Responsive Breakpoints Tool einschließlich einer API zur Generierung der perfekten Breakpoints.
• WordPress generiert mehrere Versionen von Bildern und gibt standardmäßig die Syntax für responsive Bilder aus aus.
• Gatsby verfügt über eine Sammlung von Plugins zur Transformation und Implementierung von Bildern auf Ihrer Website. Sie implementieren sie letztendlich mit gatsby-image, einem ziemlich ausgefeilten Werkzeug zur Implementierung responsiver Bilder und anderer Bildladeoptimierungen. Apropos React, es gibt Komponentenabstraktionen wie „An Almost Ideal React Image Component“, die ebenfalls coole Sachen machen.
• Nicolas Hoizeys Images Responsiver Node-Modul (und sein Eleventy-Plugin) trifft viele intelligente Markup-Entscheidungen für Sie und passt gut zu einer CDN, die das dynamische Skalieren übernehmen kann.
• Dies sind nur einige Beispiele! Alles, was Sie tun können, um diesen Prozess einfacher oder automatisch zu gestalten, ist es wert.

Ich bin sicher, es gibt viele weitere CMSs und andere Softwareprodukte, die helfen, die Komplexität der Erstellung von responsiven Bildersyntax zu automatisieren. Obwohl ich es liebe, dass all diese Syntax existiert, finde ich es alles viel zu umständlich, sie von Hand zu erstellen. Dennoch denke ich, dass es sich lohnt, all diese Syntax zu kennen, damit wir unsere eigenen Abstraktionen erstellen oder die von uns verwendeten Abstraktionen überprüfen können, um sicherzustellen, dass sie die Dinge korrekt tun.

Verwandte Konzepte

• Die object-fit-Eigenschaft in CSS steuert, wie sich ein Bild in seinem eigenen Feld verhält. Zum Beispiel wird ein Bild normalerweise "gestaucht", wenn Sie die Abmessungen auf etwas anderes als sein natürliches Seitenverhältnis ändern, aber object-fit kann verwendet werden, um es zuzuschneiden oder stattdessen zu enthalten.
• Die object-position-Eigenschaft in CSS ermöglicht es Ihnen, ein Bild innerhalb seines Feldes zu verschieben.

Was ist mit responsiven Bildern in CSS mit Hintergrundbildern?

Wir haben genau das schon einmal behandelt. Der Trick besteht darin, @media-Abfragen zu verwenden, um die background-image-Quelle zu ändern. Zum Beispiel

.img {
  background-image: url(small.jpg);
}
@media 
  (min-width: 468px),
  (-webkit-min-device-pixel-ratio: 2), 
  (min-resolution: 192dpi) {
  .img {
    background-image: url(large.jpg);
  }
}

Wenn Sie möchten, dass der Browser die beste Option wählt, wie srcset/sizes, aber in CSS, wird die Lösung letztendlich die image-set()-Funktion sein. Es gibt jedoch zwei Probleme mit image-set() heute:

• Die Unterstützung dafür ist noch nicht da. Safaris Implementierung führt die Gruppe an, aber image-set() ist in Chrome seit acht Jahren präfixiert und in Firefox überhaupt nicht vorhanden.
• Selbst der Standard selbst scheint hinter den Zeiten zurückzubleiben. Zum Beispiel unterstützt er nur x-Deskriptoren (noch keine w, noch nicht).

Am besten verwenden Sie vorerst einfach Media Queries.

Müssen Sie Polyfillen?

Ich bin ziemlich meh, was das Polyfilling all dessen im Moment angeht. Es gibt jedoch ein großartiges Polyfill namens Picturefill, das Ihnen volle IE 9-11 Unterstützung bietet, wenn Sie diese benötigen. Denken Sie jedoch daran, dass keine dieser Dinge so kaputt geht, dass sie in nicht unterstützenden Browsern überhaupt kein Bild mehr anzeigt, vorausgesetzt, Sie haben irgendwo ein <img src="" alt="">. Wenn Sie die (ziemlich sichere) Annahme treffen, dass IE 11 auf einem Desktop-Display mit geringer Pixeldichte läuft, können Sie Ihre Bildquellen standardmäßig widerspiegeln und von dort aus aufbauen.

Andere wichtige Bildüberlegungen

• Qualitätsoptimierung: Der Sinn von responsiven Bildern ist das Laden der kleinsten, wirkungsvollsten Ressource, die Sie haben können. Dies können Sie nicht erreichen, ohne Ihr Bild effektiv zu komprimieren. Sie streben für jedes Bild nach einem "Sweet Spot" zwischen gutem Aussehen und geringem Gewicht. Ich lasse gerne Bild-Hosting-Dienste dieses Problem für mich lösen, aber Etsy hat einen wirklich großartigen Artikel darüber, was sie mit selbst entwickelter Infrastruktur erreichen konnten.
• Auslieferung von CDNs: Apropos Bild-Hosting-Dienste, Geschwindigkeit hat viele Formen. Schnelle Server, die geografisch nah am Benutzer sind, sind ebenfalls ein wichtiger Geschwindigkeitsfaktor.
• Caching: Was ist besser, als weniger Daten über das Netzwerk zu laden? Gar keine Daten zu laden! Dafür ist HTTP-Caching da. Mit dem Cache-Control-Header können Sie dem Browser mitteilen, Bilder aufzubewahren, sodass der Browser nicht über das Netzwerk darauf zugreifen muss, wenn dasselbe Bild wieder benötigt wird, was eine massive Leistungssteigerung für wiederholte Aufrufe bedeutet.
• Lazy Loading: Dies ist eine weitere Möglichkeit, das Laden von Bildern ganz zu vermeiden. Lazy Loading bedeutet, das Herunterladen eines Bildes hinauszuzögern, bis es sich im Viewport oder in dessen Nähe befindet. Ein Bild, das sich also weit unten auf der Seite befindet, wird beispielsweise nicht geladen, wenn der Benutzer niemals dorthin scrollt.

Andere gute Ressourcen

(Die ich im Beitrag noch nicht verlinkt habe!)

• Eric Portis im Cloudinary-Blog: Responsive Images mit ‚srcset‘, ‚sizes‘ und Cloudinary
• Eric Portis‘ tiefer Einblick in Srcset und Sizes
• Eric Portis auf Smashing Magazine: Responsive Images Done Right: Ein Leitfaden zu <picture> und srcset
• MDN-Anleitung: Responsive Bilder
• Jason Grigsbys umfangreiche 10-teilige Anleitung im Cloudfour-Blog
• Scott Vandehey im Cloudfour-Blog: Responsive Images auf einfache Art
• Die ursprüngliche W3C Community Group, die sich für responsive Bilder in Browsern einsetzte und sie durchsetzte
• Pete LePage im Google Developer Web Fundamentals Guide: Bilder
• Addy Osmans Essential Image Optimization eBook
• Elad Schechters Vollständiger Leitfaden für responsive Bilder
• 📹 Mat Marquis‘ Konferenzvortrag: Die Vergangenheit, Gegenwart und Zukunft von responsiven Bildern
• Mat Marquis‘ Buch Image Performance
• Jake Archibalds Die Anatomie von responsiven Bildern
• 📹 Responsive Bilder, WordPress und Cloudinary
• Andreas Bovens im Opera Developer Blog: Responsive Bilder: Anwendungsfälle und dokumentierte Code-Schnipsel für den Einstieg

Browser-Unterstützung

Dies ist für srcset/sizes, aber es ist dasselbe für <picture>.