Lazy Loading auf Browserebene für CMS

Erkenntnisse zur Verwendung des standardisierten Ladeattributs

Felix Arntz
Felix Arntz

Mit diesem Beitrag möchte ich die Entwickler und Beitragenden von CMS-Plattformen (z.B. die Entwickelnden von CMS-Kernen) davon überzeugen, dass es jetzt an der Zeit ist, die Unterstützung für das Lazy Loading von Bildern auf Browserebene zu implementieren. Außerdem gebe ich Ihnen Empfehlungen dazu, wie Sie für eine hohe Nutzerfreundlichkeit sorgen und Anpassungen durch andere Entwickler ermöglichen können, wenn Sie Lazy Loading implementieren. Diese Richtlinien basieren auf unserer Erfahrung beim Hinzufügen von Unterstützung für WordPress sowie beim Implementieren der Funktion bei Joomla, Drupal und TYPO3.

Unabhängig davon, ob du CMS-Plattform-Entwickler oder CMS-Nutzer bist (d.h. Websites mit CMS erstellt), kannst du in diesem Beitrag mehr über die Vorteile des Lazy Loading auf Browserebene in deinem CMS erfahren. Im Abschnitt Nächste Schritte findest du Vorschläge, wie du deine CMS-Plattform für die Implementierung von Lazy Loading unterstützen kannst.

Hintergrund

Im vergangenen Jahr ist Lazy Loading von Bildern und iFrames mit dem Attribut loading Teil des WHATWG-HTML-Standards und in verschiedenen Browsern immer häufiger durchgesetzt. Diese Meilensteine bilden jedoch nur den Grundstein für ein schnelleres und ressourcensparendes Web. Jetzt ist er in der verteilten Webumgebung verfügbar, sodass das Attribut loading genutzt werden kann.

Content-Management-Systeme machen etwa 60% der Websites aus, sodass diese Plattformen eine wichtige Rolle bei der Einführung moderner Browserfunktionen im Web spielen. Einige beliebte Open-Source-CMS wie WordPress, Joomla und TYPO3 unterstützen das Attribut loading bereits bei Bildern. Sehen wir uns nun ihre Ansätze und die Erkenntnisse an, die auch für die Einführung der Funktion in anderen CMS-Plattformen relevant sind. Lazy Loading von Medien ist eine wichtige Funktion für die Webleistung, von der Websites in großem Umfang profitieren sollten. Daher wird empfohlen, es auf der CMS-Kernebene zu verwenden.

Beispiel für die Implementierung von Lazy Loading

Standardisierung

Die Einführung nicht standardisierter Browserfunktionen in CMS erleichtert umfassende Tests und kann Verbesserungsmöglichkeiten aufzeigen. Die allgemeine Meinung ist jedoch, dass, solange eine Browserfunktion nicht standardisiert ist, vorzugsweise in Form einer Erweiterung oder eines Plug-ins für die jeweilige Plattform implementiert werden sollte. Erst nach der Standardisierung kann eine Funktion für die Einführung im Plattformkern in Betracht gezogen werden.

Unterstützte Browser

Ähnlich verhält es sich mit der Browserunterstützung für die Funktion: Die Mehrheit der CMS-Nutzer sollte die Vorteile dieser Funktion nutzen können. Wenn die Funktion bei einem erheblichen Prozentsatz der Browser noch nicht unterstützt wird, muss sie zumindest dafür sorgen, dass sie zumindest keine negativen Auswirkungen auf diese Browser hat.

Grenzwerte für „Distance-of-viewport“

Ein häufiges Problem bei Lazy Loading-Implementierungen besteht darin, dass sie im Prinzip die Wahrscheinlichkeit erhöhen, dass ein Bild nicht geladen wird, sobald es im Darstellungsbereich des Nutzers sichtbar wird, da der Ladezyklus später beginnt. Im Gegensatz zu früheren JavaScript-basierten Lösungen gehen Browser konservativ an diesen Ansatz und können diesen Ansatz außerdem anhand realer Daten zur Nutzererfahrung optimieren, um die Auswirkungen zu minimieren. Lazy Loading sollte daher für CMS-Plattformen sicher auf Browserebene eingesetzt werden.

Empfehlungen zur Nutzererfahrung

Dimensionsattribute für Elemente verlangen

