Lazy Loading auf Browserebene für CMS

Erkenntnisse aus der Einführung des standardisierten Attributs „Ladestation“

Felix Arntz
Felix Arntz

Mit diesem Beitrag möchte ich CMS-Plattformentwickler und ‑Mitarbeiter (d.h. die Personen, die CMS-Kernsysteme entwickeln) davon überzeugen, dass jetzt der richtige Zeitpunkt ist, die Unterstützung für die Lazy-Loading-Funktion für Bilder auf Browserebene zu implementieren. Außerdem gebe ich Empfehlungen, wie Sie beim Implementieren von Lazy Loading eine hohe Nutzerfreundlichkeit und die Anpassung durch andere Entwickler ermöglichen. Diese Richtlinien basieren auf unserer Erfahrung bei der Implementierung der Funktion in WordPress sowie bei der Unterstützung von Joomla, Drupal und TYPO3.

Unabhängig davon, ob Sie Entwickler einer CMS-Plattform oder CMS-Nutzer sind (d.h. eine Person, die Websites mit einem CMS erstellt), können Sie in diesem Beitrag mehr über die Vorteile des Lazy-Loadings auf Browserebene in Ihrem CMS erfahren. Im Abschnitt Nächste Schritte finden Sie Vorschläge, wie Sie die CMS-Plattform dazu anregen können, Lazy Loading zu implementieren.

Hintergrund

Im letzten Jahr wurde das Lazy-Loading von Bildern und Iframes mit dem Attribut loading in den WHATWG-HTML-Standard aufgenommen und wird von immer mehr Browsern unterstützt. Diese Meilensteine bilden jedoch nur die Grundlage für ein schnelleres und ressourcenschonenderes Web. Es liegt nun am verteilten Web-System, das loading-Attribut zu verwenden.

Content-Management-Systeme betreiben etwa 60% aller Websites. Daher spielen diese Plattformen eine wichtige Rolle bei der Einführung moderner Browserfunktionen im Web. Einige beliebte Open-Source-CMS wie WordPress, Joomla und TYPO3 unterstützen das loading-Attribut für Bilder bereits. Sehen wir uns an, wie diese CMS die Funktion implementiert haben und welche Erkenntnisse für die Einführung der Funktion in anderen CMS-Plattformen relevant sind. Das 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 CMS-Kernebene zu implementieren.

Argumente für die Implementierung von Lazy Loading

Standardisierung

Die Verwendung nicht standardisierter Browserfunktionen in CMSs ermöglicht umfassende Tests und kann potenzielle Verbesserungsmöglichkeiten aufzeigen. Die allgemeine Meinung unter CMS-Anbietern ist jedoch, dass eine Browserfunktion, die 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 Aufnahme in den Plattformkern in Betracht gezogen werden.

Unterstützte Browser

Die Browserunterstützung der Funktion ist ein ähnliches Problem: Die Mehrheit der CMS-Nutzer sollte von der Funktion profitieren können. Wenn die Funktion in einem erheblichen Prozentsatz der Browser noch nicht unterstützt wird, muss sie dafür sorgen, dass sie zumindest keine negativen Auswirkungen auf diese hat.

Grenzwerte für die Entfernung vom Darstellungsbereich

Ein häufiges Problem bei Lazy-Loading-Implementierungen besteht darin, dass die Wahrscheinlichkeit steigt, dass ein Bild nicht geladen wird, sobald es im Darstellungsbereich des Nutzers sichtbar wird, da der Ladezyklus erst später beginnt. Im Gegensatz zu früheren JavaScript-basierten Lösungen gehen Browser konservativ vor und können ihren Ansatz anhand von realen Nutzerdaten optimieren, um die Auswirkungen zu minimieren. Daher sollte das Lazy-Loading auf Browserebene für CMS-Plattformen sicher einsetzbar sein.

Empfehlungen zur Nutzerfreundlichkeit

Dimensionen für Elemente erforderlich

