Wichtige Assets vorab laden, um die Ladegeschwindigkeit zu verbessern

Wenn Sie eine Webseite öffnen, fordert der Browser das HTML-Dokument von einem Server an, analysiert den Inhalt und sendet separate Anfragen für alle referenzierten Ressourcen. Als Entwickler wissen Sie bereits, welche Ressourcen für Ihre Seite erforderlich sind und welche davon am wichtigsten sind. So 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.

Das Vorabladen eignet sich am besten für Ressourcen, die vom Browser in der Regel erst spät erkannt werden.

Screenshot des Bereichs „Netzwerk“ in den Chrome DevTools
In diesem Beispiel wird die Schriftart „Pacifico“ im Stylesheet mit einer @font-face-Regel definiert. Der Browser lädt die Schriftdatei erst nach dem Herunterladen und Parsen des Stylesheets.

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

Screenshot des Chrome DevTools-Netzwerkbereichs nach dem Anwenden des Vorabladens
In diesem Beispiel ist die Schriftart „Pacifico“ vorab geladen, sodass der Download parallel zum Stylesheet erfolgt.

Die kritische Anfragekette stellt die Reihenfolge der Ressourcen dar, die vom Browser priorisiert und abgerufen werden. Lighthouse kennzeichnet Assets auf der dritten Ebene dieser Kette als spät erkannt. Mit der Prüfung Schlüsselanfragen vorladen können Sie ermitteln, welche Ressourcen vorgeladen werden sollen.

Die Prüfung für das Vorabladen wichtiger Anfragen in Lighthouse

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, damit sie bei Bedarf sofort verfügbar sind. Die Scripts werden nicht ausgeführt und die Stylesheets nicht angewendet.

Ressourcenhinweise wie preconnect und prefetch werden vom Browser nach Bedarf ausgeführt. Die preload ist dagegen für den Browser obligatorisch. Moderne Browser priorisieren Ressourcen bereits ziemlich gut. Daher ist es wichtig, preload sparsam zu verwenden und nur die wichtigsten Ressourcen vorab zu laden.

Nicht verwendete Vorab-Ladevorgänge lösen ungefähr drei Sekunden nach dem load-Ereignis eine Warnung in der Chrome-Konsole 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 analysiert. Wenn Sie diese Ressourcen vorab laden, werden sie abgerufen, bevor die CSS-Dateien heruntergeladen wurden.

CSS-Dateien vorab laden

Wenn Sie den Ansatz für kritisches CSS verwenden, teilen Sie Ihr CSS in zwei Teile auf. Das kritische CSS, das für das Rendern der Inhalte „above the fold“ (ohne Scrollen sichtbar) erforderlich ist, wird in die <head> des Dokuments eingebettet. Nicht kritisches CSS wird in der Regel mit JavaScript lazy-loaded. Wenn Sie warten, bis JavaScript ausgeführt wird, bevor nicht kritisches CSS geladen wird, kann das beim Scrollen zu Verzögerungen beim Rendern führen. Daher ist es empfehlenswert, den Download mit <link rel="preload"> früher zu starten.

JavaScript-Dateien vorab laden

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

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 andere.

Einige Arten von Ressourcen, z. B. Schriftarten, werden im anonymen Modus geladen. Für diese müssen Sie das crossorigin-Attribut 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 dafür zu sorgen, 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 finden. Dies kann in einigen Fällen zu kleinen 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 die Einschleusung von Pre-Load-Tags unterstützt. Mit webpack Version 4.6.0 oder höher wird das Vorladen durch Magische Kommentare in import() unterstützt:

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

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

Auswirkungen des Vorladens auf die 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 große Textblöcke, die mit Webschriften gerendert werden, können von einem gut platzierten Preload-Hinweis erheblich profitieren. Sie sollten verwendet werden, wenn es Möglichkeiten gibt, diese wichtigen Inhalte schneller an den Nutzer zu liefern.

Beim Vorladen und bei anderen Optimierungen ist jedoch Vorsicht geboten. Vermeiden Sie insbesondere das Vorladen zu vieler Ressourcen. Wenn zu viele Ressourcen priorisiert werden, ist effektiv keine davon priorisiert. Die Auswirkungen übermäßiger Hinweise zur Vorab-Ladezeit sind besonders schädlich für Nutzer in langsameren Netzwerken, in denen Bandbreitenkonflikte stärker zu spüren sind.

Konzentrieren Sie sich stattdessen auf einige hochwertige Ressourcen, von denen Sie wissen, dass sie von einem gut platzierten Preloading profitieren. Achten Sie beim Vorabladen von Schriftarten darauf, dass Sie Schriftarten im WOFF 2.0-Format bereitstellen, um die Ressourcenladezeit so weit wie möglich zu verkürzen. Da WOFF 2.0 ausgezeichnet von Browsern unterstützt wird, führt die Verwendung älterer Formate wie WOFF 1.0 oder TrueType (TTF) zu einer Verzögerung des LCP, wenn der LCP-Kandidat ein Textknoten ist.

