Welchen Vorteil bietet die Nutzung von HTTP/2 Server Push im Vergleich zu `<link rel='preload'>`?

Der theoretische Vorteil von HTTP/2 Server Push liegt in der Reduzierung der Round-Trip-Time (RTT). Während bei <link rel="preload"> der Browser das HTML-Dokument empfangen, analysieren und erst daraufhin eine separate Anfrage für die Ressource stellen muss, sendet der Server bei HTTP/2 Push die Assets (z. B. CSS oder JavaScript) proaktiv mit der Antwort des HTML-Dokuments mit. Die Ressourcen befinden sich somit bereits im lokalen Cache des Browsers, wenn der Parser sie im Dokument referenziert.

In der praktischen Anwendung führt dieser Ansatz jedoch zu Problemen bei der Cache-Steuerung. Ein Server, der Ressourcen pusht, hat standardmäßig keine Kenntnis darüber, ob der Client die Datei bereits im Cache gespeichert hat. Dies führt häufig zu redundanten Datenübertragungen und einer unnötigen Belastung der Bandbreite. Im Gegensatz dazu prüft der Browser bei einem Preload-Tag zuerst seinen internen Cache, bevor er eine Netzwerkanfrage auslöst.

Die technischen Unterschiede lassen sich in der folgenden Tabelle zusammenfassen:

Besonders bei hochperformanten E-Commerce Plattformen ist die Optimierung des Critical Rendering Path entscheidend. Server Push versprach hier eine Beschleunigung, scheiterte jedoch an der Komplexität der Implementierung und der mangelnden Unterstützung durch moderne Browser-Engines.

Wir empfehlen daher den Verzicht auf HTTP/2 Server Push. Die Nutzung von <link rel="preload"> bietet eine stabilere und cache-effizientere Lösung. Für maximale Performance-Gewinne setzen wir stattdessen auf den Standard "103 Early Hints". Dieser kombiniert die Vorteile beider Ansätze, indem der Server dem Browser bereits während der Generierung der HTML-Antwort mitteilt, welche Ressourcen geladen werden müssen, ohne den Cache-Mechanismus des Clients zu ignorieren.