103 Early Hints: Kritische Ressourcen während der Server-Denkzeit vorab laden

Zuletzt geprüft von Arjen Karel im März 2026

Was sind 103 Early Hints?

Early Hints ist ein HTTP-Statuscode (103), der gesendet wird, bevor der Webserver die endgültige Antwort sendet. Damit kann der Server dem Browser früh im Ladevorgang mitteilen, dass bestimmte Ressourcen wie ein Bild oder ein Stylesheet für das Rendern der Seite kritisch sind.

Die meisten dynamischen Seiten brauchen Zeit zur Generierung. Der Server fragt eine Datenbank ab, führt Anwendungslogik aus und baut das HTML zusammen. Während dieser Verarbeitungszeit wartet der Browser einfach. 103 Early Hints füllen diese Lücke. Sie sagen dem Browser, was er abrufen soll, während er auf die echte Antwort wartet.

Early Hints ersetzen den veralteten HTTP/2 Server Push. Chrome hat diesen in Version 106 entfernt. Server Push bündelte Ressourcen mit der endgültigen Antwort. Dabei wurden oft Daten gepusht, die der Browser bereits im Cache hatte. Early Hints vermeiden dieses Problem. Sie geben nur Hinweise. Der Browser entscheidet, ob er darauf reagiert.

Browser-Unterstützung

103 Early Hints wird von 93 % der Browser weltweit unterstützt:

• Chrome 103+ und Edge 103+: volle Unterstützung für preconnect und preload (seit Juni 2022)
• Firefox 123+: volle Unterstützung für preconnect und preload (seit Februar 2024)
• Safari 17+: nur preconnect. Safari unterstützt kein preload in 103-Antworten

Diese Safari-Einschränkung ist wichtig. Wenn deine Early Hints-Strategie nur auf das Preloading von Bildern oder Schriftarten setzt, profitieren Safari-Nutzer nicht davon. Binde preconnect-Hinweise zusammen mit preload-Hinweisen ein. So wärmt Safari zumindest die Verbindung zu den Ursprüngen deiner Ressourcen auf.

Early Hints funktionieren nur über HTTP/2 oder HTTP/3. Sie funktionieren nicht über HTTP/1.1, aus iframes oder für Non-Navigation-Requests. Der Browser verarbeitet nur Hinweise für preload und preconnect. dns-prefetch und prefetch werden in 103-Antworten nicht unterstützt.

Wie sehen 103 Early Hints aus?

Wenn ein Browser eine Seite anfordert, gibt der Server sofort eine 103-Antwort zurück, bevor er das HTML fertig generiert hat. Diese Antwort sagt dem Browser, dass er anfangen soll, das LCP-Bild und das Stylesheet abzurufen:

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image
Link: </style.css>; rel=preload; as=style

In der Zwischenzeit generiert der Server die Seite. Sobald sie fertig ist, sendet er die endgültige Antwort:

HTTP/2 200 OK
Content-Length: 1234
[der Rest der Antwort]

Wenn der Browser die 200-Antwort erhält, lädt er Bild und Stylesheet bereits herunter. Dieser Vorsprung macht den Largest Contentful Paint schneller.

So sendest du 103 Early Hints

Du hast drei Hauptoptionen, von der einfachsten bis zur größten Kontrolle.

Cloudflare (am einfachsten)

Wenn du bereits Cloudflare für die Performance nutzt, ist das Aktivieren von Early Hints nur ein einziger Schalter. Navigiere zu Speed > Settings > Content Optimization und aktiviere Early Hints. Das Feature ist in allen Tarifen verfügbar, auch in der kostenlosen Version.

Cloudflare speichert die Link-Header aus den 200-Antworten deines Ursprungsservers. Bei nachfolgenden Anfragen sendet es diese gecachten Header als 103-Antwort, bevor es die Anfrage an deinen Server weiterleitet. Du stellst die Hinweise bereit, indem du Link-Header aus deiner Anwendung sendest:

header("Link: </image.webp>; rel=preload; as=image", false);
header("Link: </style.css>; rel=preload; as=style", false);

NGINX (nativ seit 1.29.0)

NGINX hat in Version 1.29.0 (Juni 2025) native Unterstützung für 103 Early Hints hinzugefügt. Die Direktive early_hints leitet 103-Antworten von deinem Backend an den Client weiter:

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

server {
    location / {
        early_hints $early_hints;
        proxy_pass http://backend.example.com;
    }
}

Die sec-fetch-mode-Map stellt sicher, dass Hinweise nur für Navigation-Requests über HTTP/2 oder HTTP/3 gesendet werden. Deine Backend-Anwendung muss die 103-Antwort generieren. NGINX leitet sie nur durch.

Apache (2.4.58+)