Um Layoutverschiebungen zu vermeiden, wird schon lange empfohlen, eingebettete Inhalte wie Bilder oder iFrames immer die Dimensionsattribute width und height zu enthalten. So kann der Browser das Seitenverhältnis dieser Elemente ableiten, bevor sie tatsächlich geladen werden. Diese Empfehlung ist unabhängig davon relevant, ob ein Element Lazy Loading ist oder nicht. Aufgrund der 0,1% höheren Wahrscheinlichkeit, dass ein Bild einmal im Darstellungsbereich nicht vollständig geladen wird, ist dies bei Lazy Loading jedoch etwas besser anwendbar.

CMS sollten vorzugsweise Dimensionsattribute für alle Bilder und iFrames bereitstellen. Wenn dies nicht für jedes dieser Elemente möglich ist, wird empfohlen, Lazy Loading von Bildern zu überspringen, die nicht beide Attribute enthalten.

Lazy Loading von „above the fold“-Elementen vermeiden

Derzeit wird für CMS empfohlen, loading="lazy"-Attribute nur Bildern und iFrames hinzuzufügen, die „below the fold“ (mit Scrollen sichtbar) platziert sind. So lassen sich Verzögerungen beim Messwert Largest Contentful Paint vermeiden, die im Juli 2021 in einigen Fällen signifikant sein können. Allerdings ist es komplex, die Position eines Elements im Verhältnis zum Darstellungsbereich vor dem Rendering zu beurteilen. Dies gilt insbesondere, wenn das CMS einen automatisierten Ansatz zum Hinzufügen von loading-Attributen verwendet, aber auch bei manuellen Eingriffen müssen mehrere Faktoren wie die unterschiedlichen Größen und Seitenverhältnisse des Darstellungsbereichs berücksichtigt werden. Dennoch wird dringend empfohlen, Hero-Images und andere Bilder oder iFrames, die ohne Scrollen sichtbar sind, von Lazy Loading zu verzichten.

JavaScript-Fallback vermeiden

Zwar kann JavaScript verwendet werden, um Browsern, die das loading-Attribut (noch) nicht unterstützen, Lazy Loading zu verwenden. Bei diesen Mechanismen muss jedoch immer zuerst das src-Attribut eines Bildes oder iFrames entfernt werden. Dadurch kommt es bei den Browsern, die das Attribut unterstützen, zu einer Verzögerung. Darüber hinaus vergrößert sich durch die Einführung einer solchen JavaScript-basierten Lösung in den Front-Ends eines umfangreichen CMS die Oberfläche für potenzielle Probleme. Dies ist einer der Gründe, warum bei keinem großen CMS Lazy Loading vor der standardisierten Browserfunktion im Kern eingeführt wurde.

Technische Empfehlungen

Lazy Loading standardmäßig aktivieren

Die allgemeine Empfehlung für CMS, die Lazy Loading auf Browserebene implementieren, besteht darin, diese Funktion standardmäßig zu aktivieren. d. h., loading="lazy" sollte Bildern und iFrames hinzugefügt werden, vorzugsweise nur für die Elemente mit Dimensionsattributen. Die standardmäßige Aktivierung der Funktion führt zu größeren Einsparungen bei den Netzwerkressourcen als bei einer manuellen Aktivierung, z. B. pro Image.

Soweit möglich sollte loading="lazy" nur Elementen hinzugefügt werden, die „below the fold“ (mit Scrollen sichtbar) erscheinen. Diese Anforderung kann für ein CMS komplex sein, da clientseitige Bekanntheit und verschiedene Größen des Darstellungsbereichs fehlen. Es wird jedoch empfohlen, zumindest ungefähre Heuristiken zu verwenden, um Elemente wie Hero-Images, die wahrscheinlich „above the fold“ erscheinen, nicht als Lazy Loading zu verwenden.

Änderungen pro Element zulassen

Obwohl loading="lazy" standardmäßig zu Bildern und iFrames hinzugefügt werden sollte, muss das Attribut bei bestimmten Bildern unbedingt weggelassen werden, um beispielsweise eine Optimierung für LCP vorzunehmen. Wenn die Zielgruppe des CMS im Durchschnitt technisch versiert ist, könnte dies ein UI-Steuerelement sein, das für jedes Bild und jeden iFrame verfügbar ist, um Lazy Loading für dieses Element zu deaktivieren. Alternativ oder zusätzlich kann eine API auch Drittanbietern zugänglich gemacht werden, damit diese über Code ähnliche Änderungen vornehmen können.

