Wichtige Assets vorab laden, um die Ladegeschwindigkeit zu verbessern

Houssein Djirdeh
Jeremy Wagner
Milica Mihajlija

Wenn Sie eine Webseite öffnen, fordert der Browser das HTML-Dokument von einem Server an, parst dessen Inhalt und sendet separate Anfragen für alle referenzierten Ressourcen. Als Entwickler wissen Sie bereits, welche Ressourcen Ihre Seite benötigt und welche davon am wichtigsten sind. Mit diesem Wissen können Sie die kritischen Ressourcen vorab anfordern und den Ladevorgang beschleunigen. In diesem Beitrag wird erläutert, wie Sie das mit <link rel="preload"> erreichen.

So funktioniert das Vorladen

Das Vorabladen eignet sich am besten für Ressourcen, die der Browser normalerweise erst spät erkennt.

Screenshot des Bereichs „Netzwerk“ in den Chrome-Entwicklertools.
In diesem Beispiel wird die Schriftart „Pacifico“ im Stylesheet mit einer @font-face-Regel definiert. Der Browser lädt die Schriftartdatei erst, nachdem er das Stylesheet heruntergeladen und geparst hat.

Wenn Sie eine bestimmte Ressource vorab laden, teilen Sie dem Browser mit, dass Sie sie früher abrufen möchten, als der Browser sie sonst erkennen würde, weil Sie sicher sind, dass sie für die aktuelle Seite wichtig ist.

Screenshot des Bereichs „Netzwerk“ in den Chrome-Entwicklertools nach dem Anwenden von Preloading
In diesem Beispiel wird die Schriftart „Pacifico“ vorab geladen, sodass der Download parallel zum Stylesheet erfolgt.

Die Kette kritischer Anfragen stellt die Reihenfolge der Ressourcen dar, die vom Browser priorisiert und abgerufen werden. Lighthouse identifiziert Assets, die sich auf der dritten Ebene dieser Kette befinden, als spät erkannte Assets. Mit dem Audit für das Vorabladen wichtiger Anfragen können Sie ermitteln, welche Ressourcen vorab geladen werden sollen.

Lighthouse-Prüfung „Wichtige Anfragen vorab laden“.

Sie können Ressourcen vorab laden, indem Sie dem Head Ihres HTML-Dokuments ein <link>-Tag mit rel="preload" hinzufügen:

<link rel="preload" as="script" href="critical.js">

Der Browser speichert vorab geladene Ressourcen im Cache, sodass sie bei Bedarf sofort verfügbar sind. Die Skripts werden nicht ausgeführt und die Stylesheets werden nicht angewendet.

Ressourcenhinweise wie preconnect und prefetch werden nach Ermessen des Browsers ausgeführt. Die preload ist dagegen für den Browser obligatorisch. Moderne Browser sind bereits recht gut darin, Ressourcen zu priorisieren. Deshalb ist es wichtig, preload sparsam zu verwenden und nur die wichtigsten Ressourcen vorzuladen.

Nicht verwendete Preloads lösen in Chrome etwa 3 Sekunden nach dem load-Ereignis eine Konsolenwarnung aus.

Warnung in der Chrome-Entwicklertools-Konsole zu nicht verwendeten vorab geladenen Ressourcen.

Anwendungsfälle

In CSS definierte Ressourcen vorab laden

Mit @font-face-Regeln definierte Schriftarten oder in CSS-Dateien definierte Hintergrundbilder werden erst erkannt, wenn der Browser diese CSS-Dateien herunterlädt und parst. Durch das Vorabladen dieser Ressourcen werden sie abgerufen, bevor die CSS-Dateien heruntergeladen wurden.

CSS-Dateien vorab laden

Wenn Sie den Ansatz mit kritischem CSS verwenden, teilen Sie Ihr CSS in zwei Teile auf. Das kritische CSS, das zum Rendern der Inhalte „above the fold“ (ohne Scrollen sichtbar) erforderlich ist, wird im <head> des Dokuments inline eingefügt. Nicht kritisches CSS wird in der Regel mit JavaScript verzögert geladen. Wenn Sie warten, bis JavaScript ausgeführt wird, bevor Sie nicht kritisches CSS laden, kann es zu Verzögerungen beim Rendern kommen, wenn Nutzer scrollen. Daher ist es ratsam, <link rel="preload"> zu verwenden, um den Download früher zu starten.

JavaScript-Dateien vorab laden

