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

Hier erfahren Sie, wie Ihr Server dem Browser Hinweise zu wichtigen untergeordneten Ressourcen senden kann.

Kenji Baheux

Barry Pollard

Veröffentlicht am 23. Juni 2022, zuletzt aktualisiert am 10. Juli 2026

Was sind Early Hints?

Websites sind im Laufe der Zeit immer komplexer geworden. Daher ist es nicht ungewöhnlich, dass ein Server nicht unerhebliche Arbeit leisten muss (z. B. Zugriff auf Datenbanken oder CDNs, die auf den Ursprungsserver zugreifen), um den HTML-Code für die angeforderte Seite zu erstellen. Leider führt diese „Server-Denkzeit“ zu einer zusätzlichen Latenz, bevor der Browser mit dem Rendering der Seite beginnen kann. Tatsächlich ist die Verbindung so lange inaktiv, wie der Server zum Vorbereiten der Antwort benötigt.

Early Hints ist ein HTTP-Statuscode (103 Early Hints), mit dem eine vorläufige HTTP-Antwort vor einer endgültigen Antwort gesendet wird. So kann ein Server dem Browser Hinweise zu wichtigen untergeordneten Ressourcen (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 aufzubauen und untergeordnete Ressourcen anzufordern, während er auf die Hauptressource wartet. Mit anderen Worten: Early Hints hilft dem Browser, diese „Server-Denkzeit“ zu nutzen, indem er einige Aufgaben im Voraus erledigt und so das Laden von Seiten beschleunigt.

In einigen Fällen kann die Leistungsverbesserung für den Largest Contentful Paint von mehreren Hundert Millisekunden, wie von Shopify und Cloudflare beobachtet, bis zu einer Sekunde schneller sein, wie in diesem Vorher-Nachher-Vergleich zu sehen ist:

Early Hints verwenden

Der erste Schritt, um Early Hints zu nutzen, besteht darin, die wichtigsten Landingpages zu ermitteln. Das sind die Seiten, auf denen Ihre Nutzer normalerweise beginnen, wenn sie Ihre Website besuchen. Das kann die Startseite oder beliebte Produkteinträge sein, wenn viele Nutzer von anderen Websites kommen. Der Grund, warum diese Einstiegspunkte wichtiger sind als andere Seiten, ist, dass der Nutzen von Early Hints abnimmt, wenn der Nutzer auf Ihrer Website navigiert. Das heißt, der Browser hat die benötigten untergeordneten Ressourcen mit größerer Wahrscheinlichkeit bei der zweiten oder dritten nachfolgenden Navigation. 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 untergeordneten Ressourcen gute Kandidaten für preconnect- oder preload-Hinweise wären. In der Regel sind das Ursprünge und untergeordnete Ressourcen, die am meisten zu wichtigen Nutzermesswerten wie Largest Contentful Paint oder First Contentful Paint beitragen. Suchen Sie genauer nach untergeordneten Ressourcen, die das Rendering blockieren, z. B. synchrones JavaScript, Stylesheets oder sogar Webfonts. Suchen Sie auch nach Ursprüngen, die untergeordnete Ressourcen 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 auch als Kandidaten für Early Hints in Betracht ziehen. Weitere Informationen finden Sie unter LCP optimieren. Es ist jedoch möglicherweise nicht optimal, die preconnect und preload Anweisungen einfach aus dem HTML-Code in Early Hints zu kopieren.

Wenn Sie diese in HTML verwenden, möchten Sie in der Regel Ressourcen preconnect oder preload, die der Preload Scanner nicht im HTML-Code findet, z. B. Schriftarten oder Hintergrundbilder, die sonst erst spät gefunden würden. Bei Early Hints haben Sie den HTML-Code nicht. Stattdessen können Sie preconnect zu wichtigen Domains oder preload zu wichtigen Ressourcen, die sonst möglicherweise früh im HTML-Code gefunden würden, z. B. main.css oder app.js. Außerdem unterstützen nicht alle Browser preload für Early Hints. Weitere Informationen finden Sie unter Unterstützte Browser.

Im zweiten Schritt wird das Risiko minimiert, Early Hints für Ressourcen oder Ursprünge zu verwenden, die möglicherweise veraltet sind oder nicht mehr von der Hauptressource verwendet werden. Ressourcen, die häufig aktualisiert und versioniert werden (z. B. example.com/css/main.fa231e9c.css), sind möglicherweise nicht die beste Wahl. Dieses Problem ist nicht spezifisch für Early Hints, sondern gilt für alle preload- oder preconnect-Anweisungen, wo immer sie vorhanden sind. Solche Details lassen sich am besten mit Automatisierung oder Vorlagen bearbeiten. Bei einem manuellen Prozess ist es wahrscheinlicher, dass Hash- oder Versions-URLs zwischen preload und dem tatsächlichen HTML-Tag, das die Ressource verwendet, nicht übereinstimmen.

Ein Beispiel:

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 mit Early Hints vorab zu laden:

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

Einige Augenblicke später wird die Webseite einschließlich des verknüpften CSS bereitgestellt. 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">

Im Allgemeinen sollten Sie Ressourcen und Ursprünge verwenden, die relativ stabil und weitgehend unabhängig vom Ergebnis für die Hauptressource sind. Bei Bedarf können Sie Ihre wichtigsten Ressourcen in zwei Teile aufteilen: einen stabilen Teil, der mit Early Hints verwendet werden soll, und einen dynamischeren Teil, der abgerufen werden soll, 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 auf dem Server nach Hauptressourcenanfragen, die von Browsern gesendet werden, die Early Hints unterstützen, und antworten Sie sofort mit 103 Early Hints. Fügen Sie in die 103-Antwort die relevanten Hinweise für die Vorabverbindung und das Vorabladen ein. Sobald die Hauptressource bereit ist, antworten Sie mit der üblichen Antwort (z. B. 200 OK, wenn erfolgreich). Aus Gründen der Abwärtskompatibilität empfiehlt es sich, auch Link-HTTP-Header in die endgültige Antwort aufzunehmen. Sie können sie sogar mit wichtigen Ressourcen ergänzen, die bei der Generierung der Hauptressource ermittelt wurden (z. B. der dynamische Teil einer wichtigen Ressource, wenn Sie den Vorschlag zur Aufteilung in zwei Teile befolgt haben). 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

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

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

Unterstützung für die Vorabverbindung :

Unterstützung für das Vorabladen :

Chrome-Entwicklertools unterstützt auch 103 Early Hints und die Link Header sind in den Dokumentressourcen zu sehen:

Wenn Sie die Early Hints-Ressourcen verwenden möchten, darf in DevTools die Option Disable cache nicht angekreuzt sein, da Early Hints den Browsercache verwendet. Bei vorab geladenen Ressourcen wird unter Initiator Early-hints und unter Größe (Disk cache) angezeigt:

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

Firefox unterstützt 103 Early Hints nicht explizit als Initiator in DevTools. Ressourcen, die mit Early Hints geladen wurden, werden jedoch in der Spalte Übertragen als cached angezeigt und haben beim Klicken auf sie einen HTTP-Anfrageheader X-Moz: early hint.

Server support

Hier eine kurze Zusammenfassung der Unterstützung für Early Hints in gängiger Open-Source-HTTP-Serversoftware:

• Apache:wird mit mod_http2 unterstützt.
• H2O:wird unterstützt.
• NGINX:wird unterstützt.
• Node:wird für http und http2 unterstützt.

Early Hints einfacher aktivieren

Wenn Sie eines der folgenden CDNs oder eine der folgenden Plattformen verwenden, müssen Sie Early Hints möglicherweise nicht manuell implementieren. In der Online-Dokumentation Ihres Lösungsanbieters erfahren Sie, ob Early Hints unterstützt werden. Alternativ können Sie sich die nicht vollständige Liste hier ansehen:

• Early Hints bei Cloudflare
• Early Hints bei Fastly.
• Early Hints bei Akamai.

Probleme für Clients vermeiden, die Early Hints nicht unterstützen

Informative HTTP-Antworten im 100er-Bereich 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 Sie 103 Early Hints nur als Antwort auf Clients senden, die einen HTTP-Anfrageheader sec-fetch-mode: navigate 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 außerdem nur für Navigationsanfragen unterstützt werden (siehe aktuelle Einschränkungen), wird so vermieden, dass sie unnötig für andere Anfragen gesendet werden.

Außerdem sollten Early Hints nur über HTTP/2- oder HTTP/3-Verbindungen gesendet werden. Die meisten Browser akzeptieren sie nur über diese Protokolle.

Erweitertes Muster

Wenn Sie Early Hints vollständig auf Ihre wichtigsten Landingpages angewendet haben und nach weiteren Möglichkeiten suchen, ist das folgende erweiterte Muster möglicherweise interessant für Sie.

Bei Besuchern, die sich bei einer typischen Nutzerreise in der n-ten Seitenanfrage befinden, können Sie die Early Hints-Antwort an Inhalte anpassen, die weiter unten auf der Seite zu finden sind. Mit anderen Worten: Sie verwenden 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 Rendering blockieren. Wenn ein Besucher jedoch schon eine Weile navigiert hat, hat sein Browser sehr wahrscheinlich bereits alle wichtigen Ressourcen. Ab diesem Zeitpunkt kann es sinnvoll sein, sich auf Ressourcen mit niedrigerer Priorität zu konzentrieren. Das kann beispielsweise bedeuten, dass Sie Early Hints verwenden, um Produktbilder oder zusätzliches JS/CSS zu laden, das nur für weniger häufige Nutzerinteraktionen erforderlich ist.

Aktuelle Beschränkungen

Hier sind die Einschränkungen von Early Hints, wie sie in Chrome implementiert sind:

• Nur für Navigationsanfragen verfügbar (d. h. die Hauptressource für das Dokument der obersten Ebene).
• Unterstützt nur preconnect und preload (d. h. prefetch wird nicht unterstützt).
• Wenn auf Early Hints eine Cross-Origin-Weiterleitung in der endgültigen Antwort folgt, verwerfen Browser die Ressourcen und Verbindungen, die sie mit Early Hints erhalten haben.
• Ressourcen, die mit 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, mit Early Hints vorab geladen werden. Andernfalls wird die Ressource doppelt abgerufen (einmal von Early Hints und einmal vom Dokument). In Chrome ist der HTTP-Cache für nicht vertrauenswürdige HTTPS-Zertifikate deaktiviert (auch wenn Sie die Seite laden).
• Das Vorabladen responsiver Bilder (mit imagesrcset, imagesizes oder media) wird möglicherweise nicht mit HTTP <link> Headern unterstützt, da der Darstellungsbereich erst definiert wird, wenn das Dokument erstellt wurde. Im besten Fall warten sie, bis das Dokument empfangen wurde, wodurch die Hauptvorteile von 103 Early Hints zunichte gemacht werden.

Andere Browser haben ähnliche Einschränkungen und, wie bereits erwähnt, beschränken einige 103 Early Hints nur auf preconnect.

Beziehung zu H2/Push

Wenn Sie mit der eingestellten Funktion HTTP2/Push vertraut sind, fragen Sie sich vielleicht, wie sich Early Hints davon unterscheiden. Bei Early Hints ist ein Roundtrip erforderlich, damit der Browser mit dem Abrufen wichtiger untergeordneter Ressourcen beginnen kann. Bei HTTP2/Push konnte der Server untergeordnete Ressourcen zusammen mit der Antwort senden. Das klingt zwar gut, hatte aber einen entscheidenden strukturellen Nachteil: Mit HTTP2/Push war es extrem schwierig zu vermeiden, untergeordnete Ressourcen zu senden, die der Browser bereits hatte. Dieser „Über-Push“-Effekt führte zu einer weniger effizienten Nutzung der Netzwerkbandbreite, was die Leistungsverbesserungen erheblich beeinträchtigte. Insgesamt zeigten Chrome-Daten, dass HTTP2/Push tatsächlich einen negativen Nettoeffekt auf die Leistung im gesamten Web hatte.

Im Gegensatz dazu funktioniert Early Hints in der Praxis besser, da es die Möglichkeit kombiniert, eine vorläufige Antwort mit Hinweisen zu senden, die den Browser in die Lage versetzen, das abzurufen oder sich damit zu verbinden, was er tatsächlich benötigt. Early Hints deckt zwar nicht alle Anwendungsfälle ab, die HTTP2/Push theoretisch abdecken könnte, aber wir sind der Meinung, dass Early Hints eine praktischere Lösung ist, um die Navigation zu beschleunigen.

Miniaturansicht von Pierre Bamin.