Ladezeitoptimierung: Content Preload
Wer sich regelmäßig mit seiner Website-Performance auseinandersetzt, dem ist auch der neueste Streich aus dem Hause Google nicht entgangen: Mit seinen Web Vitals bietet Google jetzt noch genauere Möglichkeiten zur Analyse von relevanten KPIs. Zwei der drei wichtigen Primary Web Vitals können mit der Content Preload Funktion maßgeblich optimiert werden.
Durch den Content-Preload ist es möglich Seitenelemente priorisiert laden zu lassen, ausgewählte Seitenelemente werden somit vorzeitig geladen um Layoutverschiebungen durch nachladende Ads zu vermeiden. Wie genau LCP und CLS durch den Preload optimiert werden und mithilfe des Google Lighthouse Tools Preload geeignete Elemente identifiziert werden können erklären wir in unserem Beitrag.
Was ist ein Content Preload?
Mit der „Preload“-Eigenschaft eines <link> Elements können spezifische Abrufanforderungen im <head> Bereich des HTML-Codes angegeben werden. So werden Ressourcen als priorisiert deklariert und im Ladevorgang einer URL bereits vor dem „Main Rendering“ des Browsers ausgeführt.
Zusammenfassen von JS- und CSS-Ressourcen
Um den Quellcode schmal zu halten sollte bereits vor dem Einsatz des Content Preloads definiert werden, welche Seitenelemente für den initialen Sichtbereich und die Interaktionsmöglichkeiten essenziell sind. Es bietet sich an, grundlegende Java Scripts und Cascading Style Sheets innerhalb „/main.js“ sowie „/style.css“ zu bündeln und abrufbar abzubilden. Ein weiterer Vorteil der Ressourcenbündelung ist die Möglichkeit die bereits priorisierten Inhalte über die Cacheeinstellungen im Zwischenspeicher des Nutzers zu lagern. Somit sind diese laderelevanten Elemente über eine längere Zeitspanne bei erneuten Seitenaufrufen bereits im Cache des Users vorhanden und müssen nicht komplett neu geladen werden.
Preload Funktion im Detail
Für gewöhnlich wird das Element im Header dazu verwendet eine CSS-Datei zu laden.
<link rel="stylesheet" href="style.css">
Mit der Verwendung des rel-Attributs wandeln wir das bekannte <link> Element jedoch in einen Preloader für jegliche Seitenbausteine um. Hierfür müssen nur zwei weitere Werte spezifiziert werden:
- Für die Erreichbarkeit wird der Ressourcenpfad mittels des href-Attributs angegeben.
- Für die Ressourcenzuordnung kommt das as-Attribut zum Einsatz.
Haben wir unsere JS- und CSS-Ressourcen wie oben beschrieben priorisiert und gebündelt, ergibt sich folgendes Codebeispiel:
<link rel="preload" href="style.css" as="style">
<link rel="preload" href="main.js" as="script">
Ein simpler Head-Bereich könnte somit so aussehen:
In diesem Beispiel werden JS- sowie CSS-Dateien bereits vorgeladen. Somit sind diese umgehend verfügbar, sobald sie für das Rendern der Seite benötigt werden. Das Beispiel erscheint zunächst banal, da der Browser im gleichen HMTL-Abschnitt das Stylesheet vorfinden würde. Die Vorteile werden jedoch deutlicher, je größer und später die durch den Preload vorgeladenen Ressourcen eigentlich im Quellcode liegen würden. Ressourcen, auf die vom CSS ausgehend verwiesen wird (z.B. Schriftarten oder Bilder) sowie Ressourcen wie JSON, importierte Scripte oder Web Worker, die über JavaScript angefragt werden, können effizienter geladen werden. Ebenso verhält es sich mit großen Bild- und Videodateien.
Welche Elemente kommen für einen Preload in Frage?
Es gibt viele Seitenelemente, die für eine Preload-Funktion in Frage kommen:
| Element | Beschreibung |
|---|---|
| audio | Audio Datei (<audio>) |
| document | Ein über <frame> oder <iframe> eingebettetes HTML Dokument |
| embed | Ressourcen, die innerhalb eines <embed> Elements eingebettet sind |
| fetch | Ressourcen, die abgerufen oder per XHR angefragt werden (ArrayBuffer oder JSON) |
| font | Schriftart |
| image | Bilddatei |
| object | Ressourcen, die innerhalb eines <object> Elements eingebettet sind |
| script | JavaScript Dateien |
| style | CSS-Stylesheet |
| track | WebVTT Datei |
| worker | JavaScript Web Worker oder Shared Worker |
| video | Video Datei (<video>) |
Beispielhafte Darstellungen der Preload Elemente im Quellcode:
| Typ | Preload Beispiel |
|---|---|
<audio> |
<link rel=preload as=audio href=...> |
<video> |
<link rel=preload as=video href=...> |
<track> |
<link rel=preload as=track href=...> |
<script> |
<link rel=preload as=script href=...> |
<link rel=stylesheet> |
<link rel=preload as=style href=...> |
font |
<link rel=preload as=font href=...> |
<img>, <picture> (srcset, imageset) |
<link rel=preload as=image href=...> |
<image> |
<link rel=preload as=image href=...> |
XHR, fetch |
<link rel=preload as=fetch crossorigin href=...> |
Worker, SharedWorker |
<link rel=preload as=worker href=...> |
<embed> |
<link rel=preload as=embed href=...> |
<object> |
<link rel=preload as=object href=...> |
<iframe>, <frame> |
<link rel=preload as=document href=...> |
Welche Vorteile bietet der Content Preload?
Die Nutzung des Content Preloads hat gleich mehrere Vorteile:
- Wichtige Ressourcen werden als erstes geladen
- Einzelne Bereiche, wie z. B. der initiale Sichtbereich werden im Ladevorgang sichergestellt
- Die Total Blocking Time des Renderers wird reduziert
- Die durchschnittliche Seitenperformance nimmt zu
- Platzhalter für Ads und Anzeigen können vorgeladen werden, um Layout Shifts zu vermeiden
Besonders in Betrachtung der Web Vitals und der damit entstandenen Möglichkeiten für Google, eine Bewertung der Nutzerfreundlichkeit von URLs zu erstellen, ist der Content Preload ein nützliches Instrument für die Optimierung des Largest Contentful Paints einer Seite. Er stellt sicher, dass relevante Informationen als erstes gebündelt geladen werden und pünktlich zur Verfügung stehen. Somit findet eine Optimierung sowohl auf technischer Seite für den Crawler als auch für die positive Nutzerwahrnehmung statt.
Kostenlos und einfach: Mit dem Google Lighthouse Test Preload-Elemente identifizieren
Angenommen das Anforderungsprotokoll einer Seite sieht folgendermaßen aus:
Die „index.html“ Datei deklariert „app.js“ – sobald „app.js“ ausgeführt wird ruft es „styles.css“ und „ui.js“ für den Ladeprozess auf. Die Seite ist erst dann vollständig geladen, wenn beide Ressourcen heruntergeladen und geparst ausgeführt wurden.
Dem Beispiel nach würde der Lighthouse-Test „styles.css“ und „ui.js“ als zu optimierende Kandidaten ausgeben.
Potenzielle Ladezeiteinsparungen basieren darauf, wie viel früher der Browser die Anfragen starten könnte, wenn die beiden Elemente den Preload verwenden würden. Wenn z. B. „app.js“ 200 ms für das Herunterladen, Parsen und Ausführen benötigt, beträgt die potenzielle Einsparung für jede Ressource 200 ms, da „app.js“ kein Engpass für jede der Anfragen ist.
Im direkten Vergleich zwischen einem Ladediagramm mit Preload-Funktion und ohne Preload-Funktion werden die Vorteile deutlich.
Der Ladeprozess inkl. des Preloads ist schneller.
Ressourcen können gleichzeitig geladen werden, anstatt nacheinander.
Über den Autor
Dennis Kurz
Senior Executive SEO
Köln
Dennis Kurz ist als Senior Executive im Fachbereich Suchmaschinenoptimierung (SEO) der Resolution Media am Standort Köln tätig und schreibt über Online Marketing sowie digitales Quer- und Neudenken.