Da Browser vorab geladene Dateien nicht ausführen, ist das Vorabladen nützlich, um das Abrufen von der Ausführung zu trennen. Dadurch können Messwerte wie „Time to Interactive“ verbessert werden. Das Vorabladen funktioniert am besten, wenn Sie Ihre JavaScript-Bundles aufteilen und nur kritische Chunks vorab laden.

rel=preload implementieren

Die einfachste Möglichkeit, preload zu implementieren, besteht darin, dem <head> des Dokuments ein <link>-Tag hinzuzufügen:

<head>
  <link rel="preload" as="script" href="critical.js">
</head>

Wenn Sie das Attribut as angeben, kann der Browser die Priorität der vorab abgerufenen Ressource entsprechend ihrem Typ festlegen, die richtigen Header festlegen und ermitteln, ob die Ressource bereits im Cache vorhanden ist. Zulässige Werte für dieses Attribut sind: script, style, font, image und others.

Einige Arten von Ressourcen, z. B. Schriftarten, werden im anonymen Modus geladen. Für diese müssen Sie das Attribut crossorigin mit preload festlegen:

<link rel="preload" href="ComicSans.woff2" as="font" type="font/woff2" crossorigin>

<link>-Elemente akzeptieren auch das type-Attribut, das den MIME-Typ der verknüpften Ressource enthält. Die Browser verwenden den Wert des Attributs type, um sicherzustellen, dass Ressourcen nur dann vorab geladen werden, wenn ihr Dateityp unterstützt wird. Wenn ein Browser den angegebenen Ressourcentyp nicht unterstützt, wird <link rel="preload"> ignoriert.

Sie können auch jede Art von Ressource über den Link-HTTP-Header vorab laden:

Link: </css/style.css>; rel="preload"; as="style"

Ein Vorteil der Angabe von preload im HTTP-Header besteht darin, dass der Browser das Dokument nicht parsen muss, um es zu erkennen. Das kann in einigen Fällen zu geringfügigen Verbesserungen führen.

JavaScript-Module mit Webpack vorab laden

Wenn Sie einen Modul-Bundler verwenden, der Build-Dateien Ihrer Anwendung erstellt, müssen Sie prüfen, ob er das Einfügen von Preload-Tags unterstützt. Mit webpack-Version 4.6.0 oder höher wird das Vorabladen durch die Verwendung von Magic Comments in import() unterstützt:

import(_/* webpackPreload: true */_ "CriticalChunk")

Wenn Sie eine ältere Version von webpack verwenden, nutzen Sie ein Drittanbieter-Plug-in wie preload-webpack-plugin.

Auswirkungen von Preloading auf Core Web Vitals

Das Vorabladen ist eine leistungsstarke Optimierung, die sich auf die Ladegeschwindigkeit auswirkt. Solche Optimierungen können zu Änderungen bei den Core Web Vitals Ihrer Website führen.

Largest Contentful Paint (LCP)

Das Vorladen hat einen großen Einfluss auf den Largest Contentful Paint (LCP) bei Schriftarten und Bildern, da sowohl Bilder als auch Textknoten LCP-Kandidaten sein können. Hero-Bilder und lange Textblöcke, die mit Webfonts gerendert werden, können erheblich von einem gut platzierten Preload-Hinweis profitieren. Er sollte verwendet werden, wenn sich die Möglichkeit bietet, diese wichtigen Inhalte schneller an den Nutzer zu liefern.

Beim Preloading und anderen Optimierungen ist jedoch Vorsicht geboten. Vermeiden Sie insbesondere das Vorladen zu vieler Ressourcen. Wenn zu viele Ressourcen priorisiert werden, wird im Grunde keine von ihnen priorisiert. Die Auswirkungen von übermäßigen Preload-Hinweisen sind besonders schädlich für Nutzer mit langsameren Netzwerken, bei denen Bandbreitenkonflikte deutlicher werden.

Konzentrieren Sie sich stattdessen auf einige hochwertige Ressourcen, die von einem gut platzierten Preload profitieren. Wenn Sie Schriftarten vorab laden, sollten Sie sie im WOFF 2.0-Format bereitstellen, um die Ladezeit von Ressourcen so weit wie möglich zu verkürzen. Da WOFF 2.0 hervorragende Browserunterstützung bietet, wird der LCP verzögert, wenn der LCP-Kandidat ein Textknoten ist und Sie ältere Formate wie WOFF 1.0 oder TrueType (TTF) verwenden.

