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.

Kenji Baheux

Barry Pollard

Was ist „Early Hints“?

Websites sind mit der Zeit immer ausgefeilter geworden. Daher ist es nicht ungewöhnlich, dass ein Server nicht triviale 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 ist diese „Denkzeit für Server“ führt zu zusätzlicher Latenz, bevor der Browser mit dem Rendern der Seite beginnen kann. Tatsächlich bleibt die Verbindung effektiv so lange inaktiv, wie der Server die Antwort vorbereitet.

</ph>

„Early Hints“ ist ein HTTP-Statuscode (103 Early Hints), mit dem vor der endgültigen Antwort eine vorläufige HTTP-Antwort gesendet wird. Dadurch kann ein Server Hinweise zu wichtigen Unterressourcen (z. B. Stylesheets für die Seite, kritischem JavaScript) oder Ursprüngen an den Browser senden, die wahrscheinlich von der Seite verwendet werden, während der Server damit beschäftigt ist, die Hauptressource zu generieren. 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 „Server Denkzeit“ zu nutzen. indem Sie einige Vorkehrungen treffen, um den Seitenaufbau zu beschleunigen.

</ph>

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:

</ph>

Early Hints verwenden

Der erste Schritt zur Nutzung von Early Hints besteht darin, die wichtigsten Landingpages zu identifizieren, d. h. die Seiten, auf denen Ihre Nutzer normalerweise starten, wenn sie Ihre Website besuchen. Dies könnten die Startseite oder beliebte Seiten mit Produkteinträgen sein, falls viele Nutzer von anderen Websites kommen. Diese Einstiegspunkte sind wichtiger als andere Seiten, weil der Nutzen von Early Hints mit dem Nutzer abnimmt, wenn der Nutzer auf Ihrer Website navigiert. Das bedeutet, dass der Browser mit größerer Wahrscheinlichkeit in der zweiten oder dritten Navigation über alle erforderlichen Unterressourcen verfügt. Es ist auch immer eine gute Idee, einen guten ersten Eindruck zu liefern.

Nachdem Sie nun diese priorisierte Liste von Landingpages haben, müssen Sie im nächsten Schritt ermitteln, welche Ursprünge oder Unterressourcen gute Kandidaten für preconnect- oder preload-Hinweise wären. In der Regel sind dies Ursprünge und Unterressourcen, die den größten Beitrag zu wichtigen Nutzermesswerten wie Largest Contentful Paint oder First Contentful Paint leisten. 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 Ihre Hauptressourcen bereits preconnect oder preload verwenden, können Sie diese Ursprünge oder Ressourcen unter den Kandidaten für „Early Hints“ berücksichtigen. Weitere Informationen finden Sie unter LCP optimieren. Allerdings ist das einfache Kopieren der preconnect- und preload-Anweisungen von HTML in Early Hints möglicherweise nicht optimal.

Wenn Sie diese in HTML verwenden, sollten Sie normalerweise preconnect- oder preload-Ressourcen nutzen, die der Preload Scanner nicht im HTML-Code erkennt, beispielsweise Schriftarten oder Hintergrundbilder, die andernfalls erst spät erkannt würden. Für „Early Hints“ steht Ihnen der HTML-Code nicht zur Verfügung. Daher empfehlen wir, 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.

Der zweite Schritt besteht darin, das Risiko der Verwendung von Early Hints für Ressourcen oder Ursprünge zu minimieren, 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 möglicherweise nicht die beste Wahl. Beachten Sie, dass sich dieses Problem nicht speziell auf „Early Hints“ bezieht, sondern für alle preload oder preconnect, unabhängig davon, wo sie vorhanden sind. Diese Art von Detail eignet sich am besten für Automatisierung oder Vorlagen. Beispielsweise führt ein manueller Prozess eher zu nicht übereinstimmenden Hash- oder Versions-URLs zwischen preload und dem tatsächlichen HTML-Tag, für das die Ressource verwendet wird.

Betrachten Sie als Beispiel den folgenden Ablauf:

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

