HTTP 103 Early Hints — Der Browser arbeitet, während der Server denkt

Ein Browser fordert ein Dokument an, doch der Server braucht möglicherweise Zeit, bevor er weiß, was er zurückgeben soll. Er muss vielleicht eine Datenbank abfragen, auf einen Upstream-Dienst warten oder eine Seite durch eine PHP-Anwendung rendern. Währenddessen wirkt die Verbindung untätig, obwohl der Server arbeitet. Gibt es eine sichere Möglichkeit, dem Browser schon vor der fertigen endgültigen Antwort etwas Sinnvolles zu tun zu geben?

HTTP 103 Early Hints ist eine solche Möglichkeit. Ein Server kann eine vorläufige Antwort mit Hinweisen auf wahrscheinlich benötigte Ressourcen senden. Ein Browser kann diese Hinweise verwenden, um eine Verbindung aufzubauen oder ein Stylesheet abzurufen, während er auf die endgültige Antwort wartet. Die entscheidenden Wörter sind vorläufig und wahrscheinlich: 103 ist nicht das Dokument und keine Zusage, dass die angegebene Ressource tatsächlich verwendet wird.

Die Lücke Vor Der Endgültigen Antwort

Betrachten wir eine langsame Dokumentanfrage. Der Browser sendet GET /dashboard. Die Anwendung führt anschließend mehrere Vorgänge aus, bevor sie HTML erzeugen kann. Wenn das Stylesheet und ein wichtiges Script bereits bekannt sind, wird Zeit verschenkt, wenn sie erst in der endgültigen Antwort erwähnt werden.

Mit Early Hints sieht die Abfolge ungefähr so aus:

GET /dashboard
Host: example.com

HTTP/2 103 Early Hints
Link: </assets/app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/2 200 OK
Content-Type: text/html
Link: </assets/app.css>; rel=preload; as=style

<!doctype html>
...

Die 103-Antwort teilt dem Client mit, was der Server voraussichtlich als Nächstes senden wird. Die endgültige Antwort muss weiterhin eintreffen, und ihre Header bleiben maßgeblich. Laut RFC 8297 kann ein Client die frühen Felder spekulativ auswerten, doch diese Auswertung darf nicht verändern, wie er die endgültige Antwort verarbeitet.

Was Kann Der Browser Tun?

Die nützlichsten Hinweise sind normalerweise Link-Felder. Mit rel=preload kann der Server eine Ressource angeben, die für die erste Seite wichtig ist, und mit as deren Zieltyp nennen. Mit rel=preconnect kann er vorschlagen, dass der Browser eine Verbindung zu einer anderen Origin vorbereitet.

Das sind weiterhin nur Hinweise. Der Browser kann feststellen, dass eine Ressource bereits im Cache liegt, nicht unterstützt wird, in der aktuellen Situation nicht sicher abgerufen werden kann oder nach einer Weiterleitung nicht mehr relevant ist. Die MDN-Referenz zu 103 erklärt ebenfalls, dass Browser Kompatibilitätsgrenzen haben und frühe Arbeit verwerfen können, wenn die endgültige Navigation zu einer anderen Origin weiterleitet.

Damit unterscheidet sich Early Hints von einem Stylesheet-Link im endgültigen HTML. Der HTML-Link wird erst entdeckt, wenn das Dokument eingetroffen ist. Ein 103-Link kann früher entdeckt werden, während der Server die Antwort noch vorbereitet. Early Hints unterscheidet sich auch von HTTP/2 Server Push: Early Hints schlägt Arbeit vor und überlässt dem Browser die Kontrolle über den Abruf, während Server Push Bytes sendet, auch wenn der Browser die Ressource möglicherweise schon besitzt.

Wann Ist Die Funktion Sinnvoll?

Early Hints ist nicht für jede Seite automatisch nützlich. Wenn eine Anwendung ihre endgültige Antwort sofort senden kann, reichen ein gewöhnlicher Link-Header oder ein HTML-Element <link> möglicherweise aus. Die Implementierungsanleitung von Google Chrome beschreibt Early Hints als Möglichkeit, die Denkzeit des Servers zu nutzen, nicht als Ersatz für grundlegende Ressourcenerkennung.

Geeignete Kandidaten haben meist drei Eigenschaften:

• Sie werden auf wichtigen Einstiegsseiten benötigt, etwa auf der Startseite oder einer häufig besuchten Landingpage.
• Sie sind stabil genug, damit der Server ihre URL vor der Dokumenterzeugung vorhersagen kann.
• Sie sind cachefähig und werden von der endgültigen Seite tatsächlich verwendet.

Ein Asset mit Hash, das sich bei jedem Deployment ändert, kann ein schlechter Kandidat sein, wenn Hinweis und erzeugtes HTML voneinander abweichen können. Eine selten verwendete Ressource verbraucht womöglich nur früher Bandbreite. Die Chrome-Dokumentation warnt ausdrücklich, dass eine nicht cachefähige Ressource zweimal abgerufen werden kann: einmal wegen des frühen Hinweises und erneut, wenn das Dokument sie entdeckt.

Der erste Schritt sollte daher nicht darin bestehen, überall Header hinzuzufügen. Identifiziere eine langsame Navigation, prüfe spät entdeckte Ressourcen und vergleiche eine kontrollierte Änderung mit einer Ausgangsmessung. Ohne diese Messung ist „schneller“ nur eine Annahme.

