Kort fortalt: Accept-CH er en response-header der siger: “Jeg (serveren) vil gerne have at du (browseren) sender de her Client Hints næste gang.” Det bruges typisk for at gøre billedservering smartere – men det er også et caching-problem forklædt som en performance-feature.
Hvad betyder Accept-CH?
Client Hints (se Client Hints) er ekstra headers som browseren kan sende, fx DPR eller viewport-bredde. Mange af dem er opt-in, fordi de kan øge fingerprinting-overfladen og fordi de påvirker caching.
Når du svarer med:
Accept-CH: ...
…fortæller du browseren hvilke hints du ønsker på fremtidige requests til samme origin (eller scope, afhængigt af policy).
Hvorfor er det vigtigt?
Bedre variantvalg (især billeder)
Med Accept-CH kan du få serveren til at vælge:
- en passende billedstørrelse
- et passende format
Det kan spare bytes og reducere decode-work. Især hvis billedet er LCP-elementet, kan det flytte LCP – men kun hvis resten af kæden er sund (TTFB, caching, render-blocking).
Cache-korrekthed (Vary)
Hvis dit svar afhænger af hints, skal caches vide det. Ellers kan en variant til én klient blive serveret til en anden.
Det er her du typisk skal forstå:
- Vary
- cache keys (CDN)
- normalisering/bucketing af varianter
Typisk flow i praksis
- Første request kommer uden hints (browser ved ikke at den må sende dem).
- Server svarer med
Accept-CH. - Browseren kan herefter sende hints på senere requests, og serveren kan returnere bedre varianter.
Det betyder også: Accept-CH er sjældent “magic” for første load. Det er ofte en gentagne-besøg forbedring, eller noget der hjælper i brugerflows efter første side.
Typiske fejl
1) For mange hints
Hver ekstra dimension kan skabe flere varianter. Hvis du kombinerer mange hints, falder cache-hit-rate.
2) Ingen normalisering
Hvis du serverer forskellige varianter for hver mulig viewport-bredde, mister du caching. En bedre strategi er at mappe til få buckets.
3) Forveksle med srcset/sizes
Hvis du har kontrol over markup, er srcset/sizes ofte bedre, fordi caching bliver enkel og browseren vælger lokalt. Accept-CH er mest relevant når serveren skal træffe valg (fx billedproxy).
Relaterede begreber og næste skridt
- Client Hints – selve konceptet og konsekvenserne
- srcset og sizes – den cache-venlige standardløsning
- Vary – undgå at servere forkert variant
- Cache-Control – sæt caching-politik for dine varianter
FAQ
Sender browseren hints på den første request?
Typisk nej – Accept-CH fungerer som et opt-in. Browseren lærer først at den må sende hints efter at have set headeren, og sender dem på efterfølgende requests (eller når den har gemt politikken).
Skal jeg altid bruge Accept-CH for responsive billeder?
Nej. For mange sites er `srcset`/`sizes` den enkleste og mest cache-venlige løsning. Accept-CH er mest interessant når du serverer billeder dynamisk fra origin eller image service baseret på klientens kontekst.
Hvilken klassisk fejl ser du med Accept-CH?
At man aktiverer mange hints uden at normalisere varianter. Det giver lav cache-hit-rate og kan i værste fald gøre TTFB og LCP dårligere.
Eksterne kilder
Accept-CH er beskrevet som del af HTTP Client Hints.
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.
