In diesem Modul erfahren Sie, wie Sie dem Browser eine Auswahl an Bildern zur Verfügung stellen, damit er die besten Entscheidungen darüber treffen kann, was angezeigt werden soll. srcset ist keine Methode zum Austauschen von Bildquellen an bestimmten Haltepunkten und auch nicht dazu gedacht, ein Bild gegen ein anderes auszutauschen. Diese Syntaxen ermöglichen es dem Browser, unabhängig von uns ein sehr schwieriges Problem zu lösen: nahtlose Anforderung und Darstellung einer Bildquelle, die auf den Browserkontext eines Nutzers zugeschnitten ist, einschließlich Größe des Darstellungsbereichs, Anzeigedichte, Nutzereinstellungen, Bandbreite und zahlreichen anderen Faktoren.
Das ist eine große Herausforderung – sicherlich mehr, als wir bei der Auszeichnung eines Bildes für das Web berücksichtigen möchten, und eine gute Umsetzung erfordert mehr Informationen, als wir Zugang haben.
Dichte mit x beschreiben
Ein <img>-Objekt mit einer festen Breite belegt in jedem Suchkontext immer die gleiche Menge des Darstellungsbereichs, unabhängig von der Dichte des Displays eines Nutzers – der Anzahl der physischen Pixel, aus denen sein Bildschirm besteht. Ein Bild mit einer inhärenten Breite von 400px nimmt beispielsweise sowohl auf dem ursprünglichen Google Pixel als auch auf dem neueren Pixel 6 Pro fast den gesamten Darstellungsbereich des Browsers ein. Beide Geräte haben einen normalisierten Darstellungsbereich, der 412px
logische Pixel breit ist.
Pixel 6 Pro hat jedoch ein viel schärferes Display: Pixel 6 Pro hat eine physische Auflösung von 1440 × 3120 Pixeln, während Pixel 1080 × 1920 Pixel hat – also die Anzahl der Hardwarepixel, aus denen das Display selbst besteht.
Das Verhältnis zwischen den logischen und physischen Pixeln eines Geräts ist das Pixelverhältnis des Geräts für diese Anzeige (DPR). Zur Berechnung der DPR wird die tatsächliche Bildschirmauflösung des Geräts durch die CSS-Pixel eines Darstellungsbereichs geteilt.
Das ursprüngliche Pixel hat also einen DPR von 2,6, während das Pixel 6 Pro eine DPR von 3,5 hat.
Das iPhone 4, das erste Gerät mit einem DPR größer als 1, meldet ein Geräte-Pixel-Verhältnis von 2 – die physische Auflösung des Bildschirms ist doppelt so hoch wie die logische Auflösung. Alle Geräte vor dem iPhone 4 hatten einen DPR von 1: ein logisches Pixel zu einem physischen Pixel.
Wenn Sie dieses 400px-breite Bild auf einem Display mit einem DPR von 2 betrachten, wird jedes logische Pixel in vier physischer Pixel des Displays gerendert: zwei horizontal und zwei vertikal. Das Bild profitiert nicht von einem hochauflösenden Display – es sieht genauso aus wie auf einem Display mit einem DPR von 1. Natürlich wird alles, was vom Rendering-Modul des Browsers gezeichnet wird, z. B. Text, CSS-Formen oder SVGs, entsprechend dem Bildschirm mit höherer Dichte gezeichnet. Wie Sie jedoch unter Bildformate und Komprimierung gelernt haben, sind Rasterbilder feste Pixelraster. Auch wenn dies nicht immer deutlich erkennbar ist, sieht ein Rasterbild, das für einen Bildschirm mit höherer Dichte angepasst wurde, im Vergleich zur umgebenden Seite eine niedrige Auflösung aus.
Um eine solche Erhöhung zu verhindern, muss das gerenderte Bild eine intrinsische Breite von mindestens 800 Pixeln haben. Wenn sie verkleinert wird, um einen Raum in einem Layout mit einer Breite von 400 logischen Pixeln unterzubringen, hat diese 800-Pixel-Bildquelle die doppelte Pixeldichte. Auf einem Display mit einem DPR von 2 sieht sie gut und gestochen scharf aus.
Da ein Display mit einem DPR von 1 die höhere Dichte eines Bildes nicht nutzen kann, wird es verkleinert, damit es dem Display entspricht. Wie Sie wissen, sieht ein verkleinertes Bild gut aus. Auf einem Bildschirm mit niedriger Dichte sieht ein Bild, das sich für Displays mit höherer Dichte eignet, wie andere Bilder mit niedriger Dichte aus.
Wie Sie unter Bilder und Leistung gelernt haben, benötigt ein Nutzer mit einem Bildschirm mit geringer Dichte nur eine Quelle mit einer inhärenten Breite von 400px, die eine auf 400px skalierte Bildquelle anzeigt. Auch wenn ein viel größeres Bild für alle Nutzer visuell gut geeignet wäre, würde eine große, hochauflösende Bildquelle, die auf einem kleinen Display mit niedriger Dichte gerendert wird, wie alle anderen kleinen Bilder mit niedriger Dichte aussehen, aber deutlich langsamer wirken.
Wie Sie vielleicht vermuten, sind Mobilgeräte mit einer DPR von 1 verschwindend selten, aber im Kontext des „Desktop“-Browsers ist dies immer noch üblich. Laut Daten von Matt Hobbs berichten etwa 18% der Browsersitzungen von GOV.UK im November 2022 eine DVR von 1. Obwohl hochauflösende Bilder so aussehen würden, wie Nutzer es erwarten, sind die Bandbreite und die Verarbeitungskosten deutlich höher. Besonders wichtig ist dies für Nutzer von älteren und weniger leistungsstarken Geräten, die wahrscheinlich immer noch einen Bildschirm mit niedriger Dichte haben.
Die Verwendung von srcset sorgt dafür, dass nur Geräte mit hochauflösenden Displays Bildquellen erhalten, die groß genug sind, um scharf auszusehen, ohne die gleichen Bandbreitenkosten an Nutzer mit Displays mit niedrigerer Auflösung weiterzugeben.
Das Attribut srcset gibt einen oder mehrere durch Kommas getrennte Kandidaten zum Rendern eines Bildes an. Jeder Kandidaten besteht aus zwei Elementen: einer URL, wie Sie sie in src verwenden würden, und einer Syntax, die diese Bildquelle beschreibt. Jeder Kandidaten in srcset wird durch seine inhärente Breite („w“-Syntax) oder durch seine beabsichtigte Dichte („x-Syntax“) beschrieben.
Die Syntax x ist eine Abkürzung für „Diese Quelle ist für eine Anzeige mit dieser Dichte geeignet“ – ein Kandidat gefolgt von 2x ist für eine Anzeige mit einem DPR von 2 geeignet.
<img src="low-density.jpg" srcset="double-density.jpg 2x" alt="...">
Browser, die srcset unterstützen, sehen zwei Kandidaten: double-density.jpg – double-density.jpg – was 2x als geeignet für Displays mit einem DPR von 2 beschreibt – und low-density.jpg im src-Attribut – der Kandidat wird ausgewählt, wenn in srcset nichts Besseres gefunden wird. Bei Browsern, die srcset nicht unterstützen, werden das Attribut und sein Inhalt ignoriert. Der Inhalt von src wird wie gewohnt angefordert.
Die im srcset-Attribut angegebenen Werte können leicht mit einer Anleitung verwechselt werden. Dadurch wird der Browser durch 2x darüber informiert, dass die zugehörige Quelldatei für die Verwendung auf einer Anzeige mit einem DPR von 2 geeignet ist, d. h. Informationen zur Quelle selbst. Sie sagt dem Browser nicht, wie die Quelle verwendet werden soll, sondern informiert den Browser lediglich darüber, wie die Quelle genutzt werden könnte. Das ist eine subtile, aber wichtige Unterscheidung: Es handelt sich um ein Bild mit doppelter Punktdichte, nicht um ein Bild, das auf einem Display mit doppelter Punktdichte verwendet werden kann.
Der Unterschied zwischen einer Syntax, die besagt, dass diese Quelle für 2x-Bildschirme geeignet ist, und einer Syntax, die besagt, dass diese Quelle auf 2x-Bildschirmen verwendet wird, ist im gedruckten Zustand gering. Die Anzeigedichte ist jedoch nur einer von vielen miteinander verknüpften Faktoren, die der Browser verwendet, um zu entscheiden, welcher für das Rendering infrage kommt. Einige davon sind bekannt. Sie können beispielsweise einzeln über die Medienabfrage prefers-reduced-data feststellen, ob ein Nutzer eine Browsereinstellung zur Bandbreiteneinsparung aktiviert hat, und diese verwenden, um Nutzern unabhängig von ihrer Anzeigedichte immer Bilder mit niedriger Dichte anzuzeigen. Aber wenn sie nicht konsistent und von jedem Entwickler auf jeder Website implementiert wird, wäre sie für einen Nutzer nicht von großem Nutzen.
Vielleicht haben sie an einem Standort ihre Präferenz respektiert und stoßen auf dem nächsten auf eine Wand mit Bildern, die die Bandbreite verschleiern.
Der absichtlich vage Algorithmus zur Ressourcenauswahl, der von srcset/sizes verwendet wird, lässt Browser Raum für die Entscheidung, ob Bilder mit geringerer Dichte, mit Bandbreiteneinbrüchen, oder auf Grundlage einer Präferenz zur Minimierung der Datennutzung ausgewählt werden können, ohne dass wir die Verantwortung dafür übernehmen, wie, wann oder bei welchem Schwellenwert. Es ergibt keinen Sinn, Verantwortung – und zusätzliche Arbeit – zu übernehmen, bei der der Browser besser für Sie gerüstet ist.
Breiten mit w beschreiben
srcset akzeptiert einen zweiten Deskriptortyp für Bildquellenkandidaten. Es ist viel leistungsstärker – und für unsere Zwecke
viel leichter zu verstehen. Anstatt einen Kandidaten mit den passenden Abmessungen für eine bestimmte Anzeigedichte zu kennzeichnen, beschreibt die w-Syntax die inhärente Breite jeder Kandidatenquelle. Auch hier sind alle Kandidaten hinsichtlich ihrer Abmessungen identisch – derselbe Inhalt, derselbe Zuschnitt und dasselbe Seitenverhältnis. Aber in diesem Fall soll der Browser des Nutzers zwischen zwei Kandidaten wählen: „small.jpg“, einer Quelle mit einer inhärenten Breite von 600 px, und „large.jpg“, einer Quelle mit einer inhärenten Breite von 1.200 px.
srcset="small.jpg 600w, large.jpg 1200w"
Dadurch wird dem Browser nicht mitgeteilt, was mit diesen Informationen getroffen werden soll. Sie erhalten lediglich eine Liste mit Kandidaten für die Anzeige des Bildes.
Bevor der Browser entscheiden kann, welche Quelle gerendert werden soll, müssen Sie noch weitere Informationen bereitstellen: eine Beschreibung, wie das Bild auf der Seite gerendert werden soll. Dazu verwenden Sie das Attribut sizes.
Nutzung mit sizes beschreiben
Browser sind äußerst leistungsfähig, wenn es um die Übertragung von Bildern geht. Anfragen für Bild-Assets werden schon lange vor Anfragen für Stylesheets oder JavaScript initiiert – oft sogar noch, bevor das Markup vollständig geparst wurde. Wenn der Browser diese Anfragen sendet, hat er mit Ausnahme des Markups keine Informationen über die Seite selbst. Möglicherweise wurden noch nicht einmal externe Stylesheets angefordert oder gar nicht angewendet. Wenn der Browser das Markup parst und externe Anfragen sendet, sind nur Informationen auf Browserebene verfügbar: die Größe des Darstellungsbereichs des Nutzers, die Pixeldichte der Anzeige des Nutzers, Nutzereinstellungen usw.
Diese Aussage sagt nichts darüber aus, wie ein Bild im Seitenlayout gerendert werden soll. Der Darstellungsbereich kann nicht einmal als Proxy für die Obergrenze der Größe img verwendet werden, da er einen horizontal scrollbaren Container belegen kann. Also müssen wir dem Browser diese Informationen zur Verfügung stellen und dies mithilfe von Markup tun. Das ist alles, was wir für diese Anfragen verwenden können.
Wie srcset soll auch sizes Informationen zu einem Bild verfügbar machen, sobald das Markup geparst wurde. Das Attribut srcset ist eine Abkürzung für „Hier sind die Quelldateien und ihre inhärente Größe“ und das Attribut sizes steht für „Hier ist die Größe des gerenderten Bilds im Layout“. Die Art und Weise, wie Sie das Bild beschreiben, richtet sich nach dem Darstellungsbereich. Auch hier ist die Größe des Darstellungsbereichs die einzigen Layoutinformationen, über die der Browser bei der Bildanfrage verfügt.
Das mag in der Druckversion etwas kompliziert klingen, ist in der Praxis aber viel leichter zu verstehen:
<img
sizes="80vw"
srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 2000w"
src="fallback.jpg"
alt="...">
Hier wird dem Browser durch diesen sizes-Wert mitgeteilt, dass der Bereich in unserem Layout, den das img-Element einnimmt, eine Breite von 80vw – 80% des Darstellungsbereichs hat. Zur Erinnerung: Dies ist keine Anleitung, sondern eine Beschreibung der Bildgröße im Seitenlayout. Nicht heißt es: „Dieses Bild soll 80% des Darstellungsbereichs einnehmen“, sondern „das Bild nimmt nach dem Rendern der Seite 80% des Darstellungsbereichs ein“.
Als Entwickler ist Ihre Arbeit erledigt. Sie haben eine Liste möglicher Quellen in srcset und die Breite Ihres Bildes in sizes korrekt beschrieben. Wie bei der x-Syntax in srcset wird der Rest dem Browser überlassen.
Damit Sie jedoch besser verstehen, wie diese Informationen verwendet werden, sehen wir uns die Entscheidungen an, die der Browser eines Nutzers trifft, wenn er auf dieses Markup stößt:
Sie haben den Browser darüber informiert, dass dieses Bild 80% des verfügbaren Darstellungsbereichs einnehmen wird. Wenn wir also img auf einem Gerät mit einem 1.000 Pixel breiten Darstellungsbereich rendern würden, belegt dieses Bild 800 Pixel. Der Browser nimmt diesen Wert dann und teilt ihn gegen die Breite der einzelnen Bildquellenkandidaten, die wir in srcset angegeben haben. Die kleinste Quelle hat eine inhärente Größe von 600 Pixeln, also 600 ÷ 800 = 0,75. Unser mittelgroßes Bild ist 1.200 Pixel breit: 1.200 ÷ 800=1,5. Das größte Bild ist 2000 Pixel breit: 2000 ÷ 800=2,5.
Die Ergebnisse dieser Berechnungen (.75, 1.5 und 2.5) sind im Grunde DPR-Optionen, die speziell auf die Größe des Darstellungsbereichs des Nutzers zugeschnitten sind. Da der Browser auch über Informationen zur Anzeigedichte des Nutzers verfügt, trifft er eine Reihe von Entscheidungen:
Bei dieser Größe des Darstellungsbereichs wird der Kandidat small.jpg unabhängig von der Anzeigedichte des Nutzers verworfen. Mit einem berechneten DPR-Wert, der niedriger als 1 ist, würde diese Quelle für jeden Nutzer verkleinert werden, sodass sie nicht geeignet ist. Auf einem Gerät mit einem DPR von 1 bietet medium.jpg die genaueste Übereinstimmung. Diese Quelle eignet sich zur Anzeige mit einem DPR von 1.5, ist also etwas größer als nötig. Denken Sie jedoch daran, dass das Herunterskalieren ein visuell nahtloser Prozess ist. Auf einem Gerät mit einem DPR von 2 ist large.jpg die genaueste Übereinstimmung und wird daher ausgewählt.
Wenn das gleiche Bild in einem 600 Pixel breiten Darstellungsbereich gerendert wird, würde die Berechnung völlig anders aussehen: 80vw ist jetzt 480 Pixel.
Wenn wir die Breite der Quellen entsprechend dividieren, erhalten wir 1.25, 2.5 und 4.1666666667. Bei dieser Größe des Darstellungsbereichs wird small.jpg auf 1x-Geräten und medium.jpg auf 2x-Geräten ausgewählt.
Dieses Bild wird in all diesen Suchkontexten identisch aussehen: Alle unsere Quelldateien sind unabhängig von ihren Abmessungen identisch und jede wird so scharf gerendert, wie es die Anzeigedichte des Nutzers zulässt. Anstatt jedoch large.jpg für jeden Nutzer bereitzustellen, um die größten Darstellungsbereiche und Displays mit der höchsten Punktdichte zu berücksichtigen, wird Nutzern immer der kleinste geeignete Kandidat angezeigt.
Wenn Sie eine beschreibende Syntax anstelle einer vorgeschriebenen Syntax verwenden, müssen Sie nicht manuell Haltepunkte festlegen und zukünftige Darstellungsbereiche und DVRs nicht berücksichtigen. Sie stellen einfach dem Browser Informationen bereit und lassen ihn die Antworten für Sie ermitteln.
Da der sizes-Wert relativ zum Darstellungsbereich und völlig unabhängig vom Seitenlayout ist, entsteht eine zusätzliche Ebene.
Es kommt selten vor, dass ein Bild nur einen Prozentsatz des Darstellungsbereichs einnimmt, ohne Ränder mit fester Breite, keinen Abstand oder Einfluss anderer Elemente auf der Seite. Häufig müssen Sie die Breite eines Bildes mithilfe einer Kombination aus Einheiten, Prozentsätzen, em, px usw. ausdrücken.
Glücklicherweise können Sie hier calc() verwenden. Alle Browser mit nativer Unterstützung für responsive Bilder unterstützen auch calc(). Dadurch können wir CSS-Einheiten kombinieren, z. B. ein Bild, das die gesamte Breite des Darstellungsbereichs des Nutzers abzüglich eines 1em-Randes auf beiden Seiten einnimmt:
<img
sizes="calc(100vw-2em)"
srcset="small.jpg 400w, medium.jpg 800w, large.jpg 1600w, x-large.jpg 2400w"
src="fallback.jpg"
alt="...">
Haltepunkte beschreiben
Wenn Sie viel Zeit mit responsiven Layouts verbracht haben, ist Ihnen wahrscheinlich aufgefallen, dass in diesen Beispielen etwas fehlt: Der Platz, den ein Bild in einem Layout einnimmt, ändert sich sehr wahrscheinlich über die Haltepunkte unseres Layouts. In diesem Fall müssen Sie etwas mehr Details an den Browser übergeben: sizes akzeptiert durch Kommas getrennte Kandidaten für die gerenderte Größe des Bildes, ebenso wie srcset durch Kommas getrennte Kandidaten für Bildquellen. Für diese Bedingungen wird die vertraute Syntax von Medienabfragen verwendet.
Diese Syntax ist „First-Match“: Sobald eine Medienbedingung erfüllt ist, beendet der Browser das Parsen des sizes-Attributs und der angegebene Wert wird angewendet.
Angenommen, ein Bild soll 80% des Darstellungsbereichs einnehmen, abzüglich eines em Abstands auf beiden Seiten, bei Darstellungsbereichen über 1.200 Pixeln. Bei kleineren Darstellungsbereichen nimmt es die gesamte Breite des Darstellungsbereichs ein.
<img
sizes="(min-width: 1200px) calc(80vw - 2em), 100vw"
srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 2000w"
src="fallback.jpg"
alt="...">
Wenn der Darstellungsbereich des Nutzers größer als 1.200 Pixel ist, beschreibt calc(80vw - 2em) die Breite des Bilds in unserem Layout. Wenn die Bedingung (min-width: 1200px) nicht erfüllt ist, fährt der Browser mit dem nächsten Wert fort. Da an diesen Wert keine bestimmte Medienbedingung gebunden ist, wird 100vw als Standard verwendet. Wenn Sie dieses sizes-Attribut mit max-width-Medienabfragen schreiben würden:
<img
sizes="(max-width: 1200px) 100vw, calc(80vw - 2em)"
srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 2000w"
src="fallback.jpg"
alt="...">
Klar formulierter Text: „Stimmt (max-width: 1200px) überein? Wenn nicht, fahren Sie fort. Der nächste Wert – calc(80vw - 2em) – hat keine gültige Bedingung, daher ist dies die ausgewählte Bedingung.
Nachdem Sie dem Browser alle Informationen zu Ihrem img-Element bereitgestellt haben – potenzielle Quellen, inhärente Breiten und die Art und Weise, wie Sie das Bild dem Nutzer präsentieren – verwendet der Browser eine Reihe ungenauer Regeln, um zu bestimmen, was mit diesen Informationen geschehen soll. Wenn das vage klingt, liegt das daran, dass es so ist. Der in der HTML-Spezifikation codierte Quellenauswahlalgorithmus gibt explizit vage an, wie eine Quelle ausgewählt werden soll. Nachdem die Quellen, ihre Deskriptoren und das Rendering des Bildes geparst wurden, kann der Browser alles tun, was er möchte. Sie können nicht genau wissen, welche Quelle der Browser auswählt.
Eine Syntax, die besagt, dass „Diese Quelle auf einem hochauflösenden Display verwenden“ besagt, wäre vorhersehbar, würde aber nicht das Kernproblem bei Bildern in einem responsiven Layout angehen: die Einsparung von Bandbreite für den Nutzer. Die Pixeldichte eines Bildschirms steht nur tangentlich mit der Geschwindigkeit der Internetverbindung zusammen. Wenn Sie einen Top-Laptop verwenden, aber über eine gebührenpflichtige Verbindung, per Tethering mit Ihrem Smartphone oder über eine unruhige WLAN-Verbindung im Flugzeug surfen, sollten Sie unabhängig von der Qualität des Bildschirms die hochauflösenden Bildquellen deaktivieren.
Die endgültige Entscheidung dem Browser zu überlassen, ermöglicht weit mehr Leistungsverbesserungen, als wir mit einer strikt präskriptiven Syntax schaffen könnten. Beispiel: In den meisten Browsern fordert ein img mit der Syntax srcset oder sizes niemals eine Quelle an, die kleinere Abmessungen als eine Quelle anfordert, die der Nutzer bereits im Cache des Browsers hat. Welchen Sinn würde es haben, eine neue Anfrage für eine identisch aussehende Quelle zu senden, wenn der Browser die bereits vorhandene Bildquelle nahtlos herunterskalieren kann? Wenn der Nutzer jedoch seinen Darstellungsbereich so weit skaliert, dass ein neues Bild benötigt wird, um eine Hochskalierung zu vermeiden, wird diese Anfrage trotzdem gestellt, sodass alles so aussieht, wie Sie es erwarten.
Dieser Mangel an expliziter Kontrolle kann zwar auf den ersten Blick beängstigend klingen, aber da Sie Quelldateien mit identischen Inhalten verwenden, ist die Wahrscheinlichkeit, dass Nutzer defekt sind, genauso groß wie bei einer src-Quelle aus einer einzigen Quelle – unabhängig von den Entscheidungen des Browsers.
sizes und srcset verwenden
Das ist eine Menge Informationen – sowohl für Sie als Leser als auch für den Browser. srcset und sizes sind beide sehr dichte Syntaxen, die eine schockierende Menge an Informationen in relativ wenigen Zeichen beschreiben. Das heißt, im wahrsten Sinne des Wortes: Wenn diese Syntaxen weniger knapp gehalten und von uns Menschen leichter geparst werden könnten, hätte sie für einen Browser schwieriger zu parsen sein. Je komplexer ein String, desto größer ist das Risiko für Parserfehler oder unbeabsichtigte Unterschiede im Verhalten von einem Browser zum anderen. Dies hat jedoch einen Vorteil: Eine Syntax, die von Maschinen leichter gelesen werden kann, ist eine Syntax, die von diesen einfacher geschrieben wird.
srcset ist ein eindeutiges Beispiel für Automatisierung. Es kommt selten vor, dass Sie mehrere Versionen Ihrer Images für eine Produktionsumgebung manuell erstellen, anstatt den Prozess stattdessen mit einem Task-Runner wie Gulp, einem Bundler wie Webpack, einem Drittanbieter-CDN wie Cloudinary oder einer Funktion zu automatisieren, die bereits in ein CMS Ihrer Wahl integriert ist. Wenn genügend Informationen vorhanden sind, um unsere Quellen zu generieren, hätte ein System genügend Informationen, um sie in ein brauchbares srcset-Attribut zu schreiben.
sizes ist etwas schwieriger zu automatisieren. Wie Sie wissen, kann ein System die Größe eines Bildes in einem gerenderten Layout nur dann berechnen, wenn das Layout gerendert wird. Glücklicherweise gibt es mehrere Entwicklertools, die die handschriftlichen sizes-Attribute abstrahieren – und das mit einer Effizienz, die von Hand nie möglich wäre. respImageLint ist beispielsweise ein Code-Snippet, das dazu dient, die Genauigkeit Ihrer sizes-Attribute zu überprüfen und Verbesserungsvorschläge zu machen. Beim Projekt Lazysizes wird die Effizienz beeinträchtigt, da Bildanfragen erst nach der Einrichtung des Layouts zurückgestellt werden, sodass JavaScript sizes-Werte für Sie generieren kann. Wenn Sie ein vollständig clientseitiges Rendering-Framework wie React oder Vue verwenden, gibt es verschiedene Lösungen zum Erstellen und/oder Generieren der srcset- und sizes-Attribute. Diese werden im Abschnitt CMS und Frameworks näher erläutert.