Schnelleres Laden von Seiten dank „Early Hints“ durch die Reaktionszeit des Servers

Hier erfahren Sie, wie Ihr Server dem Browser Hinweise zu kritischen Unterressourcen senden kann.

Kenji Baheux

Barry Pollard

Was sind frühe Hinweise?

Websites sind mit der Zeit immer ausgefeilter geworden. Daher ist es nicht ungewöhnlich, dass ein Server umfangreiche Aufgaben ausführen muss (z. B. Zugriff auf Datenbanken oder CDNs, die auf den Ursprungsserver zugreifen), um die HTML-Datei für die angeforderte Seite zu erstellen. Leider führt diese „Server-Überlegungszeit“ zu einer zusätzlichen Latenz, bevor der Browser mit dem Rendern der Seite beginnen kann. Tatsächlich ist die Verbindung so lange inaktiv, wie der Server für die Vorbereitung der Antwort benötigt.

„Early Hints“ ist ein HTTP-Statuscode (103 Early Hints), mit dem vor einer endgültigen Antwort eine vorläufige HTTP-Antwort gesendet wird. So kann ein Server dem Browser Hinweise zu wichtigen Unterressourcen (z. B. Stylesheets für die Seite, wichtiges JavaScript) oder Ursprüngen senden, die wahrscheinlich von der Seite verwendet werden, während der Server die Hauptressource generiert. Der Browser kann diese Hinweise verwenden, um Verbindungen aufzuwärmen und Unterressourcen anzufordern, während er auf die Hauptressource wartet. Mit anderen Worten: Frühzeitige Hinweise helfen dem Browser, diese „Server-Überlegungszeit“ zu nutzen, indem er einige Aufgaben im Voraus erledigt und so das Laden der Seite beschleunigt.

In einigen Fällen kann die Leistungsverbesserung für Largest Contentful Paint von Shopify und Cloudflare mehrere hundert Millisekunden und bis zu einer Sekunde schneller sein, wie hier vor und nach dem Vergleich dargestellt:

Frühe Hinweise verwenden

Der erste Schritt, um Frühindikatoren zu nutzen, besteht darin, die wichtigsten Landingpages zu ermitteln, also die Seiten, auf denen Ihre Nutzer in der Regel beginnen, wenn sie Ihre Website besuchen. Dies könnte die Startseite oder beliebte Seiten mit Produkteinträgen sein, falls viele Nutzer von anderen Websites kommen. Diese Einstiegspunkte sind wichtiger als andere Seiten, da die Nützlichkeit von frühen Hinweisen abnimmt, je weiter sich der Nutzer auf Ihrer Website bewegt. Das bedeutet, dass der Browser bei der zweiten oder dritten Navigation wahrscheinlich alle erforderlichen Unterressourcen hat. Außerdem ist es immer eine gute Idee, einen guten ersten Eindruck zu hinterlassen.

Nachdem Sie diese priorisierte Liste von Landingpages erstellt haben, müssen Sie als Nächstes ermitteln, welche Ursprünge oder Unterressourcen gute Kandidaten für preconnect- oder preload-Hinweise sind. In der Regel sind dies Ursprünge und untergeordnete Ressourcen, die am stärksten zu wichtigen Nutzermesswerten wie Largest Contentful Paint oder First Contentful Paint beitragen. Genauer gesagt, suchen Sie nach Unterressourcen wie synchronem JavaScript, Stylesheets oder sogar Webschriftarten, die das Rendering blockieren. Suchen Sie auch nach Ursprüngen, die Unterressourcen hosten, die einen großen Beitrag zu wichtigen Nutzermesswerten leisten.

Wenn für Ihre Hauptressourcen bereits preconnect oder preload verwendet wird, können Sie diese Ursprünge oder Ressourcen als Kandidaten für Vorab-Hinweise in Betracht ziehen. Weitere Informationen finden Sie unter LCP optimieren. Das naive Kopieren der preconnect- und preload-Anweisungen aus HTML in Early Hints ist jedoch nicht optimal.

