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

Finden Sie heraus, wie Ihr Server Hinweise zu wichtigen Unterressourcen an den Browser senden kann.

Was sind „Early Hints“?

Websites sind im Laufe der Zeit ausgefeilter geworden. Daher ist es nicht ungewöhnlich, dass ein Server nicht einfache Aufgaben (z. B. Zugriff auf Datenbanken oder CDNs, die auf den Ursprungsserver zugreifen) ausführen muss, um den HTML-Code für die angeforderte Seite zu generieren. Diese „Denkzeit des Servers“ führt leider zu einer zusätzlichen Latenz, bevor der Browser mit dem Rendern der Seite beginnen kann. Die Verbindung bleibt so lange inaktiv, wie der Server zur 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. Dadurch kann ein Server Hinweise auf kritische Unterressourcen (z. B. Stylesheets für die Seite, kritisches JavaScript) oder Ursprünge an den Browser senden, die wahrscheinlich von der Seite verwendet werden, während der Server mit der Generierung der Hauptressource beschäftigt ist. Der Browser kann diese Hinweise verwenden, um Verbindungen aufzuwärmen und Unterressourcen anzufordern, während er auf die Hauptressource wartet. Mit anderen Worten: Early Hints hilft dem Browser, diese „Denkzeit des Servers“ zu nutzen, indem er einige Vorarbeiten erledigt und so das Laden von Seiten beschleunigt.

In einigen Fällen kann die Leistungsverbesserung beim Largest Contentful Paint von Shopify und Cloudflare von mehreren hundert Millisekunden und bis zu einer Sekunde schneller erfolgen, wie in diesem Vorher-Nachher-Vergleich gezeigt:

So verwendest du Early Hints

Der erste Schritt zur Nutzung von Early Hints besteht darin, die besten Landingpages zu identifizieren, also die Seiten, auf denen die Nutzer normalerweise starten, wenn sie Ihre Website besuchen. Das kann die Startseite oder beliebte Seiten mit Produkteinträgen sein, wenn viele Nutzer von anderen Websites weitergeleitet werden. Diese Einstiegspunkte sind wichtiger als andere Seiten, da der Nutzen von „Early Hints“ mit zunehmender Navigation Ihrer Website abnimmt. Das heißt, der Browser verfügt mit größerer Wahrscheinlichkeit über alle erforderlichen Unterressourcen in der zweiten oder dritten Navigation. Es ist auch immer eine gute Idee, einen guten ersten Eindruck zu vermitteln!

Nachdem Sie diese priorisierte Liste mit Landingpages erstellt haben, müssen Sie im nächsten Schritt ermitteln, welche Ursprünge oder Unterressourcen sich gut für preconnect- oder preload-Hinweise eignen. In der Regel sind das Ursprünge und Unterressourcen, die am meisten zu wichtigen Nutzermesswerten wie Largest Contentful Paint oder First Contentful Paint beitragen. Genauer gesagt, suchen Sie nach Unterressourcen, die das Rendering blockieren, wie synchrones JavaScript, Stylesheets oder sogar Webschriftarten. Suchen Sie ebenso nach Ursprüngen, die Unterressourcen hosten, die einen großen Beitrag zu wichtigen Nutzermesswerten leisten.

Wenn Ihre Hauptressourcen bereits preconnect oder preload verwenden, können Sie diese Ursprünge oder Ressourcen als Kandidaten für „Early Hints“ in Betracht ziehen. Weitere Informationen zum Optimieren des LCP Allerdings ist es nicht optimal, die Anweisungen preconnect und preload von HTML in „Early Hints“ zu kopieren.

Wenn Sie diese in HTML verwenden, sollten Sie Ressourcen preconnect oder preload, die der Preload Scanner nicht im HTML-Code erkennt, z. B. Schriftarten oder Hintergrundbilder, die sonst erst später erkannt würden. Für Early Hints fehlt der HTML-Code, daher können Sie kritische Domains oder preload kritische Ressourcen, die sonst vielleicht zu Beginn des HTML-Codes gefunden werden, vielleicht ganz früh im HTML-Code finden, z. B. durch Vorabladen von main.css oder app.js. Außerdem unterstützen nicht alle Browser preload für Early Hints. Weitere Informationen finden Sie unter Browserunterstützung.preconnect

