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

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

Baheux
Kenji Baheux
Pollard

Was sind „Early Hints“?

Websites werden mit der Zeit immer ausgefeilter. Daher ist es nicht ungewöhnlich, dass ein Server nicht einfache Aufgaben ausführen muss (z. B. Zugriff auf Datenbanken oder CDNs, die auf den Ursprungsserver zugreifen), um den HTML-Code für die angeforderte Seite zu generieren. Leider führt diese „Nachdenken des Servers“ zu zusätzlicher Latenz, bevor der Browser mit dem Rendern der Seite beginnen kann. Tatsächlich bleibt die Verbindung so lange inaktiv, wie der Server benötigt, um die Antwort vorzubereiten.

Bild, das den Server mit einer Zeitlücke von 200 ms zwischen dem Laden der Seite und dem Laden anderer Ressourcen zeigt.
Ohne frühzeitige Hinweise: Alles wird auf dem Server blockiert und bestimmt, wie auf die Hauptressource geantwortet wird.

"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 auf kritische Unterressourcen (z. B. Stylesheet 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, eine solche „Server-Nachdenken“ zu nutzen, indem er einige Vorarbeiten erledigt und so das Laden der Seiten beschleunigt.

Abbildung, die zeigt, wie die Seite mithilfe von Early Hints eine Teilantwort senden kann.
Mit Early Hints: Der Server kann eine Teilantwort mit Ressourcenhinweisen bereitstellen, während er die endgültige Antwort bestimmt

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

Vergleich von zwei Websites
Vorher/Nachher-Vergleich der ersten Hinweise auf einer Testwebsite mit WebPageTest (Moto G4 – DSL)

Frühe Hinweise implementieren

Bevor wir tiefer in das Thema einsteigen, beachten Sie bitte, dass "Erste Hinweise" nicht nützlich sind, wenn Ihr Server sofort 200-Antworten (oder andere endgültige Antworten) senden kann. In solchen Fällen kannst du das reguläre link rel=preload oder link rel=preconnect in der Hauptantwort (rel-HTTP-Header verknüpfen) bzw. in der Hauptantwort (<link>-Elemente) verwenden. Falls Ihr Server etwas Zeit benötigt, um die Hauptantwort zu generieren, lesen Sie weiter!

Der erste Schritt zur Nutzung von Early Hints besteht darin, die besten Landingpages zu identifizieren, also die Seiten, auf denen Nutzer normalerweise starten, wenn sie Ihre Website besuchen. Dies 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, weil der Nutzen von „Early Hints“ mit der Navigation der Nutzer auf Ihrer Website abnimmt. Das bedeutet, dass der Browser bei der zweiten oder dritten Navigation wahrscheinlich alle Unterressourcen hat, die er benötigt. Es ist auch immer eine gute Idee, einen guten ersten Eindruck zu vermitteln.

Nachdem Sie nun diese priorisierte Liste von Landingpages haben, besteht der nächste Schritt darin, als ersten Annäherung zu ermitteln, welche Ursprünge oder Unterressourcen sich gut für Preconnect- oder Preload-Hinweise eignen. In der Regel sind das die 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. Ebenso sollten Sie nach Ursprüngen suchen, die Unterressourcen hosten, die einen großen Beitrag zu wichtigen Nutzermesswerten leisten. Hinweis: Wenn Ihre Hauptressourcen bereits <link rel=preconnect> oder <link rel=preload> verwenden, können Sie diese Ursprünge oder Ressourcen als Kandidaten für „Early Hints“ in Betracht ziehen. Weitere Informationen finden Sie in diesem Artikel.

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 nicht die beste Wahl. Beachten Sie, dass sich dieses Problem nicht nur auf „Early Hints“ bezieht, sondern auf alle Links rel=preload oder rel=preconnect, wo auch immer sie vorhanden sind. Diese Art von Detail eignet sich am besten für Automatisierung oder Vorlagen. So ist es beispielsweise wahrscheinlicher, dass ein manueller Prozess zu nicht übereinstimmenden Hash- oder Versions-URLs zwischen link rel=preload und dem HTML-Tag führt, das die Ressource verwendet.

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 erforderlich sein wird, und schlägt vor, die API über „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 bereitgestellt. Leider wird diese CSS-Ressource häufig aktualisiert und die Hauptressource liegt bereits fünf Versionen hinter der vorhergesagten CSS-Ressource (abcd100) (abcd105).

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

