Derzeit sind Bilder die größten Assets im Web, sowohl was die Gesamtübertragungsgröße als auch die Anzahl der Anfragen pro Seite angeht. Die mittlere Übertragungsgröße der Webseite beträgt etwa 2 MB (Stand Juni 2022), wobei fast die Hälfte davon auf Bilder ausmacht. Man kann ohne Übertreibung sagen, dass die Optimierung von Bildanfragen die größte Leistungsoptimierung ist, die möglich ist.
Später erfahren Sie, wie sich responsive Bilder weiterentwickelt haben, um die Probleme zu lösen, bei denen versucht wurde, für alle Fälle ein Bild auszuliefern. In diesem Abschnitt erfahren Sie mehr über die wichtigsten Leistungsmesswerte zu Bildern und darüber, wie Sie sie verbessern können.
Bildanfragen zurückstellen
Sie lernen nun eine Reihe von Möglichkeiten kennen, wie Sie dafür sorgen können, dass Ihre Bildanfragen so klein und effizient wie möglich sind. Die schnellste Bildanfrage ist jedoch immer die, die nie ausgeführt wird. Zunächst möchte ich Ihnen zeigen, welche Änderung Sie an der Bereitstellung von Bild-Assets für Nutzer möglicherweise am stärksten beeinflussen können: das Attribut loading="lazy".
<img src="image.jpg" loading="lazy" alt="…">
Dieses Attribut sorgt dafür, dass Anfragen für Bilder erst gesendet werden, wenn sie sich in der Nähe des Darstellungsbereichs des Nutzers befinden. Dabei werden die Anfragen vom ersten Seitenaufbau – dem Zeitpunkt, an dem der Browser die meisten Zugriffe hat – zurückgestellt und diese Anfragen aus dem kritischen Rendering-Pfad entfernt.
In der Praxis kann die Verwendung dieses Attributs einen enormen positiven Einfluss auf die Leistung haben: Ein Bild, das nie in den Darstellungsbereich des Nutzers fällt, wird nie angefordert, und es wird keine Bandbreite für Bilder verschwendet, die der Nutzer nie sehen wird.
Es gibt jedoch einen Haken: Wenn Sie diese Anfragen zurückstellen, werden die hyperoptimierten Prozesse des Browsers für die Anforderung von Bildern so früh wie möglich nicht genutzt. Wenn loading="lazy" für img-Elemente oben im Layout verwendet wird und sich daher beim ersten Laden der Seite im Darstellungsbereich des Nutzers befinden, können diese Bilder für den Endnutzer deutlich langsamer erscheinen.
Priorität abrufen
Das loading-Attribut ist ein Beispiel für eine größere Bemühung von Webstandards, Entwicklern mehr Kontrolle über die Priorisierung von Anfragen durch Webbrowser zu geben.
Wahrscheinlich sind Sie mit den grundlegenden Ansätzen zum Abrufen der Priorität von Browsern vertraut: Beispielsweise wird die Anfrage für eine externe CSS-Datei im <head> eines Dokuments als ausreichend erachtet, um das Rendering zu blockieren. Eine Anfrage für eine externe JavaScript-Datei kurz über </body> wird hingegen zurückgestellt, bis das Rendering abgeschlossen ist. Wenn der Wert eines loading-Attributs für eine <img> „lazy“ (lazy) ist, wird die zugehörige Bildanfrage so lange zurückgestellt, bis der Browser bestimmt, dass sie einem Nutzer angezeigt wird. Andernfalls hat dieses Image dieselbe Priorität wie jedes andere Image auf der Seite.
Das Attribut fetchpriority soll Entwicklern eine genauere Kontrolle über die Priorität von Assets geben. So können Sie Ressourcen im Verhältnis zu Ressourcen desselben Typs mit hoher und niedriger Priorität kennzeichnen. Die Anwendungsfälle für fetchpriority ähneln dem Attribut loading, sind aber viel allgemeiner. Sie können beispielsweise fetchpriority="low" für ein Bild verwenden, das nur nach einer Nutzerinteraktion erkannt wird (unabhängig davon, ob das Bild in den Darstellungsbereich des Nutzers fällt oder nicht), um sichtbare Bilder an anderer Stelle auf der Seite zu priorisieren, oder fetchpriority="high", um ein Bild zu priorisieren, das sofort nach dem Rendern der Seite im Darstellungsbereich sichtbar ist.
Beachten Sie, dass sich fetchpriority von loading insofern unterscheidet, als dass es das Browserverhalten nicht grundlegend verändert. Er weist den Browser nicht an, bestimmte Assets vor anderen zu laden, sondern liefert ihm wichtigen Kontext für die Entscheidungen, die er bei der Anforderung von Assets trifft.
Wirkung von Bildern messen
Bei der Optimierung von Bild-Assets ist die wahrgenommene Leistung häufig wichtiger und schwieriger zu messen als die Gesamtübertragungsgröße allein.
Web Vitals bietet messbare, umsetzbare Messwerte und Anleitungen zur Verbesserung der Nutzererfahrung im Web. Dabei werden Probleme wie langsame Antwortzeiten von einem Webserver, Rendering-Probleme und Verzögerungen bei der Interaktivität hervorgehoben. Core Web Vitals ist eine Teilmenge dieser Ziele. Der Schwerpunkt liegt dabei darauf, wie schnell der Nutzer eine Seite sieht – eine Reihe technischer Messwerte, die zusammen bestimmen, wie schnell sich eine Website oder App für einen Nutzer anfühlt.
Cumulative Layout Shift
Cumulative Layout Shift (CLS) ist ein Maß für die visuelle Stabilität. Er ist ein Messwert, mit dem erfasst wird, wie stark sich das Layout des Inhalts auf einer Seite verschiebt, wenn Assets geladen und die Seite gerendert wird. Jeder, der viel Zeit im Web verbracht hat, ist in einer langen Textausführung verloren gegangen, weil eine Seite „springt“, da eine verzögerte Webfont- oder Bildquelle plötzlich gerendert wird oder ein interaktives Element plötzlich von Ihrem Mauszeiger wegbewegt wird. Ein hoher CLS-Wert ist im Idealfall ein lästiges Ärgernis und im schlimmsten Fall die Ursache eines Nutzerfehlers. Beispielsweise verschiebt sich die Schaltfläche „Abbrechen“ in einen Bereich, der zuvor eine Bestätigungsschaltfläche einnimmt, während der Nutzer darauf klickt.
Bei langen Ladezeiten und dem großen Platz, den sie in einem Layout belegen können, sind Bilder eine häufige Ursache für hohe CLS-Werte.
Dank der relativ aktuellen Änderungen in modernen Browsern ist es einfacher, als Sie vielleicht denken, hohe CLS-Werte aufgrund von Bildern zu vermeiden.
Wenn Sie seit einigen Jahren am Front-End arbeiten, sind Sie mit den Attributen width und height in <img> vertraut. Vor der weit verbreiteten Einführung von CSS waren diese die einzige Möglichkeit, die Größe eines Bildes zu steuern.
<img src="image.jpg" height="200" width="400" alt="…">
Diese Attribute wurden nicht mehr verwendet, um unsere Stilbedenken von unserem Markup getrennt zu halten, insbesondere da bei responsivem Webdesign eine prozentbasierte Größenanpassung über CSS angegeben werden musste. In den Anfängen des responsiven Webdesigns wurde häufig empfohlen, die nicht verwendeten Attribute width und height zu entfernen, da sie durch die in unserem CSS angegebenen Werte max-width: 100% und height: auto überschrieben würden.
<img src="image.jpg" alt="…">
img {
max-width: 100%;
height: auto;
}
Nachdem die Attribute height und width wie im vorherigen Beispiel entfernt wurden, hat der Browser in diesem Fall die einzige Methode, die Höhe des Bildes zu bestimmen, nämlich darin, die Quelle anzufordern, zu parsen und in ihrem inhärenten Seitenverhältnis zu rendern. Dies richtet sich nach der Breite des Platzes, den er im Layout einnimmt, nachdem Stylesheets angewendet wurden. Ein Großteil dieses Prozesses findet nach dem Rendern der Seite statt, wobei die neu berechnete Höhe zusätzliche Layoutverschiebungen verursacht.
Seit 2019 wurde das Browserverhalten aktualisiert, um die Attribute width und height anders zu verarbeiten. Anstatt die Werte dieser Attribute zu verwenden, um die feste, pixelbasierte Größe eines img-Elements im Layout zu bestimmen, kann angenommen werden, dass diese Attribute das Seitenverhältnis des Bildes darstellen, auch wenn die Syntax gleich ist. Moderne Browser dividieren diese Werte untereinander, um das img intrinsische Seitenverhältnis eines Elements vor dem Rendern der Seite zu bestimmen und so den Platz zu reservieren, den das Bild beim Rendern des Layouts einnehmen wird.
In der Regel sollten Sie für <img> immer die Attribute height und width mit Werten verwenden, die der intrinsischen Größe Ihrer Bildquelle entsprechen. Achten Sie jedoch darauf, dass Sie height: auto zusammen mit max-width: 100% angegeben haben, um die Höhe im HTML-Attribut zu überschreiben.
<img src="image.jpg" height="200" width="400" alt="…">
img {
max-width: 100%;
height: auto;
}
Wenn du die Attribute width und height für deine <img>-Elemente verwendest, vermeidest du einen hohen CLS-Wert aufgrund von Bildern.
Wichtig: Diese Methode hat keine Nachteile, da sie auf dem bewährten Browserverhalten basiert. Jeder Browser, der grundlegende CSS unterstützt, funktioniert wie gewohnt, wobei die height- und width-Attribute im Markup durch die Stile überschrieben werden.
Mit den Attributen width und height lassen sich CLS-Probleme effektiv vermeiden, da der erforderliche Layoutplatz für Ihre Bilder reserviert wird. Wenn Nutzer aber eine leere Lücke oder einen Platzhalter von geringer Qualität haben, während sie auf die Übertragung und das Rendering eines Bildes warten, ist das ebenfalls nicht ideal. Es gibt zwar Dinge, die Sie tun können, um die messbaren und wahrnehmbaren Auswirkungen von langsam ladenden Bildern abzuschwächen. Die einzige Möglichkeit, einem Nutzer ein vollständig gerendertes Bild schneller darzustellen, ist die Reduzierung der Übertragungsgröße.
Largest Contentful Paint
Largest Contentful Paint (LCP) gibt an, wie lange es dauert, das größte „contentful“-Element zu rendern, das im Darstellungsbereich des Nutzers sichtbar ist – das Inhaltselement, das den größten Prozentsatz der sichtbaren Seite einnimmt. Auf den ersten Blick mag es wie ein zu spezifischer Messwert erscheinen. Aus Sicht des Nutzers dient dieses Element jedoch als praktischer Stellvertreter für den Punkt, an dem der Großteil der Seite gerendert wurde. Der LCP ist ein wichtiges Maß für die (wahrgenommene) Leistung.
Messwerte wie DOMContentLoaded oder window.onload können nützlich sein, um festzustellen, wann das Laden der aktuellen Seite technisch abgeschlossen ist. Sie entsprechen jedoch nicht unbedingt der Nutzerfreundlichkeit der Seite. Eine geringe Verzögerung beim Rendern eines Elements außerhalb des Darstellungsbereichs des Nutzers wird bei einem dieser Messwerte berücksichtigt, würde jedoch von realen Nutzern wahrscheinlich völlig unentdeckt bleiben.
Ein langer LCP bedeutet, dass der erste Eindruck des Nutzers von einer Seite – dem wichtigsten Inhalt im aktuellen Darstellungsbereich – der erste Eindruck ist, dass die Seite langsam oder vollständig unterbrochen ist.
Die vom LCP erfasste Wahrnehmung der Nutzer wirkt sich direkt auf die Nutzererfahrung aus. Vodafone hat im letzten Jahr einen Test durchgeführt, der Folgendes ergab: Eine Verbesserung des LCP um 31% führte nicht nur zu einem Umsatzplus von 8 % – ein starkes Ergebnis, sondern auch eine Verbesserung der Gesamtzahl der Nutzer um 15 % bei potenziellen Kunden ("Besucher-zu-Lead-Rate") und eine um 11% höhere Anzahl der Nutzer, die ihren Einkaufswagen besucht haben.
Auf mehr als 70% der Webseiten enthält das größte Element im ersten Darstellungsbereich ein Bild – entweder als eigenständiges <img>-Element oder als Element mit Hintergrundbild. Mit anderen Worten:
70% der LCP-Werte von Seiten basieren auf der Bildleistung. Warum das so ist, erfordert keine viel Vorstellungskraft: Große, auffällige Bilder und Logos sind sehr wahrscheinlich „above the fold“ zu finden.
LCP-Verzögerungen lassen sich mit folgenden Maßnahmen vermeiden: Geben Sie für ein Bild, das ohne Scrollen sichtbar ist, niemals loading="lazy" an. Wenn Sie die Anfrage erst nach dem Rendern der Seite verzögern, hat dies wahrscheinlich erhebliche negative Auswirkungen auf Ihren LCP-Wert.
Zweitens kann die Verwendung von fetchpriority="high" dem Browser mitteilen, dass die Übertragung dieses Bildes gegenüber Bildern an anderer Stelle auf der Seite priorisiert werden soll.
Wenn ihr diese Regeln beachtet, ist das Wichtigste, was ihr tun könnt, um den LCP-Wert einer Seite zu verbessern, indem ihr die Zeit für die Übertragung und das Rendern dieser Bilder reduziert. Dazu müssen Sie Ihre Bildquellen so klein und effizient wie möglich halten (natürlich ohne Qualitätseinbußen) und dafür sorgen, dass Nutzer nur die Bild-Assets erhalten, die für ihren Suchkontext am sinnvollsten sind.
Fazit
Bild-Assets belasten die Bandbreite Ihrer Nutzer am stärksten, da bei der Übertragung aller anderen Assets, die zum Rendern einer Seite erforderlich sind, die Bandbreite weggenommen wird. Bilder können sowohl während als auch nach dem Rendern des umgebenden Seitenlayouts erhebliche Probleme in Bezug auf die wahrgenommene Leistung verursachen. Kurz gesagt: Bild-Assets schädigen.
Das mag beängstigend sein. Das heißt, „das Web wäre mit weniger Bildern besser geeignet“ würde schon allein in puncto Leistung wahr sein, aber es würde seinen Nutzern einen enormen Nachteil bereiten. Bilder sind ein wichtiger Bestandteil des Webs. Schon allein wegen der Leistung sollten Sie keine Abstriche bei der Qualität von sinnvollen Inhalten machen.
Im weiteren Verlauf dieses Kurses lernen Sie die Technologien kennen, die unseren Bild-Assets zugrunde liegen, und Techniken zur Minderung ihrer Leistungseinbußen, ohne die Qualität zu beeinträchtigen.