Der zweite Schritt besteht darin, das Risiko der Verwendung von Early Hints für Ressourcen oder Ursprünge zu minimieren, die möglicherweise veraltet oder von der Hauptressource nicht mehr verwendet werden. Beispielsweise sind Ressourcen, die häufig aktualisiert und versioniert werden (z. B. example.com/css/main.fa231e9c.css), nicht die beste Wahl. Beachten Sie, dass dieses Problem nicht nur für Early Hints gilt, sondern für alle preload oder preconnect, wo immer sie vorhanden sind. Diese Details sollten am besten mit Automatisierung oder Vorlagen umgehen. So ist es z. B. wahrscheinlicher, dass ein manueller Prozess zu nicht übereinstimmenden Hash- oder Versions-URLs zwischen „preload“ und dem HTML-Tag führt, das die Ressource nutzt.

Betrachten Sie als 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, die Anwendung mithilfe von Early Hints vorab zu laden:

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

Kurz darauf wird die Webseite, einschließlich des verknüpften Preisvergleichsportals, ausgeliefert. Leider wird diese CSS-Ressource häufig aktualisiert und die Hauptressource liegt bereits fünf Versionen vor der vorhergesagten CSS-Ressource (abcd100) (abcd105).

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

Versuche im Allgemeinen, Ressourcen und Ursprünge anzustreben, die ziemlich stabil und weitgehend unabhängig vom Ergebnis für die Hauptressource sind. Bei Bedarf können Sie Ihre Schlüsselressourcen in zwei Teile aufteilen: einen stabilen Teil, der für die Verwendung mit Early Hints vorgesehen ist, und einen dynamischeren 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 Hauptressourcen-Anfragen von Browsern, die Early Hints unterstützen, und antworten Sie sofort mit 103 Early Hints. Geben Sie in der 103-Antwort die relevanten Hinweise zum Vorverbinden und Vorabladen an. Sobald die Hauptressource bereit ist, antworten Sie mit der üblichen Antwort (z. B. „200 OK“, wenn der Vorgang erfolgreich war). Aus Gründen der Abwärtskompatibilität empfiehlt es sich, auch Link-HTTP-Header in die endgültige Antwort aufzunehmen, vielleicht sogar mit kritischen Ressourcen, die im Rahmen der Generierung der Hauptressource deutlich wurden (z. B. der dynamische Teil einer Schlüsselressource, wenn Sie dem Vorschlag „In zwei aufteilen“ gefolgt sind). So würde das 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

Ein paar Minuten 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

Obwohl 103 Early Hints in allen gängigen Browsern unterstützt wird, unterscheiden sich die Anweisungen, die bei einem Early Hint gesendet werden können, je nach Browser:

Pre-Connect-Unterstützung:

Unterstützung vorab:

Für die Chrome-Entwicklertools werden 103 Early Hints unterstützt.

Serversupport

Hier ist eine kurze Zusammenfassung des Supportniveaus für „Early Hints“ bei gängigen HTTP-Serversoftware von Open-Source-Software:

• Apache::unterstützt bei Verwendung von mod_http2.
• H2O: unterstützt.
• NGINX:Experimentelles Modul
• Knoten: Wird seit dem 18.11.0 für http und http2 unterstützt

„Frühe Hinweise“ jetzt noch einfacher aktivieren

Wenn Sie eines der folgenden CDNs oder Plattformen verwenden, müssen Sie Early Hints möglicherweise nicht manuell implementieren. Lesen Sie in der Onlinedokumentation Ihres Lösungsanbieters nach, ob er Early Hints unterstützt, oder ziehen Sie die folgende nicht vollständige Liste zurate:

• Erste Tipps bei Cloudflare
• Erste Tipps bei Fastly
• Erste Tipps für Akamai

Probleme bei Clients vermeiden, die Early Hints nicht unterstützen

HTTP-Antworten im Bereich von 100 mit Informationen sind Teil des HTTP-Standards, aber einige ältere Clients oder Bots können damit Probleme haben, da sie vor der Einführung von 103 Early Hints selten zum allgemeinen Surfen im Web verwendet wurden.

Wenn Sie nur 103 Early Hints als Antwort an Clients ausgeben, die einen sec-fetch-mode: navigate-HTTP-Anfrageheader senden, sollten solche Hinweise nur für neuere Clients gesendet werden, die auf die nächste Antwort warten möchten. Da „Early Hints“ nur für Navigationsanfragen unterstützt wird (siehe aktuelle Einschränkungen), verhindert dies außerdem, dass sie unnötigerweise bei anderen Anfragen gesendet werden.