Bei LCP und JavaScript sollten Sie darauf achten, dass Sie vollständiges Markup vom Server senden, damit der Preload-Scanner des Browsers richtig funktioniert. Wenn Sie Inhalte bereitstellen, bei denen Markup vollständig mit JavaScript gerendert wird und Sie kein serverseitig gerendertes HTML senden können, sollten Sie Ressourcen vorab laden, die sonst erst erkannt werden, wenn das Laden und Ausführen von JavaScript abgeschlossen ist.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) ist ein besonders wichtiger Messwert für Webfonts. CLS und Webfonts, bei denen die CSS-Eigenschaft font-display verwendet wird, um das Laden von Schriftarten zu verwalten, hängen eng zusammen. Um layoutbezogene Verschiebungen im Zusammenhang mit Webfonts zu minimieren, sollten Sie die folgenden Strategien in Betracht ziehen:

  1. Schriftarten vorab laden, während der Standardwert block für font-display verwendet wird: Das ist ein heikles Gleichgewicht. Das Blockieren der Anzeige von Schriftarten ohne Fallback kann als Problem der Nutzerfreundlichkeit angesehen werden. Einerseits werden durch das Laden von Schriftarten mit font-display: block; layoutbezogene Verschiebungen im Zusammenhang mit Webfonts vermieden. Andererseits sollten Webfonts, die für die Nutzererfahrung entscheidend sind, so schnell wie möglich geladen werden. Die Kombination eines Preloads mit font-display: block; kann ein akzeptabler Kompromiss sein.
  2. Schriftarten vorab laden, wenn Sie den Wert fallback für font-display verwenden. fallback ist ein Kompromiss zwischen swap und block, da der Sperrzeitraum extrem kurz ist.
  3. Verwenden Sie den optional-Wert für font-display ohne Preload. Wenn eine Web-Schriftart nicht entscheidend für die Nutzerfreundlichkeit ist, aber trotzdem zum Rendern einer beträchtlichen Menge an Seitentext verwendet wird, sollten Sie den Wert optional verwenden. Unter ungünstigen Bedingungen wird in optional der Seitentext in einer Fallback-Schriftart angezeigt, während die Schriftart im Hintergrund für die nächste Navigation geladen wird. Das Endergebnis unter diesen Bedingungen ist ein verbesserter CLS, da Systemschriftarten sofort gerendert werden. Bei nachfolgenden Seitenaufrufen wird die Schriftart sofort ohne Layoutverschiebungen geladen.

CLS ist ein schwieriger Messwert, wenn es um die Optimierung von Webfonts geht. Wie immer sollten Sie im Labor experimentieren, aber Felddaten verwenden, um festzustellen, ob Ihre Strategien zum Laden von Schriftarten den CLS-Wert verbessern oder verschlechtern.

Interaction to Next Paint (INP)

Interaction to Next Paint ist ein Messwert, der die Reaktionsfähigkeit auf Nutzereingaben misst. Da der Großteil der Interaktivität im Web durch JavaScript gesteuert wird, kann das Vorabladen von JavaScript, das wichtige Interaktionen ermöglicht, dazu beitragen, den INP einer Seite niedrig zu halten. Wenn Sie jedoch zu viel JavaScript beim Start vorladen, kann dies unbeabsichtigte negative Folgen haben, wenn zu viele Ressourcen um Bandbreite konkurrieren.

Außerdem sollten Sie vorsichtig sein, wie Sie Code-Splitting vornehmen. Die Codeaufteilung ist eine hervorragende Optimierung, um die Menge an JavaScript zu reduzieren, die beim Start geladen wird. Interaktionen können jedoch verzögert werden, wenn sie auf JavaScript angewiesen sind, das direkt zu Beginn der Interaktion geladen wird. Um dies zu kompensieren, müssen Sie die Intention des Nutzers untersuchen und vor der Interaktion einen Preload für die erforderlichen JavaScript-Chunks einfügen. Ein Beispiel wäre das Vorabladen von JavaScript, das zum Validieren des Inhalts eines Formulars erforderlich ist, wenn der Fokus auf eines der Felder im Formular gerichtet ist.

Fazit

Um die Seitengeschwindigkeit zu verbessern, sollten Sie wichtige Ressourcen vorab laden, die vom Browser erst spät erkannt werden. Alles vorzuladen wäre kontraproduktiv. Verwenden Sie preload daher sparsam und messen Sie die Auswirkungen in der Praxis.