Wenn Sie diese in HTML verwenden, sollten Sie normalerweise preconnect oder preload für Ressourcen verwenden, die vom Preload-Scanner nicht im HTML-Code gefunden werden, z. B. Schriftarten oder Hintergrundbilder, die sonst erst spät erkannt würden. Für „Early Hints“ steht Ihnen der HTML-Code nicht zur Verfügung. Daher empfiehlt es sich, stattdessen preconnect für kritische Domains oder preload kritische Ressourcen zu verwenden, die sonst vielleicht zu Beginn des HTML-Codes gefunden würden, z. B. main.css oder app.js vorab laden. Darüber hinaus unterstützen nicht alle Browser preload für „Early Hints“. Weitere Informationen finden Sie unter Browser-Unterstützung.

Im zweiten Schritt geht es darum, das Risiko zu minimieren, dass Frühe Hinweise auf Ressourcen oder Ursprünge angewendet werden, die möglicherweise veraltet sind oder von der Hauptressource nicht mehr verwendet werden. Ressourcen, die häufig aktualisiert und versioniert werden (z. B. example.com/css/main.fa231e9c.css), sind beispielsweise nicht die beste Wahl. Dieser Hinweis bezieht sich nicht nur auf frühe Hinweise, sondern auf alle preload oder preconnect, unabhängig davon, wo sie vorkommen. Diese Art von Details lässt sich am besten mit Automatisierung oder Vorlagen bearbeiten. Ein manueller Prozess führt beispielsweise mit höherer Wahrscheinlichkeit zu nicht übereinstimmenden Hash- oder Versions-URLs zwischen preload und dem tatsächlichen HTML-Tag, das die Ressource verwendet.

Betrachten Sie zum Beispiel den folgenden Ablauf:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]

Der Server prognostiziert, dass main.abcd100.css benötigt wird, und schlägt vor, sie mithilfe von Early Hints vorab zu laden:

103 Early Hints
Link: </main.abcd100.css>; rel=preload; as=style
[...]

Wenige Augenblicke später wird die Webseite mit dem verknüpften Preisvergleichsportal ausgeliefert. Leider wird diese CSS-Ressource häufig aktualisiert und die Hauptressource ist bereits fünf Versionen (abcd105) vor der prognostizierten CSS-Ressource (abcd100).

200 OK
[...]
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.abcd105.css">

Verwenden Sie im Allgemeinen Ressourcen und Ursprünge, die relativ stabil und weitgehend unabhängig vom Ergebnis der Hauptressource sind. Bei Bedarf können Sie Ihre Schlüsselressourcen in zwei Teile aufteilen: einen stabilen Teil für die Verwendung mit Early Hints und einen dynamischer Teil, der abgerufen werden muss, nachdem die Hauptressource vom Browser empfangen wurde:

<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">

Suchen Sie schließlich serverseitig nach Hauptressourcenanfragen, die von Browsern gesendet wurden, die bekanntermaßen Early Hints unterstützen, und antworten Sie sofort mit 103 Early Hints. Fügen Sie in der 103-Antwort die relevanten Preconnect- und Preloading-Hinweise ein. Sobald die Hauptressource bereit ist, sende die übliche Antwort (z. B. 200 OK bei Erfolg). Aus Gründen der Abwärtskompatibilität empfiehlt es sich, auch Link-HTTP-Header in die endgültige Antwort aufzunehmen. Sie können die Antwort auch mit wichtigen Ressourcen ergänzen, die sich beim Generieren der Hauptressource herausgestellt haben, z. B. den dynamischen Teil einer wichtigen Ressource, wenn Sie dem Vorschlag „In zwei Teile teilen“ gefolgt sind. Das würde so aussehen:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
103 Early Hints
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script

Einige Augenblicke später:

200 OK
Content-Length: 7531
Content-Type: text/html; charset=UTF-8
Content-encoding: br
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Link: </experimental.3eab3290.css>; rel=preload; as=style
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">
   <script src="/common.js"></script>
   <link rel="preconnect" href="https://fonts.googleapis.com">

Unterstützte Browser

103 Early Hints wird zwar von allen gängigen Browsern unterstützt, die Anweisungen, die über eine Early Hint gesendet werden können, unterscheiden sich jedoch je nach Browser:

Unterstützung für die Voranbindung