Im Allgemeinen solltest du Ressourcen und Ursprünge anstreben, die ziemlich stabil und weitgehend unabhängig vom Ergebnis für die Hauptressource sind. Bei Bedarf können Sie Ihre Schlüsselressourcen aufteilen: einen stabilen Teil, der für die Verwendung mit frühen Hinweisen 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 auf der Serverseite schließlich nach Hauptressourcenanfragen von Browsern, die Früher Hinweise unterstützen, und antworten Sie sofort mit 103 Frühen Hinweisen. Fügen Sie in die 103-Antwort die entsprechenden Hinweise zum Vorverbindungs- und Vorabladen ein. Sobald die Hauptressource bereit ist, senden Sie die übliche 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 beim Generieren der Hauptressource offensichtlich wurden (z. B. den dynamischen Teil einer Schlüsselressource, wenn Sie dem Vorschlag „In zwei aufteilen“ 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

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 von allen gängigen Browsern unterstützt wird, unterscheiden sich die Anweisungen, die mit einem Early Hints gesendet werden können, je nach Browser:

Preconnect-Unterstützung:

Unterstützte Browser

  • 103
  • 103
  • 120
  • 17

Unterstützung für das Vorabladen:

Unterstützte Browser

  • 103
  • 103
  • x

Serversupport

Im Folgenden finden Sie eine kurze Zusammenfassung der Unterstützung für Early Hints durch gängige OSS-HTTP-Serversoftware:

Frühzeitige Hinweise ganz einfach aktivieren

Wenn Sie eines der folgenden CDNs oder Plattformen verwenden, müssen Sie Early Hints möglicherweise nicht manuell implementieren. Ob der Lösungsanbieter Early Hints unterstützt, können Sie der Onlinedokumentation Ihres Lösungsanbieters entnehmen. Alternativ können Sie die folgende unvollständige Liste heranziehen:

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

Informationale HTTP-Antworten im Bereich von 100 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 für das allgemeine Surfen im Web verwendet wurden.

Wenn du 103 Early Hints nur als Antwort an Clients ausgibst, die einen sec-fetch-mode: navigate-HTTP-Anfrageheader senden, sollte sichergestellt werden, dass solche Hinweise nur für neuere Clients gesendet werden, die auf die nachfolgende Antwort warten möchten. Da Frühe Hinweise nur bei Navigationsanfragen unterstützt werden (siehe aktuelle Einschränkungen), hat dies außerdem den Vorteil, dass sie nicht unnötig für andere Anfragen gesendet werden müssen.

Außerdem sollten Sie Tipps für das Senden von Hinweisen nur über HTTP/2- oder HTTP/3-Verbindungen senden.

Erweitertes Muster

Wenn Sie die Funktion „Erste Tipps“ vollständig auf Ihre wichtigsten Landingpages angewendet haben und nach weiteren Möglichkeiten suchen, ist möglicherweise das folgende erweiterte Muster für Sie interessant.

Für Besucher, die im Rahmen eines typischen Kaufprozesses die n. Seitenanfrage stellen, empfiehlt es sich, die Antwort des ersten Hinweises an Inhalte weiter unten auf der Seite anzupassen, d. h. die Funktion „Erste Hinweise“ für Ressourcen mit niedrigerer Priorität verwenden. Das mag widersprüchlich 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 eine Weile navigiert ist, ist es sehr wahrscheinlich, dass sein Browser bereits über alle wichtigen Ressourcen verfügt. Danach kann es sinnvoll sein, Ihre Aufmerksamkeit auf Ressourcen mit niedrigerer Priorität zu richten. Dies könnte beispielsweise bedeuten, dass Sie Early Hints verwenden, um Produktbilder zu laden, oder zusätzliches JavaScript/CSS, das nur für weniger häufige Nutzerinteraktionen benötigt wird.

Aktuelle Beschränkungen

Im Folgenden sind die Einschränkungen der Funktion „Frühe Hinweise“ in Chrome aufgeführt:

  • Nur für Navigationsanfragen verfügbar (d. h. die Hauptressource für das übergeordnete Dokument).
  • 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“ gewonnenen Ressourcen und Verbindungen löscht.

Andere Browser haben ähnliche Einschränkungen und beschränken 103 frühe Hinweise weiter auf preconnect.

Nächste Schritte

Abhängig vom Interesse der Community können wir unsere Implementierung von Early Hints um folgende Funktionen ergänzen:

  • Frühe Hinweise, die für Anfragen von Unterressourcen gesendet werden.
  • Frühe Hinweise zu iFrame-Hauptressourcenanfragen.
  • Unterstützung für Prefetch in Early Hints.

Wir freuen uns über Ihr Feedback dazu, welche Aspekte Sie priorisieren sollten und wie Sie "Early Hints" weiter verbessern können.

Beziehung zu H2/Push

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

Im Gegensatz dazu funktioniert Early Hints in der Praxis besser, da es die Fähigkeit, eine vorläufige Antwort zu senden, mit Hinweisen kombiniert, die es dem Browser überlassen, das abzurufen oder eine Verbindung zu dem herzustellen, was er tatsächlich benötigt. „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 für eine schnellere Navigation ist.

Miniaturansicht von Pierre Bamin.