Ein Konservatives NGINX-Proxy-Muster

NGINX dokumentiert im HTTP-Core-Modul die Direktive early_hints. Die Direktive wurde mit NGINX 1.29.0 eingeführt und steuert, wann eine vom Upstream empfangene 103-Antwort an den Client weitergegeben wird. Das NGINX-Beispiel begrenzt sie auf HTTP/2 oder HTTP/3:

map $http_sec_fetch_mode $early_hints {
    navigate $http2$http3;
}

server {
    location / {
        early_hints $early_hints;
        proxy_pass http://application_backend;
    }
}

Dieses Beispiel erzeugt nicht von selbst eine 103-Antwort. Die Upstream-Anwendung muss die Informationsantwort und ihre Link-Felder senden. NGINX gibt eine Upstream-103-Antwort anschließend unverändert weiter, wenn die Bedingung erfüllt ist. Die offizielle NGINX-Dokumentation ist maßgeblich für Syntax und Versionsanforderung.

Die Prüfung auf navigate ist bewusst gewählt. Sie verhindert, dass jede Anfrage nach einem Bild, Script oder API-Ergebnis wie eine Dokumentnavigation behandelt wird. Der Ausdruck $http2$http3 hält das Beispiel außerdem von HTTP/1.1-Clients fern, sofern der Server nicht über einen konkreten Grund und Belege verfügt, dass diese Clients Informationsantworten korrekt verarbeiten.

Warum Die Endgültige Antwort Weiterhin Wichtig Ist

Es mag redundant wirken, den Link-Header in der endgültigen Antwort zu wiederholen, aber beide Antworten haben unterschiedliche Aufgaben. Die frühe Antwort gibt dem Client die Möglichkeit, Arbeit zu beginnen. Die endgültige Antwort beschreibt die tatsächliche Darstellung. Wenn die Anwendung ihre Entscheidung ändert, kann die endgültige Antwort einen Hinweis entfernen oder ersetzen.

Der HTML Living Standard beschreibt Early Hints als Teil des Link-Verarbeitungsmodells im Browser. Das macht ein Preload nicht zu einer Garantie. Es braucht weiterhin korrekte Zielmetadaten, passendes Cache-Verhalten und eine endgültige Seite, die die Ressource verwendet. Ein Browser kann außerdem einschränken, welche Hinweise er verarbeitet. MDN empfiehlt derzeit, 103 über HTTP/2 oder neuer zu senden, sofern der Server nicht weiß, dass seine Clients Informationsantworten sicher verarbeiten.

Grenzen Und Fehlerszenarien

Es gibt mehrere Gründe für Vorsicht:

• Die Verarbeitung ist spekulativ. Ein falscher Hinweis verbraucht Verbindungskapazität und Bandbreite, bevor der Server bewiesen hat, dass die Ressource benötigt wird.
• Die Funktion ersetzt weder Autorisierung noch Response-Header. Die endgültige Antwort bleibt die maßgebliche Quelle.
• Protokoll und Browserunterstützung sind wichtig. RFC 8297 warnt vor Clients, die Informationsantworten falsch behandeln, besonders über HTTP/1.1.
• Weiterleitungen können die Arbeit ungültig machen. Eine Navigation zu einer anderen Origin kann dazu führen, dass der Browser Ressourcen aus der frühen Antwort verwirft.
• Die Funktion benötigt Denkzeit des Servers. Wenn es keine nennenswerte Lücke vor der endgültigen Antwort gibt, sind gewöhnliches Preload oder Preconnect einfacher.

Diese Grenzen sprechen nicht gegen die Funktion. Sie erinnern daran, dass Early Hints eine Optimierungsschicht ist. Sie sollte eingeführt werden, nachdem Ressourcenstruktur, Caching, Protokollverhandlung und Messungen verstanden wurden.

Fazit

HTTP 103 Early Hints gibt dem Server eine kleine Zwischenbotschaft: „Während ich die Antwort vorbereite, ist diese Ressource wahrscheinlich wichtig.“ Der Browser kann diese Zeit für eine Verbindung oder ein Preload nutzen, darf den Hinweis aber auch ignorieren. Die endgültige Antwort bestimmt weiterhin den Seiteninhalt und die geltenden Header.

Für eine PHP-Anwendung hinter NGINX ist ein enger Einstieg am vernünftigsten: Wähle eine langsame Navigation, kündige nur stabile und cachefähige Ressourcen an, behalte die Hinweise in der endgültigen Antwort und begrenze die Weitergabe auf Clients und Protokolle, die damit umgehen können. Wenn die Messung kein besseres Ergebnis zeigt, kann die Optimierung problemlos entfernt werden. Eine kleinere, vorhersehbare Antwort ist oft besser als ein cleverer Hinweis, der falsch rät.

References

1. RFC 8297: An HTTP Status Code for Indicating Hints, Kazuho Oku, IETF, December 2017.
2. 103 Early Hints, MDN Web Docs, modified June 22, 2026.
3. 103 Early Hints, Kenji Baheux and Barry Pollard, Chrome for Developers, published June 23, 2022, updated July 10, 2026.
4. Module ngx_http_core_module: early_hints, NGINX documentation.
5. HTML Living Standard: Early hints, WHATWG, updated November 9, 2026.