HTTP-Critical-CH-Header

Typ

Der Critical-CH-Header ist ein HTTP-Response-Header, mit dem der Server Client Hints als kritisch für die korrekte Ressourcenauslieferung kennzeichnet.

Syntax

Der Header enthält eine durch Komma getrennte Liste von Client Hint-Namen, die als kritisch gelten.

http 
Critical-CH: Sec-CH-Prefers-Color-Scheme
Critical-CH: Sec-CH-Viewport-Width, DPR

Direktiven

Der Critical-CH-Header listet Client Hint-Header auf, die für die Ressourcenauslieferung kritisch sind:

hint-name
Name eines Client Hint-Headers, der als kritisch markiert wird. Der Browser sendet den ursprünglichen Request erneut, wenn dieser Hint nicht enthalten war.
multiple-hints
Mehrere kritische Hints werden durch Komma getrennt. Der Browser muss alle aufgelisteten Hints im wiederholten Request senden.

Beispiele

Kritischer Viewport-Hint für adaptive Bilder

Ein API-Endpunkt für Bildauslieferung markiert die Viewport-Breite als kritisch:

http 
GET /api/v1/images/hero.jpg HTTP/1.1
Host: cdn.example.com
Accept: image/webp,image/*

Der Server antwortet mit Critical-CH und fordert einen Retry an:

http 
HTTP/1.1 200 OK
Accept-CH: Sec-CH-Viewport-Width, DPR
Critical-CH: Sec-CH-Viewport-Width
Vary: Sec-CH-Viewport-Width
Content-Type: image/jpeg

[Standard-Bild als Fallback]

Der Browser sendet den Request mit dem kritischen Hint erneut:

http 
GET /api/v1/images/hero.jpg HTTP/1.1
Host: cdn.example.com
Sec-CH-Viewport-Width: 1920
DPR: 2
Accept: image/webp,image/*

Kritische Color-Scheme-Präferenz für API-Responses

Eine API liefert unterschiedliche Ressourcen basierend auf dem präferierten Farbschema:

http 
GET /api/v1/themes/dashboard.css HTTP/1.1
Host: api.example.com

Der Server markiert das Farbschema als kritisch:

http 
HTTP/1.1 200 OK
Accept-CH: Sec-CH-Prefers-Color-Scheme, Sec-CH-Prefers-Reduced-Motion
Critical-CH: Sec-CH-Prefers-Color-Scheme
Vary: Sec-CH-Prefers-Color-Scheme
Content-Type: text/css

/* Neutrales CSS als Fallback */

Device-Memory für optimierte API-Payloads

Eine API passt die Response-Größe basierend auf verfügbarem Gerätespeicher an:

http 
GET /api/v1/products?category=electronics HTTP/1.1
Host: shop.example.com

Der Server fordert Device-Memory als kritischen Hint:

http 
HTTP/1.1 200 OK
Accept-CH: Device-Memory, Downlink
Critical-CH: Device-Memory
Vary: Device-Memory
Content-Type: application/json

{
  "products": [
    {"id": "1", "name": "Laptop", "preview": true}
  ]
}

Critical-Client-Hints-Flow

Der Ablauf bei Verwendung kritischer Client Hints mit automatischem Browser-Retry.

plantuml 
@startuml
actor Browser
participant "CDN API" as CDN
participant "Origin Server" as Origin

Browser -> CDN: GET /api/v1/resource\n(ohne Client Hints)
CDN -> Origin: Forward request
Origin --> CDN: 200 OK\nCritical-CH: Sec-CH-Viewport-Width\nAccept-CH: Sec-CH-Viewport-Width, DPR
CDN --> Browser: 200 OK\nCritical-CH: Sec-CH-Viewport-Width\n[Fallback-Content]

Browser -> Browser: Detect missing critical hint\nPrepare retry with hints

Browser -> CDN: GET /api/v1/resource\nSec-CH-Viewport-Width: 1920\nDPR: 2
CDN -> Origin: Forward with hints
Origin -> Origin: Generate optimized content\nfor viewport=1920, DPR=2
Origin --> CDN: 200 OK\n[Optimized content]
CDN --> Browser: 200 OK\n[Optimized content]
@enduml

Vorteile für die Systemarchitektur

  • Garantiert korrekte Content-Auslieferung durch automatischen Browser-Retry mit fehlenden Hints
  • Reduziert Bandbreite durch optimierte Ressourcenauslieferung basierend auf Client-Fähigkeiten
  • Verbessert User Experience durch geräteoptimierte API-Responses ohne JavaScript-Overhead
  • Ermöglicht Server-Side-Rendering mit vollständigen Client-Informationen im ersten Request
  • Unterstützt Progressive Enhancement durch Fallback-Content bei fehlendem Hint-Support

Spezifikation

Der Critical-CH-Header ist im Client Hints Infrastructure Draft definiert.

Weitere Spezifikationen

Accept-CH Header, Vary Header