Bei LCP und JavaScript sollten Sie darauf achten, dass Sie vollständiges Markup vom Server senden, damit der Preloader des Browsers ordnungsgemäß funktioniert. Wenn Sie eine Website bereitstellen, die zum Rendern von Markup vollständig auf JavaScript angewiesen ist und keine serverseitig gerenderte HTML senden kann, ist es von Vorteil, dort einzugreifen, wo der Browser-Preload-Scanner nicht kann, und Ressourcen vorab zu laden, die sonst erst nach dem Laden und Ausführen von JavaScript gefunden werden.

Cumulative Layout Shift (CLS)

Der Cumulative Layout Shift (CLS) ist ein besonders wichtiger Messwert für Webfonts. Er hat eine erhebliche Wechselwirkung mit Webfonts, bei denen die CSS-Eigenschaft font-display zum Verwalten des Ladens von Schriftarten verwendet wird. Mit den folgenden Strategien können Sie Layoutänderungen aufgrund von Webschriften minimieren:

  1. Schriftarten vorab laden und dabei den Standardwert block für font-display verwenden Das ist ein heikles Gleichgewicht. Das Blockieren der Anzeige von Schriftarten ohne Fallback kann als Problem für die Nutzerfreundlichkeit angesehen werden. Zum einen werden durch das Laden von Schriftarten mit font-display: block; Layoutänderungen aufgrund von Webschriften vermieden. Andererseits sollten diese Web-Schriftarten so schnell wie möglich geladen werden, wenn sie für die Nutzerfreundlichkeit entscheidend sind. Die Kombination eines Preloads mit font-display: block; kann ein akzeptabler Kompromiss sein.
  2. Schriftarten vorab laden und dabei den Wert fallback für font-display verwenden. fallback ist ein Kompromiss zwischen swap und block, da es eine extrem kurze Blockierungsdauer hat.
  3. Verwenden Sie den optional-Wert für font-display ohne Vorabdaten. Wenn eine Webschrift für die Nutzerfreundlichkeit nicht entscheidend ist, aber dennoch zum Rendern eines erheblichen Teils des Seitentexts verwendet wird, sollten Sie den Wert optional verwenden. Bei ungünstigen Bedingungen zeigt optional den Seitentext in einer Fallback-Schriftart an, während die Schriftart für die nächste Navigation im Hintergrund geladen wird. Das Endergebnis dieser Bedingungen ist eine verbesserte CLS, da Systemschriften sofort gerendert werden, während bei nachfolgenden Seitenladevorgängen die Schrift sofort ohne Layoutverschiebungen geladen wird.

Der CLS ist ein Messwert, der sich bei Webschriften nur schwer optimieren lässt. Wie immer sollten Sie im Lab experimentieren, aber anhand Ihrer Felddaten feststellen, ob Ihre Schriftladestrategien den CLS verbessern oder verschlechtern.

Interaction to Next Paint (INP)

Interaction to Next Paint ist ein Messwert, mit dem die Reaktionsfähigkeit auf Nutzereingaben gemessen wird. Da der Großteil der Interaktivität im Web über JavaScript gesteuert wird, kann das Vorladen von JavaScript, das für wichtige Interaktionen verantwortlich ist, dazu beitragen, den INP einer Seite niedrig zu halten. Beachten Sie jedoch, dass das Vorladen zu viel JavaScript beim Starten unbeabsichtigte negative Folgen haben kann, wenn zu viele Ressourcen um die Bandbreite konkurrieren.

Achten Sie auch darauf, wie Sie den Code aufteilen. Die Codeaufteilung ist eine hervorragende Optimierung, um die Menge an JavaScript zu reduzieren, die beim Start geladen wird. Interaktionen können sich jedoch verzögern, wenn sie auf JavaScript angewiesen sind, das direkt zu Beginn der Interaktion geladen wird. Um dies zu kompensieren, müssen Sie die Absicht des Nutzers prüfen und vor der Interaktion ein Pre-Load für die erforderlichen JavaScript-Chunks einfügen. Ein Beispiel wäre das Vorladen von JavaScript, das zum Validieren des Inhalts eines Formulars erforderlich ist, wenn eines der Felder im Formular den Fokus hat.

Fazit

Laden Sie wichtige Ressourcen, die vom Browser erst spät erkannt werden, vorab. Es wäre kontraproduktiv, alles vorab zu laden. Verwenden Sie preload daher sparsam und messen Sie die Auswirkungen in der Praxis.