103 Early Hints: schneller – oder nur früher falsch?

Sie aktivieren beim CDN Early Hints. Im Netzwerk erscheint nun eine 103 Early Hints-Antwort vor der eigentlichen 200 OK. Der Browser kann CSS, Fonts oder Verbindungen starten, während der Server noch HTML erzeugt. Klingt nach kostenlosem Performance-Gewinn.

Genau dafür existiert 103. Aber früher laden ist nur dann schneller, wenn der Browser früh das Richtige lädt. Ein falscher Preload konkurriert mit wirklich wichtigen Ressourcen, ein veralteter Asset-Hash erzeugt einen Fehlrequest und ein nicht wiederverwendbarer Preload kann sogar doppelt übertragen werden.

Die bessere Audit-Frage lautet deshalb: Sind unsere Early Hints stabil, cachebar, wirklich kritisch und mit der finalen Antwort konsistent?

Was 103 tatsächlich macht

RFC 8297 definiert 103 Early Hints als vorläufige Informationsantwort. Sie kann Link-Header enthalten, bevor der finale Status und die vollständigen Response-Header feststehen. Ein Browser kann diese Hinweise spekulativ für preload oder preconnect nutzen. Die finale Antwort bleibt jedoch maßgeblich.

Der Mechanismus ist besonders interessant, wenn der Server echte Wartezeit hat: SSR wartet auf Daten, ein CMS oder eine API antwortet langsam, ein CDN muss zum Origin oder Routing benötigt Berechnung. Chrome weist ausdrücklich darauf hin, dass Early Hints wenig bringen, wenn der finale Response ohnehin sofort verfügbar ist. Dann reichen normale Resource Hints im finalen Header oder HTML.

Mythos: Jeder Preload macht schneller

Der HTML-Standard beschreibt preload als vorzeitiges Abrufen und Cachen einer Ressource für die aktuelle Navigation. Das ist kein unverbindlicher Hinweis ohne Kosten.

Problematisch wird es etwa, wenn:

• ein Bundle geladen wird, das die Route gar nicht braucht,
• ein Font wegen falschem crossorigin später erneut angefordert wird,
• ein Hero-Bild vorgeladen wird, obwohl mobil eine andere responsive Variante gewählt wird,
• zu viele Ressourcen mit hoher Priorität um dieselbe Bandbreite konkurrieren,
• der Hint noch auf ein Asset aus dem vorherigen Deployment zeigt.

Preload ist daher ein Budget, kein Dekorationstag.

Red Flag 1: 103 und Deployment sind nicht synchron

Moderne Frontends verwenden häufig fingerprinted Assets wie app.8af31.js. Early Hints führt eine zusätzliche Cache- und Timing-Schicht ein. RFC 8297 beschreibt ausdrücklich, dass ein Caching-Intermediär eine 103-Antwort aus einem älteren Cachezustand erzeugen kann, während die finale Antwort bereits andere Header enthält.

Prüfen Sie nach Releases:

1. Verweist 103 auf dieselben kritischen Versionen wie die finale Seite?
2. Werden alte Hash-Dateien noch angefordert?
3. Bleiben alte Assets lange genug verfügbar, damit ein kurzzeitig veralteter Hint nicht in 404 endet?
4. Wie schnell aktualisiert sich die Hint-Schicht des CDN?

Wenn alte Assets sofort gelöscht werden, während Edge-Hints noch auf sie zeigen, wird aus einer Optimierung zusätzliche Netzwerkarbeit.

Red Flag 2: Der Preload kann nicht wiederverwendet werden

Ein Preload lohnt sich nur, wenn der spätere echte Request dieselbe Ressource unter kompatiblen Bedingungen wiederverwenden kann.

Bei Fonts ist crossorigin ein klassischer Stolperstein. MDN weist darauf hin, dass Font-Preloads den passenden CORS-Modus benötigen, auch bei gleicher Origin.

Prüfen Sie außerdem:

• korrektes as,
• identische URL und relevante Parameter,
• kompatible Credentials- und CORS-Modi,
• keine unnötigen Redirects,
• Cache-Header, die Wiederverwendung erlauben.

Entscheidend ist nicht, ob ein Preload-Tag existiert. Entscheidend ist, ob im Waterfall kein zweiter Download entsteht.

Red Flag 3: Nicht cachebare Ressourcen werden früh geladen

Chrome dokumentiert eine wichtige Einschränkung: Early-Hints-Preloads werden in den HTTP-Cache gelegt und später von der Seite wiederverwendet. Ist eine Ressource nicht cachebar, kann sie doppelt geladen werden – einmal durch 103 und später noch einmal durch das Dokument.

