Erkenntnisse zur Übernahme des standardisierten Ladeattributs
Mit diesem Beitrag möchte ich CMS-Plattformentwickler und -Mitwirkende (also die Personen, die CMS-Kerne entwickeln) davon überzeugen, dass jetzt der richtige Zeitpunkt ist, um die Unterstützung für das Lazy Loading von Bildern auf Browserebene zu implementieren. Außerdem gebe ich Empfehlungen dazu, wie Sie beim Implementieren von Lazy Loading für eine hohe Nutzerfreundlichkeit sorgen und Anpassungen durch andere Entwickler ermöglichen können. Diese Richtlinien basieren auf unseren Erfahrungen mit der Unterstützung von WordPress und der Implementierung der Funktion in Joomla, Drupal und TYPO3.
Unabhängig davon, ob ihr CMS-Plattformentwickler oder CMS-Nutzer seid (also Websites mit einem CMS erstellt), könnt ihr in diesem Beitrag mehr über die Vorteile des Lazy Loadings auf Browserebene in eurem CMS erfahren. Im Abschnitt Nächste Schritte finden Sie Vorschläge, wie Sie die Implementierung von Lazy Loading auf Ihrer CMS-Plattform fördern können.
Hintergrund
Im letzten Jahr ist das Lazy Loading von Bildern und iFrames mit dem Attribut loading Teil des WHATWG-HTML-Standards geworden 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-Ökosystem, das Attribut loading zu verwenden.
Content-Management-Systeme werden auf etwa 60 % der Websites verwendet. Diese Plattformen spielen daher 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 ihre Ansätze und die Erkenntnisse an, die für die Übernahme der Funktion in andere 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, sie auf CMS-Kernebene zu übernehmen.
Argumente für die sofortige Implementierung von Lazy Loading
Standardisierung
Die Übernahme nicht standardisierter Browserfunktionen in CMS erleichtert umfassende Tests und kann potenzielle Verbesserungsmöglichkeiten aufzeigen. Der allgemeine Konsens bei CMS ist jedoch, dass eine Browserfunktion, solange sie nicht standardisiert ist, vorzugsweise in Form einer Erweiterung oder eines Plug-ins für die jeweilige Plattform implementiert werden sollte. Erst wenn eine Funktion standardisiert ist, kann sie 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 es einen erheblichen Prozentsatz von Browsern gibt, in denen die Funktion noch nicht unterstützt wird, muss die Funktion zumindest dafür sorgen, dass sie keine negativen Auswirkungen auf diese Browser hat.
Grenzwerte für den Abstand vom Darstellungsbereich
Ein häufiges Problem bei der Implementierung von Lazy Loading ist, dass die Wahrscheinlichkeit, dass ein Bild nicht geladen wird, wenn es im Darstellungsbereich des Nutzers sichtbar wird, grundsätzlich steigt, weil der Ladezyklus zu einem späteren Zeitpunkt beginnt. Im Gegensatz zu früheren JavaScript-basierten Lösungen gehen Browser hier konservativ vor und können ihren Ansatz außerdem anhand von realen Nutzererfahrungsdaten optimieren, um die Auswirkungen zu minimieren. Daher sollte das Lazy Loading auf Browserebene von CMS-Plattformen sicher übernommen werden können.
Empfehlungen zur Nutzerfreundlichkeit
Dimensionsattribute für Elemente erforderlich machen
Um Layoutverschiebungen zu vermeiden, wird seit Langem empfohlen, dass eingebettete Inhalte wie Bilder oder iFrames immer die Größenattribute width und height enthalten sollten, damit der Browser das Seitenverhältnis dieser Elemente ableiten kann, bevor er sie tatsächlich lädt. Diese Empfehlung ist relevant, unabhängig davon, ob ein Element per Lazy Loading geladen wird oder nicht. Aufgrund der 0,1 % höheren Wahrscheinlichkeit, dass ein Bild im Darstellungsbereich nicht vollständig geladen wird, ist es jedoch etwas besser geeignet, wenn Lazy Loading verwendet wird.
CMS sollten vorzugsweise Größenattribute für alle Bilder und iFrames bereitstellen. Wenn dies nicht für jedes dieser Elemente möglich ist, wird empfohlen, das Lazy Loading für Bilder zu überspringen, die nicht beide Attribute enthalten.
Lazy Loading für Above-the-Fold-Elemente vermeiden
Derzeit wird empfohlen, dass CMS nur loading="lazy"-Attribute zu Bildern und iFrames hinzufügen, die sich unterhalb der Seitenmitte befinden, um eine Verzögerung beim Messwert Largest Contentful Paint zu vermeiden, die in einigen Fällen erheblich sein kann, wie im Juli 2021 festgestellt wurde. Es ist jedoch schwierig, die Position eines Elements relativ zum Darstellungsbereich vor dem Rendering-Prozess zu beurteilen. Das 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 verschiedenen Darstellungsgrößen und Seitenverhältnisse berücksichtigt werden. Es wird jedoch dringend empfohlen, Hero-Bilder und andere Bilder oder iFrames, die wahrscheinlich im „Above the fold“-Bereich angezeigt werden, nicht per Lazy Loading zu laden.
JavaScript-Fallback vermeiden
Mit JavaScript kann zwar Lazy Loading für Browser bereitgestellt werden, die das Attribut loading (noch) nicht unterstützen, aber solche Mechanismen beruhen immer darauf, dass das Attribut src eines Bildes oder iFrames zuerst entfernt wird. Das führt zu einer Verzögerung bei Browsern, die das Attribut unterstützen. Darüber hinaus erhöht die Einführung einer solchen JavaScript-basierten Lösung in den Frontends eines großen CMS die Angriffsfläche für potenzielle Probleme. Das ist einer der Gründe, warum vor der Einführung der standardisierten Browserfunktion kein großes CMS Lazy Loading in seinen Kern integriert hatte.
Technische Empfehlungen
Lazy Loading standardmäßig aktivieren
Die allgemeine Empfehlung für CMS, die Lazy Loading auf Browserebene implementieren, besteht darin, es standardmäßig zu aktivieren. Das bedeutet, dass loading="lazy" zu Bildern und iFrames hinzugefügt werden sollte, vorzugsweise nur für Elemente, die Größenattribute enthalten.
Wenn die Funktion standardmäßig aktiviert ist, werden mehr Netzwerkressourcen eingespart, als wenn sie manuell aktiviert werden müsste, z. B. für jedes Bild einzeln.
loading="lazy" sollte nach Möglichkeit nur Elementen hinzugefügt werden, die wahrscheinlich im nicht sichtbaren Bereich erscheinen.
Diese Anforderung kann für ein CMS aufgrund fehlender clientseitiger Informationen und verschiedener Darstellungsgrößen komplex zu implementieren sein. Es wird jedoch empfohlen, zumindest näherungsweise Heuristiken zu verwenden, um Elemente wie Hero-Bilder, die wahrscheinlich ohne Scrollen sichtbar sind, vom Lazy Loading auszuschließen.
Änderungen pro Element zulassen
loading="lazy" sollte standardmäßig zu Bildern und iFrames hinzugefügt werden. Es ist jedoch wichtig, dass das Attribut bei bestimmten Bildern weggelassen werden kann, z. B. um 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 verfügbar ist und es ermöglicht, das Lazy Loading für dieses Element zu deaktivieren.
Alternativ oder zusätzlich könnte eine API für Drittanbieter-Entwickler bereitgestellt werden, damit sie ähnliche Änderungen über Code vornehmen können.
In WordPress kann das loading-Attribut beispielsweise entweder für ein gesamtes HTML-Tag oder einen gesamten Kontext oder für ein bestimmtes HTML-Element im Inhalt übersprungen werden.
Vorhandene Inhalte nachrüsten
Im Wesentlichen gibt es zwei Ansätze, um das Attribut loading zu HTML-Elementen in einem CMS hinzuzufügen:
- Füge das Attribut im Content-Editor im Backend hinzu, um es dauerhaft in der Datenbank zu speichern.
- Fügen Sie das Attribut dynamisch hinzu, wenn Inhalte aus der Datenbank im Frontend gerendert werden.
Es wird empfohlen, das Attribut beim Rendern im CMS dynamisch hinzuzufügen, damit auch vorhandene Inhalte von den Vorteilen des Lazy Loading profitieren. 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 die Auswirkung des CMS auf die Einsparung von Netzwerkressourcen drastisch reduziert. Außerdem können durch das dynamische Hinzufügen des Attributs zukünftige Änderungen leicht vorgenommen werden, falls die Funktionen des Lazy Loadings auf Browserebene weiter ausgebaut werden.
Wenn das Attribut dynamisch hinzugefügt wird, sollte ein potenziell vorhandenes loading-Attribut für ein Element berücksichtigt werden und Vorrang haben. So kann das CMS oder eine Erweiterung dafür auch den editorgesteuerten Ansatz implementieren, ohne dass es zu einem Konflikt mit doppelten Attributen kommt.
Serverseitige Leistung optimieren
Wenn du das Attribut loading mithilfe einer serverseitigen Middleware dynamisch zu Inhalten hinzufügst, ist die Geschwindigkeit ein wichtiger Faktor. Je nach CMS kann das Attribut entweder über DOM-Traversal oder reguläre Ausdrücke hinzugefügt werden. Letzteres wird aus Leistungsgründen empfohlen.
Reguläre Ausdrücke sollten so wenig wie möglich verwendet werden, z. B. ein einzelner regulärer Ausdruck, der alle img- und iframe-Tags im Inhalt einschließlich ihrer Attribute erfasst und dann das Attribut loading gegebenenfalls jedem Tag-String hinzufügt. WordPress geht beispielsweise so weit, einen einzigen allgemeinen regulären Ausdruck zu verwenden, um verschiedene On-the-Fly-Vorgänge für bestimmte Elemente auszuführen. Das Hinzufügen von loading="lazy" ist nur einer davon. Mit einem einzigen regulären Ausdruck werden mehrere Funktionen ermöglicht. Diese Form der Optimierung ist ein weiterer Grund, warum die Implementierung von Lazy Loading im Kern eines CMS gegenüber einer Erweiterung empfohlen wird. Sie ermöglicht eine bessere serverseitige Leistungsoptimierung.
Nächste Schritte
Prüfen Sie, ob es bereits ein Feature Request-Ticket gibt, um die Unterstützung für das Feature in Ihrem CMS hinzuzufügen, oder öffnen Sie ein neues, falls noch keines vorhanden ist. Verweisen Sie bei Bedarf auf diesen Beitrag, um Ihren Vorschlag zu untermauern.
Wenn ihr Fragen oder Kommentare habt oder euer CMS auf dieser Seite aufgeführt werden soll, weil es Lazy Loading auf Browserebene unterstützt, könnt ihr mir auf Twitter (felixarntz@) schreiben. Wenn Sie auf andere Probleme stoßen, würde ich mich freuen, mehr darüber zu erfahren, um hoffentlich eine Lösung zu finden.
Wenn du ein CMS-Plattformentwickler bist, solltest du dir ansehen, wie andere CMS Lazy Loading implementiert haben:
Ihr könnt die Erkenntnisse aus eurer Recherche und die technischen Empfehlungen aus diesem Beitrag nutzen, um Code zu eurem CMS beizutragen, z. B. in Form eines Patches oder Pull-Requests.