Außerdem empfehlen wir, frühzeitige Hinweise nur über HTTP/2- oder HTTP/3-Verbindungen zu senden.

Erweitertes Muster

Wenn Sie die Funktion „Early Hints“ vollständig auf Ihre wichtigsten Landingpages angewendet haben und nach weiteren Werbechancen suchen, könnte das folgende erweiterte Muster für Sie von Interesse sein.

Für Besucher, die im Rahmen einer typischen User Journey die nth Seitenanfrage stellen, empfiehlt es sich, die Antwort der Funktion „Early Hints“ für Inhalte weiter unten auf der Seite anzupassen, also die Funktion „Early Hints“ für Ressourcen mit niedrigerer Priorität zu verwenden. Dies mag unlogisch klingen, da wir empfehlen, sich auf Unterressourcen oder Ursprünge mit hoher Priorität zu konzentrieren, die das Rendering blockieren. Wenn ein Besucher jedoch schon länger mit dem Internet unterwegs ist, ist es sehr wahrscheinlich, dass sein Browser bereits über alle kritischen Ressourcen verfügt. Danach kann es sinnvoll sein, Ihre Aufmerksamkeit auf Ressourcen mit niedrigerer Priorität zu richten. So könnten Sie beispielsweise „Early Hints“ zum Laden von Produktbildern verwenden oder zusätzliches JS/CSS, das nur für weniger häufige Nutzerinteraktionen benötigt wird.

Aktuelle Beschränkungen

Im Folgenden finden Sie die Einschränkungen der ersten Hinweise, die in Chrome implementiert sind:

• Nur für Navigationsanfragen verfügbar (Hauptressource für das Dokument der obersten Ebene).
• Unterstützt nur preconnect und preload, d. h. prefetch wird nicht unterstützt.
• „Early Hint“ gefolgt von einer ursprungsübergreifenden Weiterleitung bei der endgültigen Antwort führt dazu, dass Chrome die über „Early Hints“ abgerufenen Ressourcen und Verbindungen löscht.

Andere Browser haben ähnliche Einschränkungen, bei einigen gelten 103 frühe Hinweise weiter auf preconnect.

Nächste Schritte

Je nach Interesse der Community können wir unsere Implementierung von Early Hints um folgende Funktionen ergänzen:

• Frühe Hinweise zu Anfragen von Unterressourcen.
• Frühe Hinweise zu Anfragen an iFrame-Hauptressourcen.
• Unterstützung für Prefetch in Early Hints

Wir freuen uns über Ihr Feedback dazu, welche Aspekte priorisiert werden sollten und wie Sie „Early Hints“ weiter verbessern können.

Beziehung zu H2/Push

Wenn Sie mit der eingestellten HTTP2/Push-Funktion vertraut sind, fragen Sie sich vielleicht, worin sich die Funktion „Early Hints“ unterscheidet. Während Early Hints einen Umlauf erfordert, damit der Browser kritische Unterressourcen abrufen kann, könnte der Server mit HTTP2/Push damit beginnen, mit der Antwort Unterressourcen zu übertragen. Das klingt zwar erstaunlich, aber dies führte zu einem wesentlichen strukturellen Nachteil: Mit HTTP2/Push war es extrem schwierig, das Übertragen von Unterressourcen zu vermeiden, die bereits im Browser vorhanden waren. Dieser „Überschub“-Effekt führte zu einer weniger effizienten Nutzung der Netzwerkbandbreite, was die Leistungsvorteile erheblich beeinträchtigt. Insgesamt zeigten Chrome-Daten, dass HTTP2/Push tatsächlich ein negatives Ergebnis für die Leistung im Web war.

Im Gegensatz dazu funktioniert Early Hints in der Praxis besser, da es die Möglichkeit, eine vorläufige Antwort zu senden, mit Hinweisen kombiniert, die den Browser für das Abrufen oder Herstellen einer Verbindung zum eigentlichen Bedarf verantwortlich machen. „Early Hints“ deckt zwar nicht alle Anwendungsfälle ab, die HTTP2/Push theoretisch angehen könnte, wir sind jedoch der Meinung, dass Early Hints eine praktischere Lösung zur Beschleunigung der Navigation bietet.

Miniaturansicht von Pierre Bamin.