Client Hints für netzwerkbewusstes Laden nutzen

1. Was Client Hints sind und wie sie funktionieren

Client Hints sind eine Gruppe von HTTP-Headern, über die der Browser dem Server proaktiv strukturierte Informationen über das Gerät, die Präferenzen und die Netzwerkbedingungen des Nutzers mitteilt. Im Gegensatz zum klassischen User-Agent-String, der ein einziges, schwer zu parsendes Textfeld mit vielen redundanten Informationen darstellt, liefern Client Hints gezielte, einzeln abrufbare Werte wie die Bildschirmbreite, das bevorzugte Farbschema oder eben die Netzwerkqualität.

Für die Web-Performance sind besonders die sogenannten Network Information Client Hints relevant, zu denen Save-Data, Downlink und ECT (Effective Connection Type) gehören. Diese Header erlauben es einem Server, bereits bei der ersten Anfrage zu erkennen, ob ein Nutzer auf einer langsamen Mobilfunkverbindung unterwegs ist oder explizit um Datensparsamkeit gebeten hat, und die Antwort entsprechend anzupassen, bevor überhaupt ein einziges Byte an Bilddaten übertragen wurde.

2. Opt-in über den Accept-CH-Header

Aus Datenschutzgründen werden die meisten Client Hints nicht automatisch bei jeder Anfrage mitgesendet, sondern müssen vom Server explizit angefordert werden. Das geschieht über den Accept-CH-Header, den der Server in seiner Antwort setzt und der dem Browser mitteilt, welche Client Hints er bei zukünftigen Anfragen an diesen Origin senden soll. Erst nach diesem Opt-in liefert der Browser die angeforderten Header bei nachfolgenden Requests mit.

Diese Zwei-Schritt-Logik bedeutet, dass der allererste Seitenaufruf noch ohne die gewünschten Hints auskommen muss, während alle nachfolgenden Requests innerhalb derselben Origin sie automatisch enthalten. Für Single-Page-Applications oder Seiten mit mehreren nachgeladenen Ressourcen ist das meist unproblematisch, da bereits der zweite Request von der Optimierung profitiert.

# Server-Antwort auf die erste Anfrage: Client Hints anfordern
HTTP/1.1 200 OK
Accept-CH: Save-Data, Downlink, ECT, DPR, Viewport-Width
Critical-CH: Save-Data

# Nachfolgende Anfrage des Browsers enthaelt automatisch:
GET /produkte/kamera-xz200 HTTP/1.1
Save-Data: on
Downlink: 0.7
ECT: 3g
DPR: 2
Viewport-Width: 390

3. Der Save-Data-Hint für explizite Datensparsamkeit

Der Save-Data-Header ist der wichtigste und am einfachsten zu nutzende Client Hint, weil er nicht auf einer Netzwerkmessung basiert, sondern auf einer expliziten Nutzerentscheidung. Aktiviert ein Nutzer in den Betriebssystem- oder Browsereinstellungen den Datensparmodus, sendet der Browser bei jeder Anfrage den Header Save-Data: on mit, unabhängig davon, wie schnell die aktuelle Verbindung tatsächlich ist.

Für den Server bedeutet dieser Hint ein klares Signal: Der Nutzer möchte bewusst weniger Daten übertragen bekommen, etwa weil er ein begrenztes Datenvolumen hat oder in einem Land mit teuren Mobilfunktarifen unterwegs ist. Sinnvolle Reaktionen sind das Ausliefern kleinerer Bildvarianten, das Deaktivieren von Autoplay-Videos oder das Weglassen nicht essenzieller Web-Fonts und Animationen, um die übertragene Datenmenge spürbar zu reduzieren.

4. Downlink und ECT: Netzwerkqualität einschätzen

Während Save-Data eine bewusste Nutzerentscheidung abbildet, liefern Downlink und ECT eine automatische Einschätzung der tatsächlichen Netzwerkqualität. Downlink gibt die geschätzte Bandbreite in Megabit pro Sekunde als Gleitkommazahl an, während ECT (Effective Connection Type) eine grobe Kategorisierung in slow-2g, 2g, 3g oder 4g liefert, basierend auf gemessener Round-Trip-Time und Durchsatz der jüngsten Anfragen.

Diese Werte sind bewusst als Schätzung und nicht als exakte Messung zu verstehen, da sie auf historischen Daten der letzten Anfragen desselben Browsers basieren und sich die tatsächliche Verbindungsqualität jederzeit ändern kann, etwa beim Wechsel von WLAN zu Mobilfunk. Trotzdem liefern sie einen wertvollen groben Anhaltspunkt, der insbesondere für binäre Entscheidungen wie 'einfache oder aufwendige Bildvariante ausliefern' vollkommen ausreicht.

5. Adaptive Auslieferung von Bildqualität und Inhalten