Deshalb gehört Cachebarkeit in die Auswahl jedes Early-Hints-Kandidaten. Ein früher Request, der später wiederholt werden muss, ist kein Gewinn.

Red Flag 4: Authentifizierte Seiten senden Hint-Metadaten vor der Entscheidung

Cloudflare dokumentiert aktuell, dass Early Hints aus einer gecachten Schicht vor dem Origin-Response gesendet werden können. Ein nicht angemeldeter Besucher kann daher unter Umständen eine 103-Antwort erhalten, bevor der Origin anschließend 403 Forbidden liefert.

Das bedeutet nicht, dass 103 geschützte Inhalte automatisch offenlegt. Es bedeutet aber: URLs in Early Hints sollten nicht als vertrauliche Metadaten behandelt werden.

Vermeiden Sie dort benutzerspezifische Export-URLs, Dokument-IDs, interne Hostnamen, mandantenbezogene Pfade oder signierte URLs. Und jede geschützte Subressource braucht ihre eigene Autorisierung.

Cloudflare weist außerdem darauf hin, dass sein Early-Hints-Cache nach Request-URI arbeitet und Query-Strings ignoriert. Wenn kritische Ressourcen von Query-Parametern abhängen, muss dieses provider-spezifische Verhalten bewusst getestet werden.

Red Flag 5: TTFB wird besser, aber die Seite nicht

Early Hints verändert Messwerte. MDN weist darauf hin, dass TTFB bei 103 typischerweise das erste Byte der vorläufigen Antwort misst. Ein Dashboard kann also einen deutlich besseren TTFB zeigen, obwohl der finale HTML-Response genauso spät beginnt wie vorher.

Wo unterstützt, kann finalResponseHeadersStart helfen, den Beginn der finalen Antwort separat zu betrachten. Zusätzlich sollten Sie LCP, FCP, Resource-Waterfall, doppelte Requests, übertragene Bytes und Cache-Hits vergleichen.

Eine grünere Zahl ist kein Performance-Beweis.

Red Flag 6: HTTP/1.1 wird wie HTTP/2 behandelt

RFC 8297 warnt vor HTTP/1.1-Clients, die Informationsantworten falsch behandeln. MDN empfiehlt 103 aus Kompatibilitäts- und Sicherheitsgründen primär über HTTP/2 oder neuer. Cloudflare unterstützt Early Hints aktuell über HTTP/2 und HTTP/3.

Ein Audit sollte deshalb den realen Pfad betrachten: Browser, CDN, Reverse Proxy, Origin, Protokollversion und ältere Clients.

Ein pragmatischer Early-Hints-Audit

Beantworten Sie zehn Fragen:

1. Gibt es genug Server-Wartezeit, damit 103 überhaupt Vorsprung erzeugt?
2. Welche Ressource startet tatsächlich früher?
3. Wird sie auf fast jeder betroffenen Navigation gebraucht?
4. Ist sie cachebar?
5. Stimmen as, CORS und Credentials-Modus?
6. Wird irgendetwas doppelt geladen?
7. Können Hints nach Deployments auf alte Asset-Hashes zeigen?
8. Enthalten sie Informationen, die vor Authentifizierung nicht öffentlich sein sollten?
9. Funktioniert der reale Delivery-Pfad zuverlässig über die eingesetzten HTTP-Versionen?
10. Verbessert sich LCP oder die wahrgenommene Ladezeit – oder nur TTFB?

Was Website-Pflichtencheck dabei prüft

Website-Pflichtencheck kann 103 Early Hints als Teil der gesamten Auslieferungskette prüfen:

• tatsächliche 103- und finale Responses,
• Link-Header und Preload-Ziele,
• Priorisierung kritischer Ressourcen,
• CORS- und as-Konsistenz,
• Cachebarkeit und Double-Fetches,
• stale Asset-Hashes nach Deployments,
• CDN- und Reverse-Proxy-Verhalten,
• öffentliche versus authentifizierte Routen,
• HTTP/2- und HTTP/3-Auslieferung,
• TTFB gegenüber finalem Response-Start,
• LCP und echte Resource-Waterfalls.

Das Ziel ist nicht, möglichst viele Performance-Features zu aktivieren. Das Ziel ist, dass jede Optimierung nachweisbar einen Engpass verkürzt, ohne einen neuen zu erzeugen.

103 Early Hints ist ein gutes Werkzeug, wenn der Server warten muss und der Browser diese Zeit sinnvoll nutzen kann. Wenn die Hint-Liste dagegen veraltet oder überladen ist, laden Sie Fehler nur früher.

Schneller ist nicht, wer zuerst irgendeinen Request startet. Schneller ist, wer den richtigen Request früh genug startet und ihn danach nicht noch einmal braucht.