Kort fortalt: Client Hints er HTTP-headere der gør det muligt for browseren at fortælle serveren noget om konteksten (fx device pixel ratio, viewport-bredde, understøttede formater), så serveren kan sende en bedre variant af en ressource – typisk et billede. Det kan give hurtigere sider, men det kan også gøre caching mere kompleks.
Hvad betyder Client Hints?
Når en browser anmoder om en ressource, kan den (hvis du har bedt om det) sende ekstra information som headers. Eksempler på hints du ofte møder i praksis:
- DPR: device pixel ratio (2x på retina osv.)
- Viewport Width (fx til at vælge billedstørrelse)
- Sec-CH-UA-familien: kontrollerede hints om browser/brand/platform
Nogle hints er “opt-in”: browseren sender dem først når serveren har sagt “jeg vil gerne have disse hints” (se Accept-CH).
Hvorfor er det vigtigt?
Billeder: mindre spild, bedre LCP
Hvis du serverer billeder dynamisk (fx via Image CDN), kan hints hjælpe dig med at ramme:
- rigtige pixel-dimensioner (ikke for store)
- rigtige formater (WebP/AVIF hvor det giver mening)
Det kan flytte både downloadtid og oplevet hastighed, især når hero-billedet er LCP-elementet (se LCP og srcset og sizes).
Men: caching kan blive sværere
Når du begynder at variere responses baseret på hints, ender du hurtigt i de klassiske problemer:
- du har flere varianter pr. URL
- cache-nøglen bliver større
- hitrate falder
Det er især relevant hvis du har CDN/edge caching (se Edge caching og Vary).
Eksempel fra praksis (billeder)
Forestil dig at du serverer samme billede-URL til alle:
/img/hero.jpg
Uden hints kan du let komme til at sende for stort billede til små skærme, eller for lille til high-DPR.
Med en image-service kan du i stedet bruge hints til at vælge en variant der passer – men du skal være bevidst om hvor mange varianter du skaber, ellers taber du caching.
Typiske fejl og misforståelser
1) Variér på alt
Hvis du varierer per viewport-pixel, skaber du næsten uendeligt mange varianter. Det er sjældent det værd.
En bedre strategi er at normalisere til få buckets (fx 320/640/960/1280) og kun variere på det der reelt giver værdi.
2) Glemme cache-konsekvensen (Vary)
Når en response afhænger af hints, skal caching-lagene vide det. Ellers risikerer du at servere forkert variant til forkert bruger.
Det er netop derfor Vary findes (se Vary).
3) Bruge hints til “personalisering”
Client Hints er ikke til at personalisere indhold pr. bruger. Det bliver hurtigt en cache-fælde og kan skabe SEO- og canonical-problemer hvis varianter ikke er kontrolleret.
Relaterede begreber og næste skridt
- Accept-CH – hvordan du beder browseren sende hints
- Vary – cache-korrekthed når responses varierer
- Image CDN – typisk hvor hints bruges i praksis
- srcset og sizes – ofte et bedre/renere valg end server-variation for almindelige sites
FAQ
Er Client Hints kun relevant for billeder?
Nej, men billeder er det mest almindelige use-case. Client Hints kan også bruges til at servere varianter af CSS/JS eller indhold, men så bliver cache- og SEO-risikoen typisk større.
Hvorfor kan Client Hints gøre caching dårligere?
Fordi du pludselig har flere varianter af samme URL. Hvis du varierer for bredt (fx per viewport-pixel), falder cache-hit-rate, og du risikerer flere misses og højere TTFB.
Hvad er forskellen på 'Client Hints' og 'UA Client Hints'?
Client Hints er konceptet med hints-headere. UA Client Hints handler specifikt om at erstatte dele af den klassiske User-Agent med mere kontrollerede, privacy-venlige hints (fx `Sec-CH-UA*`).
Eksterne kilder
Kilder til både konceptet og de praktiske headers.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Få edge cache-hit på HTML: undgå cookies, forkert Vary og dårlige cache keys
Mange sites har CDN, men får stadig høj TTFB fordi HTML ikke caches. Lær et praktisk workflow til at få cache-hit på offentlige sider uden at servere forkert indhold.
Sådan fejlsøger du LCP fra start til slut
Følg en praktisk arbejdsgang til at finde årsagen til høj LCP, fra serverrespons og render blocking til billeder, prioritering og netværksrækkefølge.
Brug fetchpriority og preload rigtigt på de vigtigste ressourcer
Få en praktisk guide til hvordan du bruger fetchpriority og preload på billeder, fonts og CSS uden at overstyre browseren forkert.
5 grunde til at din hjemmeside er langsom og hvad du gør ved det
Se de mest almindelige årsager til en langsom hjemmeside, hvordan du spotter dem, og hvilke ændringer der typisk giver mest effekt først.
Range request i praksis: når 206 Partial Content ikke sker (og hvad det koster)
En feltguide til at spotte når browseren forsøger at bruge Range request, men ender med at få hele filer retur (200 i stedet for 206). Lær at se det i DevTools og ret fejl i proxy/CDN/origin.
Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis
Reverse proxy-laget kan være årsagen til høj TTFB, mystiske cache misses og 502/504-fejl. Lær hvad du skal kigge efter i headers og waterfall, og få et praktisk debug-flow.