Um Layoutänderungen zu vermeiden, wird seit langem empfohlen, dass eingebettete Inhalte wie Bilder oder Iframes immer die Dimensionsattribute width und height enthalten sollten, damit der Browser das Seitenverhältnis dieser Elemente ableiten kann, bevor sie tatsächlich geladen werden. Diese Empfehlung gilt unabhängig davon, ob ein Element mit Lazy Loading geladen wird oder nicht. Da jedoch die Wahrscheinlichkeit, dass ein Bild im Viewport nicht vollständig geladen wird, um 0,1% höher ist, ist es mit Lazy Loading etwas besser geeignet.

CMS sollten vorzugsweise Größenattribute für alle Bilder und Iframes angeben. Wenn dies für jedes Element nicht möglich ist, sollten Bilder mit Lazy Loading, für die keines dieser beiden Attribute angegeben ist, übersprungen werden.

Lazy Loading von Above-the-Fold-Elementen vermeiden

Derzeit wird empfohlen, loading="lazy"-Attribute nur für Bilder und iFrames hinzuzufügen, die sich unterhalb des sichtbaren Bereichs befinden, um Verzögerungen beim Messwert Largest Contentful Paint zu vermeiden. Diese können in einigen Fällen erheblich sein, wie im Juli 2021 festgestellt. Es ist jedoch schwierig, die Position eines Elements vor dem Rendering-Prozess relativ zum Viewport 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 verschiedene Faktoren wie die verschiedenen Viewport-Größen und Seitenverhältnisse berücksichtigt werden. Wir empfehlen jedoch dringend, Hero-Bilder und andere Bilder oder Iframes, die wahrscheinlich im Above-the-Fold-Bereich erscheinen, vom Lazy-Loading auszuschließen.

JavaScript-Fallback vermeiden

Mit JavaScript kann Lazy Loading für Browser bereitgestellt werden, die das loading-Attribut (noch) nicht unterstützen. Bei solchen Mechanismen wird das src-Attribut eines Bilds oder Iframes jedoch immer zuerst entfernt, was bei Browsern, die das Attribut unterstützen, zu einer Verzögerung führt. Außerdem erhöht die Einführung einer solchen JavaScript-basierten Lösung in den Frontends eines groß angelegten CMS die Wahrscheinlichkeit potenzieller Probleme. Dies ist einer der Gründe, warum vor der standardisierten Browserfunktion kein größeres CMS Lazy Loading in seinem Kern implementiert hatte.

Technische Empfehlungen

Lazy Loading standardmäßig aktivieren

Wir empfehlen, Lazy Loading für CMS, die es auf Browserebene implementieren, standardmäßig zu aktivieren. Das bedeutet, dass loading="lazy" Bildern und Iframes hinzugefügt werden sollte, vorzugsweise nur für Elemente, die Dimensionsattribute enthalten. Wenn die Funktion standardmäßig aktiviert ist, können Sie mehr Netzwerkressourcen einsparen, als wenn sie manuell aktiviert werden müsste, z. B. pro Bild.

loading="lazy" sollte nach Möglichkeit nur Elementen hinzugefügt werden, die wahrscheinlich nicht im sichtbaren Bereich angezeigt werden. Diese Anforderung kann aufgrund fehlender clientseitiger Informationen und verschiedener Ansichtsgrößen für ein CMS komplex zu implementieren sein. Es wird jedoch empfohlen, zumindest ungefähre Heuristiken zu verwenden, um Elemente wie Hero-Bilder, die wahrscheinlich im Above-the-Fold-Bereich erscheinen, vom Lazy-Loading auszuschließen.

Änderungen pro Element zulassen

loading="lazy" sollte Bildern und Iframes standardmäßig hinzugefügt werden. Es ist jedoch wichtig, das Attribut für bestimmte Bilder wegzulassen, um beispielsweise für den LCP zu optimieren. Wenn die Zielgruppe des CMS im Durchschnitt als technisch versierter gilt, könnte dies ein UI-Steuerelement sein, das für jedes Bild und jeden Iframe angezeigt wird und mit dem sich das Lazy-Loading für dieses Element deaktivieren lässt. Alternativ oder zusätzlich kann eine API für Drittanbieter verfügbar gemacht werden, damit diese ähnliche Änderungen über Code vornehmen können.

