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
Kenji Baheux
Barry Pollard

Was sind frühe Hinweise?

Websites sind im Laufe 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.

Bild, das eine Server-Ruhezeit von 200 ms zwischen dem Laden der Seite und dem Laden anderer Ressourcen zeigt
Ohne frühe Hinweise: Alles wird auf dem Server blockiert, um zu bestimmen, wie auf die Hauptressource reagiert werden soll.

„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 zu beschleunigen und untergeordnete Ressourcen 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.

Bild, das zeigt, wie mithilfe von Early Hints eine Teilantwort gesendet werden kann
Mit Early Hints: Der Server kann eine Teilantwort mit Ressourcenhinweisen senden, während er die endgültige Antwort ermittelt.

In einigen Fällen kann die Leistungssteigerung beim Largest Contentful Paint von mehreren hundert Millisekunden (wie bei Shopify und Cloudflare beobachtet) bis zu einer Sekunde betragen, wie in diesem Vorher-Nachher-Vergleich zu sehen ist:

Vergleich von zwei Websites
Vorher/Nachher-Vergleich von Early Hints auf einer Testwebsite mit WebPageTest (Moto G4 – DSL)

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. Das kann die Startseite oder eine beliebte Seite mit Produkteinträgen sein, wenn viele Nutzer von anderen Websites kommen. Diese Einstiegspunkte sind wichtiger als andere Seiten, da die Nützlichkeit von frühen Hinweisen mit zunehmender Navigation des Nutzers auf Ihrer Website abnimmt. Das bedeutet, dass der Browser bei der zweiten oder dritten Navigation mit größerer Wahrscheinlichkeit 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. Suchen Sie konkret nach renderblockierenden Unterressourcen wie synchronem JavaScript, Stylesheets oder sogar Webschriften. 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. Bei frühen Hinweisen ist der HTML-Code nicht verfügbar. Sie können stattdessen preconnect auf kritische Domains oder preload auf kritische Ressourcen verweisen, die sonst früh im HTML-Code gefunden würden, z. B. main.css oder app.js vorladen. Außerdem unterstützen nicht alle Browser preload für frühe Hinweise. Weitere Informationen finden Sie unter Browserunterstü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 eher 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
[...]

Nach wenigen Augenblicken wird die Webseite mit dem verknüpften CSS-Code 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 Hauptressourcen in zwei Teile aufteilen: einen stabilen Teil, der für die Verwendung mit Early Hints vorgesehen ist, und einen dynamischeren Teil, der nach Empfang der Hauptressource vom Browser abgerufen wird:

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

Suchen Sie abschließend auf der Serverseite nach Hauptressourcenanfragen, die von Browsern gesendet werden, die 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 Vorabverknüpfung:

Unterstützte Browser

  • Chrome: 103.
  • Edge: 103.
  • Firefox: 120.
  • Safari: 17.

Unterstützung für das Vorabladen:

Unterstützte Browser

  • Chrome: 103.
  • Edge: 103.
  • Firefox: 123.
  • Safari: Nicht unterstützt.

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

Netzwerkbereich mit Headern für frühzeitige Hinweise
In den Chrome-Entwicklertools werden Überschriften für „Early Hints“ Link angezeigt.

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:

Netzwerkbereich mit Early Hints-Initiatoren
Ressourcen mit frühen Hinweisen haben einen early-hints-Initiator und werden aus dem Datenträgercache geladen.

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:

Frühzeitige Hinweise 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:

Probleme mit 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 nur selten für das allgemeine Surfen im Web verwendet wurden.

Wenn nur 103 Early Hints als Antwort auf Clients gesendet werden, die einen sec-fetch-mode: navigate-HTTP-Anfrageheader senden, sollten diese Hinweise nur an neuere Clients gesendet werden, die wissen, dass sie auf die nachfolgende Antwort warten müssen. Da frühe Hinweise nur bei Navigationsanfragen unterstützt werden (siehe aktuelle Einschränkungen), wird außerdem verhindert, dass sie unnötigerweise 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.

Bei Besuchern, die im Rahmen eines typischen Nutzeraufrufs ihre n-te Seitenanfrage senden, können Sie die Antwort mit frühen Hinweisen an Inhalte weiter unten auf der Seite anpassen. Das bedeutet, dass Sie frühe Hinweise für Ressourcen mit niedrigerer Priorität verwenden. 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 die Early Hints und noch einmal über das Dokument). In Chrome ist der HTTP-Cache für nicht vertrauenswürdige HTTPS-Zertifikate deaktiviert, auch wenn Sie die Seite weiterhin 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. In dieser Diskussion finden Sie Vorschläge, wie Sie mit solchen Situationen besser umgehen können.

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 die 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-Caches verwendet wird.
  • Frühzeitige Hinweise, die bei Anfragen für Unterressourcen gesendet werden.
  • 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 beginnt, 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.

Frühe Hinweise schneiden dagegen in der Praxis besser ab, da sie die Möglichkeit zum Senden einer vorläufigen Antwort mit Hinweisen kombinieren, die dem Browser die Aufgabe überlassen, das abzurufen oder zu verbinden, was er tatsächlich benötigt. Frühzeitige Hinweise decken zwar nicht alle Anwendungsfälle ab, die HTTP2/Push theoretisch abdecken könnte, aber wir sind der Meinung, dass sie eine praktischere Lösung für die Beschleunigung der Navigation sind.

Miniaturansicht von Pierre Bamin