103 Early Hints: Kritische Ressourcen vorab laden, während der Server die Seite verarbeitet

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

Was sind 103 Early Hints?

Early Hints ist ein HTTP-Statuscode (103), den der Webserver vor der eigentlichen Antwort sendet. Damit teilt der Server dem Browser früh im Ladeprozess mit, dass bestimmte Ressourcen wie ein Bild oder Stylesheet kritisch für das Rendering der Seite sind.

Die meisten dynamischen Seiten brauchen Zeit bei der Erstellung. Der Server fragt eine Datenbank ab, führt Anwendungslogik aus und baut das HTML zusammen. Während dieser Zeit wartet der Browser nur. 103 Early Hints schließen diese Lücke: Sie sagen dem Browser, was er laden soll, während er auf die eigentliche Antwort wartet.

Early Hints ersetzen das veraltete HTTP/2 Server Push, das Chrome in Version 106 entfernt hat. Server Push packte Ressourcen mit in die finale Antwort und übertrug oft Bytes, die der Browser längst gecacht hatte. Early Hints vermeiden dieses Problem: Sie geben nur Hinweise. Der Browser entscheidet selbst, ob er darauf reagiert.

Browser-Support

103 Early Hints werden 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 preload in 103-Antworten nicht

Die Einschränkung bei Safari fällt ins Gewicht. Setzt deine Early-Hints-Strategie rein auf das Preloading von Bildern oder Schriften, haben Safari-Nutzer nichts davon. Sende neben Preload-Hinweisen auch preconnect mit, damit Safari zumindest vorab die Verbindung zu den Origins deiner Ressourcen aufbaut.

Early Hints funktionieren nur über HTTP/2 oder HTTP/3. Über HTTP/1.1, in Iframes oder bei Nicht-Navigations-Requests funktionieren sie nicht. Der Browser verarbeitet ausschließlich Hinweise für preload und preconnect; dns-prefetch und prefetch werden in 103-Antworten nicht unterstützt.

Wie sehen 103 Early Hints aus?

Fordert ein Browser eine Seite an, liefert der Server sofort eine 103-Antwort aus, noch bevor er das HTML fertig generiert hat. Diese Antwort weist den Browser an, 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

Währenddessen generiert der Server die Seite. Sobald sie fertig ist, sendet er die finale Antwort:

HTTP/2 200 OK
Content-Length: 1234
[the rest of the response]

Sobald die 200-Antwort beim Browser ankommt, läuft der Download von Bild und Stylesheet bereits. Genau dieser Vorsprung macht den Largest Contentful Paint schneller.

So sendest du 103 Early Hints

Du hast drei Optionen – vom einfachsten Weg bis zur maximalen Kontrolle.

Cloudflare (am einfachsten)

Nutzt du bereits Cloudflare für Performance, aktivierst du Early Hints mit einem einzigen Schalter. Navigiere zu Speed > Settings > Content Optimization und aktiviere Early Hints. Das ist in allen Tarifen verfügbar, auch im kostenlosen.

Cloudflare cacht die Link-Header aus den 200-Antworten deines Origin-Servers. Bei nachfolgenden Requests sendet Cloudflare diese gecachten Header als 103-Antwort, bevor die Anfrage an deinen Origin weitergeleitet wird. Du definierst die Hinweise, indem deine Anwendung entsprechende Link-Header mitsendet:

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 bietet seit Version 1.29.0 (Juni 2025) native Unterstützung für 103 Early Hints. Die Direktive early_hints leitet 103-Antworten vom 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;
    }
}

Das Mapping über sec-fetch-mode stellt sicher, dass Hinweise nur bei Navigations-Requests über HTTP/2 oder HTTP/3 gesendet werden. Deine Backend-Anwendung muss die 103-Antwort erzeugen; NGINX reicht sie durch.

Apache (2.4.58+)

Apache kann 103-Antworten über mod_http2 selbst erzeugen. Aktiviere das Feature 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"

Anders als NGINX erzeugt Apache die 103-Antwort direkt auf Serverebene. Deine Anwendung muss sie also nicht selbst generieren.

Wann Early Hints helfen (und wann nicht)

103 Early Hints bringen am meisten, wenn dein Server spürbar Zeit für die Antwort braucht: bei dynamischen Seiten, die Datenbanken abfragen, APIs aufrufen oder Templates rendern. Je langsamer die Time to First Byte ist, desto mehr Zeit hat der Browser, die Hinweise abzuarbeiten.

Early Hints bringen wenig, wenn:

• Dein Server in unter 100 ms antwortet. Ist die TTFB bereits schnell, gibt es für den Browser keine Wartezeit zu überbrücken. Konzentriere dich stattdessen auf die Ressourcen-Priorisierung in deinem HTML.
• Seiten aus dem Cache kommen. Eine vollständig gecachte HTML-Antwort lädt so schnell, dass die 103-Antwort kaum einen Vorsprung herausholt.
• Du zu viele Ressourcen angibst. Sendest du 10 oder mehr Ressourcen per Hint, lastet das die Verbindung aus und kann den Ladevorgang verlangsamen. Shopify stellte fest, dass aggressives Hinting auf Mobilgeräten zu schlechterer Performance bei TTFB, FCP und LCP führte. Beschränke dich auf 2 bis 4 kritische Ressourcen.

Trotz 93 % Browser-Support bleibt die Verbreitung gering. Laut dem Web Almanac 2025 nutzen nur rund 5 % der Top-Websites 103 Early Hints. Die größte Hürde: Du musst für jede Seite genau wissen, welche Ressourcen du ankündigen willst. Die meisten CMS erledigen das nicht automatisch.

So prüfst du, ob Early Hints funktionieren

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

Über die Kommandozeile kannst du das mit curl prü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 war mit 103 Early Hints 35 % früher auf dem Bildschirm zu sehen als mit einem regulären Preload im HTML.

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

2. Early Hints mit großem Stylesheet und LCP-Bild

Eine zusätzliche 85-KB-CSS-Datei in den Hints machte den Unterschied noch deutlicher: Der FCP verbesserte sich von 1,8 Sekunden auf 1,4 Sekunden und der LCP 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 den Messungen von Cloudflare bei über 100.000 Kunden: eine LCP-Verbesserung von 6 % im 50. Perzentil und 16 % im 75. Perzentil auf dem Desktop. Shopify verzeichnete an Black Friday und Cyber Monday eine LCP-Verbesserung von 500 ms bei p50. Den größten Effekt siehst du auf Seiten mit langsamen Server-Antwortzeiten – genau dann haben Early Hints die meiste Zeit, um zu wirken.

Early Hints und TTFB

Achte auf eine Besonderheit bei der Messung: Seit Chrome 133 bezieht der Browser-Zeitstempel responseStart (den die meisten Tools zur Messung der TTFB nutzen) die 103-Antwort mit ein. Deine gemessene TTFB sinkt nach dem Aktivieren von Early Hints also, obwohl die tatsächliche Verarbeitungszeit deines Servers unverändert bleibt.

Möchtest du die Verarbeitungszeit des Servers separat messen: Chrome 133 hat dafür den Zeitstempel firstResponseHeadersStart eingeführt. Er erfasst, wann die Header der endgültigen 200-Antwort eintreffen. Real User Monitoring-Tools, die beide Werte erfassen, liefern dir das vollständige Bild: wie viel Zeit Early Hints dem Browser erspart haben und wie lange dein Server tatsächlich für die Antwort brauchte.