In WordPress kann das loading-Attribut beispielsweise für ein ganzes HTML-Tag oder einen gesamten Kontext oder für ein bestimmtes HTML-Element im Inhalt übersprungen werden.

Vorhandene Inhalte nachrüsten

Es gibt zwei Möglichkeiten, HTML-Elementen in einem CMS das loading-Attribut hinzuzufügen:

  • Fügen Sie das Attribut entweder über den Inhaltseditor im Backend hinzu und speichern Sie es dauerhaft in der Datenbank.
  • Fügen Sie das Attribut „on the fly“ hinzu, wenn Sie Inhalte aus der Datenbank im Frontend rendern.

Wir empfehlen, das Attribut beim Rendern dynamisch hinzuzufügen, damit auch vorhandene Inhalte von den Vorteilen des Lazy Loadings profitieren. Wenn das Attribut nur über den Editor hinzugefügt werden könnte, würden nur neue oder vor Kurzem geänderte Inhalte davon profitieren. Die Auswirkungen des CMS auf die Einsparung von Netzwerkressourcen würden dadurch drastisch reduziert. Außerdem können zukünftige Änderungen ganz einfach vorgenommen werden, wenn die Funktionen des Lazy-Loadings auf Browserebene weiter ausgebaut werden.

Beim Hinzufügen des Attributs „on the fly“ sollte jedoch ein möglicherweise vorhandenes loading-Attribut für ein Element berücksichtigt werden und Vorrang haben. So kann das CMS oder eine Erweiterung dafür auch den editorgestützten Ansatz implementieren, ohne dass es zu Konflikten mit doppelten Attributen kommt.

Serverseitige Leistung optimieren

Wenn du das loading-Attribut Inhalten beispielsweise mithilfe einer serverseitigen Middleware „on the fly“ hinzufügst, ist die Geschwindigkeit ein wichtiger Faktor. Je nach CMS kann das Attribut entweder über die DOM-Durchsuchung oder mithilfe von regulären Ausdrücken hinzugefügt werden. Letzteres wird aus Leistungsgründen empfohlen.

Die Verwendung regulärer Ausdrücke sollte auf ein Minimum beschränkt werden. Beispiel: Ein einzelner regulärer Ausdruck, der alle img- und iframe-Tags im Inhalt einschließlich ihrer Attribute erfasst und dann jedem Tag-String nach Bedarf das loading-Attribut hinzufügt. WordPress verwendet beispielsweise einen einzigen allgemeinen regulären Ausdruck, um verschiedene On-the-fly-Vorgänge für bestimmte Elemente auszuführen, von denen das Hinzufügen von loading="lazy" nur einer ist. So werden mehrere Funktionen mit einem einzigen regulären Ausdruck ermöglicht. Diese Form der Optimierung ist ein weiterer Grund, warum das Lazy Loading im CMS-Kern anstelle einer Erweiterung empfohlen wird. So lässt sich die serverseitige Leistung besser optimieren.

Nächste Schritte

Prüfe, ob es bereits ein Ticket für einen Feature-Request gibt, um die Unterstützung für die Funktion in deinem CMS hinzuzufügen. Falls nicht, erstelle ein neues. Verwenden Sie nach Bedarf Verweise auf diesen Beitrag, um Ihren Vorschlag zu untermauern.

Wenn Sie Fragen oder Kommentare haben oder Ihr CMS auf dieser Seite aufgeführt haben möchten, weil es Lazy Loading auf Browserebene unterstützt, können Sie mir (felixarntz@) einen Tweet senden. Wenn Sie auf andere Probleme stoßen, würde ich mich auch gern darüber informieren, um Ihnen hoffentlich weiterhelfen zu können.

Wenn Sie Entwickler einer CMS-Plattform sind, sehen Sie sich an, wie andere CMSs Lazy Loading implementiert haben:

Sie können die Erkenntnisse aus Ihrer Recherche und die technischen Empfehlungen aus diesem Beitrag nutzen, um Code zu Ihrem CMS beizutragen, z. B. in Form eines Patches oder Pull-Requests.

Hero-Foto von Colin Watts auf Unsplash.