Der praktisch wichtigste Anwendungsfall für Client Hints ist die adaptive Auslieferung von Bildern. Erkennt der Server anhand von Save-Data oder eines niedrigen ECT-Werts eine langsame Verbindung, kann er serverseitig eine stärker komprimierte Bildvariante mit geringerer Auflösung ausliefern, statt die Entscheidung allein dem Client per srcset zu überlassen. Das reduziert die übertragene Datenmenge bereits auf Serverebene, ohne dass zusätzliche clientseitige Logik nötig ist.

Neben Bildern lassen sich auch andere Inhalte anpassen: Videovorschauen können durch statische Thumbnails ersetzt, die Anzahl gleichzeitig geladener Produktempfehlungen reduziert oder aufwendige Web-Font-Varianten durch Systemfonts ersetzt werden. Wichtig ist, diese Anpassungen so zu gestalten, dass sie die grundlegende Funktionalität und Lesbarkeit der Seite niemals beeinträchtigen, sondern ausschliesslich die Datenmenge und Ladezeit optimieren.

6. Praktische Umsetzung im Backend

In der Backend-Logik lassen sich die Client-Hints-Header wie jeder andere HTTP-Header auslesen und in einer zentralen Stelle, etwa einer Middleware oder einem Event-Listener, in ein einfaches Kontextobjekt übersetzen. Dieses Objekt kann dann in Templates oder Bild-Rendering-Diensten abgefragt werden, um zu entscheiden, welche Bildvariante ausgeliefert oder welche Inhalte reduziert werden sollen, ohne dass jede einzelne Stelle im Code die Header selbst parsen muss.

Wichtig ist, den Accept-CH-Header konsistent auf allen Seiten der Anwendung zu setzen, da er sich sonst nicht zuverlässig auf nachfolgende Requests auswirkt. Ausserdem sollte der Vary-Header entsprechend gesetzt werden, damit Caching-Schichten wie CDNs unterschiedliche Antworten für unterschiedliche Client-Hints-Werte korrekt vorhalten, statt versehentlich eine für langsame Verbindungen optimierte Antwort an einen Nutzer mit schneller Verbindung auszuliefern.

7. Clientseitige Alternative: die NetworkInformation-API

Neben den serverseitig ausgewerteten Headern existiert mit der NetworkInformation-API auch ein clientseitiger Zugriff auf dieselben Informationen, erreichbar über navigator.connection. Diese API liefert dieselben Werte wie Downlink, ECT und Save-Data direkt in JavaScript, ohne dass ein Server-Roundtrip nötig ist, was sich gut für clientseitige Entscheidungen eignet, etwa ob ein Video automatisch abgespielt oder eine Bildergalerie vorab geladen werden soll.

Beide Ansätze schließen sich nicht aus, sondern ergänzen sich: Die Header eignen sich für Entscheidungen, die bereits beim ersten Byte der Antwort feststehen müssen, etwa welche Bildvariante ausgeliefert wird, während die JavaScript-API sich für nachträgliche, interaktive Entscheidungen eignet, die erst nach dem initialen Laden der Seite relevant werden.

8. Datenschutzüberlegungen bei Client Hints

Client Hints wurden bewusst so entworfen, dass sie im Vergleich zum User-Agent-String weniger zum Fingerprinting geeignet sind, da sie einzeln angefordert werden müssen und viele der sensibleren Hints, etwa detaillierte Geräteinformationen, nur nach explizitem Opt-in des Servers und teils nur über HTTPS übertragen werden. Die Network Information Hints wie Save-Data, Downlink und ECT gelten dabei als vergleichsweise unkritisch, da sie kaum zur eindeutigen Identifizierung eines einzelnen Nutzers beitragen.

Dennoch sollte bei der Verarbeitung dieser Daten die Datenschutz-Grundverordnung beachtet werden, insbesondere wenn Netzwerkdaten zusammen mit anderen personenbezogenen Daten gespeichert oder ausgewertet werden. Für die reine Anpassung der Auslieferung in Echtzeit, ohne dauerhafte Speicherung der Werte, ergeben sich in der Praxis in der Regel keine zusätzlichen datenschutzrechtlichen Anforderungen über die ohnehin geltenden hinaus.

9. Browser-Support und Grenzen der Methode

Client Hints und insbesondere die Network Information Hints werden derzeit vor allem von Chromium-basierten Browsern wie Chrome und Edge unterstützt, während Safari und Firefox diese Header bislang nicht implementiert haben. Das bedeutet, dass eine auf Client Hints basierende Optimierung für einen erheblichen Teil der Nutzer schlicht keine Wirkung zeigt, was bei der Priorisierung dieser Massnahme berücksichtigt werden sollte.

Aus diesem Grund sollten Client Hints niemals als alleinige Grundlage einer Optimierungsstrategie dienen, sondern stets als zusätzliche, progressive Verbesserung neben grundlegenden Techniken wie responsive Bildern mit srcset und sizes verstanden werden. Für Browser ohne Unterstützung greifen diese grundlegenden Mechanismen weiterhin zuverlässig, während Nutzer unterstützter Browser von der zusätzlichen, feingranularen Anpassung profitieren.

10. Zusammenfassung

11. FAQ: Client Hints