Der Server sagt voraus, dass main.abcd100.css benötigt wird, und schlägt vor, die Datei 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 regelmäßig aktualisiert und die Hauptressource ist der vorhergesagten CSS-Ressource (abcd100) bereits fünf Versionen voraus (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 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. Geben Sie in der 103-Antwort die entsprechenden Hinweise zum Vorverbindungs- und Vorabladen an. Sobald die Hauptressource bereit ist, folgen Sie 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. Sie können sogar mit kritischen Ressourcen erweitern, die bei der Generierung der Hauptressource deutlich wurden (z. B. dem dynamischen Teil einer Schlüsselressource, wenn Sie dem Vorschlag „In zwei aufteilen“ gefolgt sind). Das sieht dann so aus:

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

Einen Moment 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 Hints gesendet werden können, je nach Browser:

Unterstützung für Vorverbindung:

Support vorab laden:

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

</ph>

Zur Verwendung der „Early Hints“-Ressourcen darf Disable cache in den Entwicklertools nicht aktiviert sein, da „Early Hints“ den Browser-Cache verwendet. Bei vorab geladenen Ressourcen wird der Initiator als early-hints und die Größe als (Disk cache) angezeigt:

</ph>

Dies erfordert auch ein vertrauenswürdiges Zertifikat für HTTPS-Tests.

Firefox (ab Version 126) bietet keine explizite Unterstützung für 103 Early Hints in den Entwicklertools. Ressourcen, die mit Early Hints geladen werden, zeigen jedoch keine HTTP-Header-Informationen an. Dies ist ein Indikator dafür, dass sie über Early Hints geladen wurden.

Serversupport

Nachfolgend finden Sie eine kurze Zusammenfassung der Unterstützungsstufen für „Early Hints“ in der beliebten HTTP-Serversoftware für Open-Source-Software:

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

„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 können Sie nachlesen, ob „Early Hints“ unterstützt wird, oder in der folgenden Liste nachschlagen:

• Frühe Hinweise auf Cloudflare
• Frühe Hinweise auf Fastly
• Early Hints bei Akamai

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

HTTP-Informationsantworten im Bereich von 100 sind Teil des HTTP-Standards. Einige ältere Clients oder Bots haben jedoch möglicherweise Schwierigkeiten damit, da sie vor der Einführung von „103 Early Hints“ nur selten zum allgemeinen 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 sollten Early Hints nur über HTTP/2- oder HTTP/3-Verbindungen gesendet werden. Die meisten Browser akzeptieren sie auch nur über diese Protokolle.

Erweitertes Muster

Wenn Sie die Funktion „Frühe Hinweise“ vollständig auf Ihre wichtigsten Landingpages angewendet haben und nach weiteren Möglichkeiten suchen, könnte das folgende erweiterte Muster für Sie interessant sein.

Für Besucher, die im Rahmen einer typischen User Journey die x-te Seitenanfrage ausführen, 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 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 eine Weile auf der Website navigiert, ist es sehr wahrscheinlich, dass sein Browser bereits über alle kritischen Ressourcen verfügt. Ab diesem Zeitpunkt kann es sinnvoll sein, Ihre Aufmerksamkeit auf Ressourcen mit niedrigerer Priorität zu lenken. Beispielsweise könnten Sie Early Hints zum Laden von Produktbildern oder zusätzlichen JS-/CSS-Code verwenden, der nur für weniger häufige Nutzerinteraktionen benötigt wird.

Aktuelle Beschränkungen

Im Folgenden sind die Einschränkungen der Funktion „Early Hints“ in Chrome aufgeführt:

• Nur verfügbar für Navigationsanfragen (die Hauptressource für das Dokument auf oberster Ebene).
• Unterstützt nur preconnect und preload (d. h. prefetch wird nicht unterstützt).
• Wenn „Early Hints“ gefolgt von einer ursprungsübergreifenden Weiterleitung in der endgültigen Antwort folgt, führt dies dazu, dass Chrome die mit „Early Hints“ abgerufenen Ressourcen und Verbindungen verwirft.
• Ressourcen, die mit Early Hints vorab geladen werden, werden im HTTP-Cache gespeichert und von dort später von der Seite abgerufen. Daher können nur im Cache speicherbare Ressourcen mit „Early Hints“ vorab geladen werden oder die Ressource wird doppelt abgerufen (einmal von „Early Hints“ und noch einmal vom Dokument). In Chrome ist der HTTP-Cache für nicht vertrauenswürdige HTTPS-Zertifikate deaktiviert, selbst wenn Sie die Seite laden.
• Das Vorabladen responsiver Bilder (mit imagesrcset, imagesizes oder media) wird bei HTTP-<link>-Headern nicht unterstützt, da der Darstellungsbereich erst beim Erstellen des Dokuments definiert wird. Das bedeutet, dass 103 Early Hints nicht zum Vorabladen responsiver Bilder verwendet werden kann und in diesem Fall möglicherweise das falsche Bild geladen wird. Folgen Sie dieser Diskussion zu Vorschlägen, wie Sie dieses Problem besser handhaben können.

Andere Browser haben ähnliche Einschränkungen und wie bereits erwähnt, beschränken einige 103 frühe Hinweise auf preconnect.

Nächste Schritte

Je nach Interesse der Community können wir unsere Implementierung von Early Hints mit den folgenden Funktionen erweitern:

• Erste Hinweise für nicht im Cache speicherbare Ressourcen, die den Arbeitsspeicher-Cache anstelle des HTTP-Cache verwenden.
• Bei Anfragen von Unterressourcen gesendete Hinweise.
• Early Hints, die bei iFrame-Anfragen der Hauptressource gesendet wurden.
• Unterstützung für Prefetch in „Early Hints“.

Wir freuen uns über Ihr Feedback dazu, welche Aspekte Priorität haben sollten und wie wir „Early Hints“ weiter verbessern können.

Beziehung zu H2/Push

Wenn Sie mit der veralteten HTTP2/Push-Funktion vertraut sind, werden Sie sich vielleicht fragen, wie sich Early Hints unterscheidet. Während „Early Hints“ einen Umlauf erfordert, dass der Browser wichtige Unterressourcen abrufen kann, könnte der Server mit HTTP2/Push Unterressourcen zusammen mit der Antwort senden. Das klingt zwar erstaunlich, hat aber auch einen entscheidenden strukturellen Nachteil zur Folge: Mit HTTP2/Push war es äußerst schwierig, die Übertragung von Unterressourcen, die bereits im Browser vorhanden waren, zu vermeiden. Diese „übertriebene“ zu einer weniger effizienten Nutzung der Netzwerkbandbreite führten, was die Leistungsvorteile erheblich beeinträchtigte. Insgesamt zeigten die Chrome-Daten, dass HTTP2/Push im Hinblick auf die Leistung im Web tatsächlich negativ war.

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 HTTP2/Push theoretisch behandeln könnte, aber wir sind der Meinung, dass Early Hints eine praktischere Lösung für eine schnellere Navigation ist.

Miniaturansicht von Pierre Bamin.