WordPress ermöglicht beispielsweise, das Attribut loading entweder für ein gesamtes HTML-Tag oder Kontext oder für ein bestimmtes HTML-Element im Inhalt zu überspringen.

Nachrüstung vorhandener Inhalte

Grundsätzlich gibt es zwei Ansätze, um HTML-Elementen in einem CMS das Attribut loading hinzuzufügen:

  • Fügen Sie das Attribut entweder aus dem Inhaltseditor im Back-End hinzu und speichern Sie es dauerhaft in der Datenbank.
  • Fügen Sie das Attribut direkt hinzu, wenn Sie Inhalte aus der Datenbank im Front-End rendern.

Es wird empfohlen, dass das CMS das Attribut beim Rendern spontan hinzufügt, um die Vorteile des Lazy Loading auch für vorhandene Inhalte nutzen zu können. Wenn das Attribut nur über den Editor hinzugefügt werden könnte, würden nur neue oder kürzlich geänderte Inhalte davon profitieren. Dadurch würde das CMS die Einsparung von Netzwerkressourcen erheblich reduzieren. Außerdem lassen sich durch das spontane Hinzufügen des Attributs künftige Änderungen ganz einfach vornehmen, falls die Funktionen für Lazy Loading auf Browserebene weiter ausgeweitet werden.

Wenn das Attribut spontan hinzugefügt wird, sollte jedoch ein potenziell vorhandenes loading-Attribut für ein Element berücksichtigt werden, sodass dieses Attribut Vorrang hat. Auf diese Weise kann mit dem CMS oder einer entsprechenden Erweiterung auch der Editor-orientierte Ansatz implementiert werden, ohne dass es zu einem Konflikt mit doppelten Attributen kommt.

Serverseitige Leistung optimieren

Wenn Sie Inhalten das Attribut loading spontan hinzufügen, z. B. mithilfe einer serverseitigen Middleware, spielt Geschwindigkeit eine Rolle. Je nach CMS kann das Attribut entweder über einen DOM-Durchlauf oder über reguläre Ausdrücke hinzugefügt werden, wobei Letzteres empfohlen wird, um die Leistung zu steigern.

Die Verwendung regulärer Ausdrücke sollte auf ein Minimum beschränkt werden, z. B. ein einzelner Regex, der alle img- und iframe-Tags im Inhalt einschließlich ihrer Attribute erfasst und dann das loading-Attribut jedem Tag-String bei Bedarf hinzufügt. WordPress bietet beispielsweise einen einzigen allgemeinen regulären Ausdruck, mit dem verschiedene spontane Vorgänge für bestimmte Elemente ausgeführt werden können, wobei das Hinzufügen von loading="lazy" nur eine ist. Ein regulärer Ausdruck ist erforderlich, um mehrere Funktionen zu ermöglichen. Diese Form der Optimierung ist ein weiterer Grund, warum Lazy Loading im Kern eines CMS gegenüber einer Erweiterung empfohlen wird. Sie ermöglicht eine bessere serverseitige Leistungsoptimierung.

Weitere Informationen

Prüfe, ob es bereits ein Anfrage-Ticket für eine Funktion gibt, um Support für die Funktion in deinem CMS hinzuzufügen, oder eröffne ein neues, falls noch nicht vorhanden. Untermauern Sie Ihren Vorschlag bei Bedarf mit Verweisen auf diesen Beitrag.

Sie können mir einen Tweet an (felixarntz@) senden, wenn Sie Fragen oder Kommentare haben oder Ihr CMS auf dieser Seite auflisten lassen möchten, wenn das Lazy Loading auf Browserebene unterstützt wird. Ich bin auch neugierig darauf, mehr darüber zu erfahren, um hoffentlich eine Lösung zu finden.

Wenn Sie ein CMS-Plattform-Entwickler sind, sehen Sie sich an, wie andere CMS Lazy Loading implementieren:

Sie können die Erkenntnisse aus Ihrer Forschung und die technischen Empfehlungen in diesem Beitrag nutzen, um Code zu Ihrem CMS hinzuzufügen, z. B. in Form einer Patch- oder Pull-Anfrage.

Hero-Foto von Colin Watts auf Unsplash