Apache kann 103-Antworten mit mod_http2 selbst generieren. Aktiviere es mit der H2EarlyHints-Direktive und definiere die Ressourcen für die Hinweise:

H2EarlyHints on
H2EarlyHint Link "</style.css>;rel=preload;as=style"
H2EarlyHint Link "</image.webp>;rel=preload;as=image"

Im Gegensatz zu NGINX generiert Apache die 103-Antwort direkt auf Serverebene. Deine Anwendung muss sie nicht erzeugen.

Wann Early Hints helfen (und wann nicht)

103 Early Hints sind am effektivsten, wenn dein Server spürbar Zeit für die Antwort braucht. Das gilt für dynamische Seiten, die Datenbanken abfragen, APIs aufrufen oder Templates rendern. Je langsamer die Time to First Byte ist, desto mehr Zeit hat der Browser für die Hinweise.

Early Hints bieten weniger Vorteile, wenn:

• Dein Server antwortet in unter 100 ms. Wenn die TTFB bereits schnell ist, gibt es keine Lücke für den Browser. Konzentriere dich stattdessen auf die Ressourcenpriorisierung in deinem HTML.
• Seiten kommen aus dem Cache. Eine vollständig gecachte HTML-Antwort lädt so schnell, dass die 103-Antwort kaum einen Vorsprung hat.
• Du sendest Hinweise für zu viele Ressourcen. Hinweise auf über 10 Ressourcen sättigen die Verbindung. Das kann alles verlangsamen. Shopify hat festgestellt, dass aggressives Hinting auf Mobilgeräten zu Performance-Einbußen bei TTFB, FCP und LCP führt. Beschränke dich auf 2 bis 4 kritische Ressourcen.

Trotz 93 % Browser-Unterstützung bleibt die Nutzung gering. Laut dem Web Almanac 2025 nutzen nur etwa 5 % der Top-Websites 103 Early Hints. Die größte Hürde: Man muss wissen, für welche Ressourcen pro Seite Hinweise gesendet werden sollen. Die meisten CMS können das nicht automatisch.

So überprüfst du, ob Early Hints funktionieren

Öffne die Chrome DevTools, wechsle zum Network-Panel und lade die Seite neu. Klicke auf den Document-Request und prüfe die Response-Header. Wenn Early Hints funktionieren, siehst du in der Timing-Aufschlüsselung einen 103-Status vor der 200.

Auf der Kommandozeile kannst du es mit curl überprüfen:

curl -v --http2 https://example.com 2>&1 | grep "< HTTP"

Du solltest sowohl eine 103- als auch eine 200-Antwort sehen.

Testergebnisse

Ich habe zwei Szenarien getestet, um die Auswirkungen auf den First Contentful Paint und den Largest Contentful Paint zu messen.

1. Early Hints nur für das LCP-Bild

Das LCP-Bild erschien mit 103 Early Hints 35 % früher auf dem Bildschirm als mit einem normalen Preload im HTML.

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image

2. Early Hints mit einem großen Stylesheet und dem LCP-Bild

Eine 85 KB große CSS-Datei in den Hinweisen machte den Unterschied noch deutlicher. Der FCP verbesserte sich von 1,8 Sekunden auf 1,4 Sekunden. Der LCP verbesserte sich von 3,2 Sekunden auf 2,0 Sekunden.

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image
Link: </style.css>; rel=preload; as=style

Diese Zahlen decken sich mit dem, was Cloudflare bei über 100.000 Kunden gemessen hat: eine LCP-Verbesserung von 6 % beim 50. Perzentil und 16 % beim 75. Perzentil auf dem Desktop. Shopify verzeichnete eine LCP-Verbesserung von 500 ms bei p50 während Black Friday und Cyber Monday. Die größten Gewinne gibt es bei Seiten mit langsamen Server-Antwortzeiten. Genau dann haben Early Hints die meiste Zeit, um zu wirken.

Early Hints und TTFB

Hier gibt es eine Besonderheit bei der Messung. Seit Chrome 133 beinhaltet das responseStart-Timing des Browsers (das die meisten Tools für die TTFB nutzen) die 103-Antwort. Das bedeutet, dass deine gemeldete TTFB nach der Aktivierung von Early Hints sinkt. Die tatsächliche Verarbeitungszeit deines Servers ändert sich dabei nicht.

Wenn du die Verarbeitungszeit des Servers separat messen musst: Chrome 133 hat den neuen Zeitstempel firstResponseHeadersStart eingeführt. Er meldet, wann die finalen 200-Response-Header ankommen. Real User Monitoring-Tools, die beide Werte erfassen, zeigen dir das komplette Bild: Wie viel Zeit Early Hints dem Browser gespart haben und wie lange dein Server tatsächlich für die Antwort brauchte.