Unterstützung für das Vorabladen:

Die Chrome-Entwicklertools bieten auch Unterstützung für 103 Early Hints und die Link-Header sind in den Dokumentressourcen zu sehen:

Hinweis: Wenn Sie die Ressourcen für frühe Hinweise verwenden möchten, darf Disable cache in den DevTools nicht angeklickt sein, da Early Hints den Browsercache verwendet. Bei vorab geladenen Ressourcen wird der Initiator als early-hints und die Größe als (Disk cache) angezeigt:

Außerdem ist für HTTPS-Tests ein vertrauenswürdiges Zertifikat erforderlich.

Firefox (Version 126) unterstützt in den DevTools keine explizite Unterstützung für 103 Early Hints. Bei Ressourcen, die mit Early Hints geladen wurden, werden jedoch keine HTTP-Header-Informationen angezeigt. Dies ist ein Indikator dafür, dass sie über Early Hints geladen wurden.

Serversupport

Hier eine kurze Zusammenfassung des Supports für Early Hints bei beliebter Open-Source-Software für HTTP-Server:

• Apache:unterstützt mit mod_http2.
• H2O: Unterstützt.
• NGINX: Experimentelles Modul.
• Knoten: seit 18.11.0 für http und http2 unterstützt

„Early Hints“ jetzt noch einfacher aktivieren

Wenn Sie eines der folgenden CDNs oder Plattformen verwenden, müssen Sie Early Hints möglicherweise nicht manuell implementieren. In der Onlinedokumentation Ihres Lösungsanbieters finden Sie Informationen dazu, ob er Early Hints unterstützt. Eine unvollständige Liste finden Sie hier:

• Erste Hinweise auf Cloudflare
• Early Hints bei Fastly
• Early Hints bei Akamai

Probleme bei Clients vermeiden, die keine frühen Hinweise unterstützen

Informative HTTP-Antworten im Bereich 100 sind Teil des HTTP-Standards. Einige ältere Clients oder Bots haben jedoch möglicherweise Probleme damit, da sie vor der Einführung von 103 Early Hints selten für das allgemeine Surfen im Web verwendet wurden.

Wenn du nur 103 Early Hints als Antwort an Clients ausgibst, die einen sec-fetch-mode: navigate-HTTP-Anfrageheader senden, sollten solche Hinweise nur für neuere Clients gesendet werden, die wissen, dass sie auf die nachfolgende Antwort warten müssen. Da „Early Hints“ nur bei Navigationsanfragen unterstützt wird (siehe aktuelle Einschränkungen), hat dies den zusätzlichen Vorteil, dass sie nicht unnötig bei anderen Anfragen gesendet werden.

Außerdem wird empfohlen, Early Hints nur über HTTP/2- oder HTTP/3-Verbindungen zu senden. Die meisten Browser akzeptieren sie nur über diese Protokolle.

Erweitertes Muster

Wenn Sie die frühen Hinweise bereits vollständig auf Ihre wichtigsten Landingpages angewendet haben und nach weiteren Optimierungsmöglichkeiten suchen, könnte das folgende fortgeschrittene Muster für Sie interessant sein.

Für Besucher, die sich im Rahmen einer typischen Nutzererfahrung auf der x-ten Seitenanfrage befinden, kann es sinnvoll sein, die „Early Hints“-Antwort an Inhalte anzupassen, die sich immer weiter unten auf der Seite befinden. Mit anderen Worten: Verwenden Sie „Early Hints“ für Ressourcen mit niedrigerer Priorität. Das mag kontraintuitiv klingen, da wir empfohlen haben, sich auf untergeordnete Ressourcen oder Ursprünge mit hoher Priorität zu konzentrieren, die das Rendern blockieren. Wenn ein Besucher jedoch schon eine Weile auf der Website unterwegs ist, hat sein Browser sehr wahrscheinlich bereits alle wichtigen Ressourcen. Danach kann es sinnvoll sein, sich auf Ressourcen mit niedrigerer Priorität zu konzentrieren. Das könnte beispielsweise bedeuten, dass Sie Early Hints zum Laden von Produktbildern oder zusätzliches JS/CSS verwenden, das nur für weniger häufige Nutzerinteraktionen erforderlich ist.

Aktuelle Beschränkungen

Hier sind die Einschränkungen von Early Hints in Chrome:

• Nur für Navigationsanfragen verfügbar (d. h. die Hauptressource für das Dokument der obersten Ebene).
• Es werden nur preconnect und preload unterstützt, prefetch wird nicht unterstützt.
• Wenn Early Hints von einer plattformübergreifenden Weiterleitung in der endgültigen Antwort gefolgt werden, werden die mit Early Hints abgerufenen Ressourcen und Verbindungen in Chrome gelöscht.
• Ressourcen, die mithilfe von Early Hints vorab geladen werden, werden im HTTP-Cache gespeichert und später von der Seite abgerufen. Daher können nur Ressourcen, die im Cache gespeichert werden können, mithilfe von Early Hints vorab geladen werden. Andernfalls wird die Ressource doppelt abgerufen (einmal über Early Hints und noch einmal über das Dokument). In Chrome ist der HTTP-Cache für nicht vertrauenswürdige HTTPS-Zertifikate deaktiviert, selbst wenn Sie die Seite laden.
• Das Vorladen responsiver Bilder (mit imagesrcset, imagesizes oder media) wird nicht mit HTTP-<link>-Headern unterstützt, da der Darstellungsbereich erst beim Erstellen des Dokuments definiert wird. Das bedeutet, dass 103 Early-Hinweise nicht zum Vorladen responsiver Bilder verwendet werden können und bei Verwendung zu diesem Zweck möglicherweise das falsche Bild geladen wird. Folgen Sie dieser Diskussion zu Vorschlägen, wie sich dieses Problem besser handhaben lässt.

Andere Browser haben ähnliche Einschränkungen und wie bereits erwähnt beschränken einige von ihnen 103 Vorabhinweise auf nur preconnect.

Nächste Schritte

Je nach Interesse der Community werden wir unsere Implementierung von Early Hints möglicherweise um die folgenden Funktionen ergänzen:

• Frühzeitige Hinweise für nicht im Cache ablegbare Ressourcen, bei denen der Arbeitsspeicher-Cache statt des HTTP-Cache verwendet wird.
• Bei Anfragen von Unterressourcen gesendete Hinweise.
• Frühzeitige Hinweise, die bei Anfragen an die Hauptressource des Iframes gesendet werden.
• Unterstützung für Prefetch in Early Hints.

Wir freuen uns auf Ihren Input dazu, welche Aspekte priorisiert werden sollten und wie wir Early Hints weiter verbessern können.

Beziehung zu H2/Push

Wenn Sie mit der veralteten HTTP2/Push-Funktion vertraut sind, fragen Sie sich vielleicht, inwiefern sich Early Hints davon unterscheidet. Während bei Early Hints ein Hin- und Rücklauf erforderlich ist, damit der Browser mit dem Abrufen wichtiger Unterressourcen beginnen kann, kann der Server bei HTTP2/Push Unterressourcen zusammen mit der Antwort senden. Das klingt zwar toll, hatte aber einen wichtigen strukturellen Nachteil: Bei HTTP2/Push war es extrem schwierig, zu verhindern, dass Unterressourcen gesendet wurden, die der Browser bereits hatte. Dieser Effekt führte zu einer weniger effizienten Nutzung der Netzwerkbandbreite, was die Leistungsvorteile erheblich beeinträchtigte. Insgesamt zeigten die Chrome-Daten, dass HTTP2/Push die Leistung im Web insgesamt negativ beeinflusste.

Im Gegensatz dazu funktioniert Early Hints in der Praxis besser, da es die Fähigkeit kombiniert, eine vorläufige Antwort zu senden, mit Hinweisen, die dem Browser das Abrufen oder Herstellen einer Verbindung zu den tatsächlich benötigten Informationen überlassen. Early Hints deckt zwar nicht alle Anwendungsfälle ab, die mit HTTP2/Push theoretisch behandelt werden könnten, aber wir sind der Meinung, dass Early Hints eine praktische Lösung zur Beschleunigung der Navigation ist.

Miniaturansicht von Pierre Bamin