Accept-CH Lifecycle Management: Requesting and Persisting Client Hints at CDN Edges

Back in early 2020, we rolled out Accept-CH for image optimization across a major retail CDN and watched our logs light up with zero hints for the first two requests of every new session. We’d assumed one response header would do the job. It didn’t. The browser’s persistence model, the edge’s cache behavior, and the spec’s own privacy restrictions conspired to drop those hints right where we needed them most.

Why Accept-CH Alone Doesn't Guarantee Hints on the Next Request

There's a common misconception I've seen in at least a dozen CDN migrations: you set Accept-CH on your origin or edge, and the browser will dutifully send you Sec-CH-UA, Viewport-Width, and the rest on every subsequent request. That's not how the lifecycle works. The spec defines Accept-CH as a request for persistence, not a command. The browser decides whether to honor it, how long to remember it, and whether to attach it to the next navigation. And since 2023, with Client Hints Reliability improvements and the shift to Permissions-Policy delegation, the rules have gotten stricter.

For a hint to persist, three conditions have to line up. First, the response must be delivered over a secure context (HTTPS). Second, the origin must be authorized to receive that hint via Permissions-Policy - especially critical for third-party or CDN-hosted subresources where the top-level frame controls delegation. Third, the browser must store the hint-to-origin mapping in its own client-side cache. That cache is origin-scoped and in most Chromium-based browsers, it expires when the browsing session ends or when the user clears site data. It’s not a cookie, it isn’t sent to other origins, and you can’t inspect it from JavaScript. I've debugged cases where our edge was correctly emitting Accept-CH, but because we served the HTML from www.example.com and the images from cdn.example.com, the hints never arrived on the CDN host without an explicit delegate.

This is where Critical-CH changes the dynamic, but at a cost. If you need a hint on the very first meaningful request after opt-in, you can use Critical-CH to tell the browser: restart the request with these hints if you didn't already include them. It prevents that extra round-trip we all hate, but it does trigger a retry. On high-latency mobile networks, that retry can add 80-150ms. You’ll want to be selective - use it for layout-critical hints like Sec-CH-UA-Mobile or Viewport-Width, not for nice-to-haves like Device-Memory. Understanding this flow is essential when you're tuning how critical bytes get delivered, much like the trade-offs we make with HTTP/2 Stream Prioritization at CDN Edges: Delivering Critical Resources First.

HTTP/1.1 200 OK
Date: Thu, 15 Jun 2024 14:22:31 GMT
Content-Type: text/html; charset=utf-8
Accept-CH: Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Downlink, Viewport-Width, Device-Memory
Critical-CH: Sec-CH-UA-Mobile, Viewport-Width
Permissions-Policy: ch-ua=(self), ch-ua-mobile=(self "https://cdn.example.com"), viewport-width=(self "https://cdn.example.com"), device-memory=(self)
Vary: Sec-CH-UA-Mobile, Viewport-Width, Downlink
Cache-Control: public, max-age=86400
Strict-Transport-Security: max-age=31536000; includeSubDomains

Configuring Edge Persistence: Cache Keys, Vary, and Session Stickiness

At the edge, your job isn't just to forward Accept-CH - it's to make the resulting Vary behavior survivable. I’ve seen teams add five high-entropy hints to Accept-CH and then wonder why their cache hit ratio cratered from 96% to 61% overnight. Every value you add to Vary fragments your cache. If you Vary: Sec-CH-UA-Platform, Viewport-Width, Downlink naively, you’re creating dozens of cache variants for the same logical object. The trick we’ve used for years is to normalize and bucket at the edge before you build the cache key.

Instead of keying on raw Viewport-Width: 412, bucket it into breakpoints - say, 320, 480, 768, 1024, 1440. Instead of keying on the full Sec-CH-UA string with minor version churn, extract just the brand and major version. You can do this in VCL, Lua, or a Cloudflare Worker, but the principle is the same: request the granular hint, but cache on the coarse interpretation. You also need to decide where Accept-CH is injected. If your origin emits it, your CDN must be configured to cache and re-emit it, not strip it. If your edge emits it directly (which I now prefer for control), ensure your origin doesn't strip Vary downstream. And don't forget that Accept-CH persistence is per-origin - if you terminate TLS at the CDN and fetch over a separate origin connection, the client never sees the origin's Accept-CH unless the edge reproduces it to the client.

Session stickiness is another trap. Client Hints aren't sent on the very first visit, period. That means your edge logic must have a sane fallback for that cold start. We typically implement a two-tier strategy: serve a generic, highly-cacheable variant on anonymous/hint-less requests, and only serve the hint-optimized variant once the hint is present. This pairs closely with how you manage underlying transport state. If you're also dealing with protocol migration, the persistence model gets even more nuanced, as covered in HTTP/3 Connection Migration: Seamless Handoffs Across Network Changes, and the same logic around window sizing and backpressure applies when you’re buffering those retries - see HTTP/2 Flow Control Tuning for CDN: Window Sizes and Stream Management. According to the HTTP Working Group Specifications and practical guidance on web.dev Articles, you shouldn’t rely on hints for security decisions, only for optimization.

// Fastly VCL - Normalize Client Hints before cache lookup
sub vcl_recv {
  // Request hints from client on first HTML response
  // (Actual Accept-CH is set in vcl_deliver for HTML only)

  if (req.http.Sec-CH-UA-Mobile) {
    // Normalize to 0 or 1 for cache key
    set req.http.X-CH-Mobile-Normalized = req.http.Sec-CH-UA-Mobile;
  } else {
    set req.http.X-CH-Mobile-Normalized = "unknown";
  }

  if (req.http.Viewport-Width) {
    // Bucket width to avoid cache explosion
    if (std.atoi(req.http.Viewport-Width) < 480) { set req.http.X-Viewport-Bucket = "320"; }
    elsif (std.atoi(req.http.Viewport-Width) < 768) { set req.http.X-Viewport-Bucket = "480"; }
    elsif (std.atoi(req.http.Viewport-Width) < 1024) { set req.http.X-Viewport-Bucket = "768"; }
    else { set req.http.X-Viewport-Bucket = "1024"; }
  } else {
    set req.http.X-Viewport-Bucket = "fallback";
  }
}

sub vcl_hash {
  hash_data(req.http.X-Viewport-Bucket);
  hash_data(req.http.X-CH-Mobile-Normalized);
  return(hash);
}

sub vcl_deliver {
  if (resp.http.Content-Type ~ "text/html") {
    set resp.http.Accept-CH = "Sec-CH-UA-Mobile, Viewport-Width, Downlink, Device-Memory";
    set resp.http.Critical-CH = "Sec-CH-UA-Mobile, Viewport-Width";
    set resp.http.Permissions-Policy = "ch-ua-mobile=(self), viewport-width=(self)";
    set resp.http.Vary = "Sec-CH-UA-Mobile, Viewport-Width";
  }
}

Measuring Persistence Effectiveness and Failure Modes at Scale

You can't manage what you don't measure, and hint persistence is notoriously hard to observe from server logs alone. We instrument our edges to log three states for every request: hint-requested (we sent Accept-CH), hint-received (client sent hint), and hint-used (we actually varied the response). Without that, you're flying blind. On a recent global rollout for a media customer serving 12B requests/day, we found only 68% of eligible Chrome clients returned hints on their second navigation, even though we were sending Accept-CH on every HTML response. The culprit was a combination of Permissions-Policy delegation missing on their image domain and an intermediate cache that was stripping the header.

Failure modes fall into a few buckets you'll recognize quickly once you've stared at enough waterfall charts. First, cache poisoning from misconfigured Vary - we once cached an HTML response with Vary: Sec-CH-UA and served desktop markup to mobile crawlers for six hours. Second, hints that vanish on cross-origin redirects. If your flow is example.com -> cdn.example.net with a 302, the persisted hints for example.com don't follow. Third, privacy-driven truncation: browsers will deliberately withhold high-entropy hints like Sec-CH-UA-Full-Version-List unless you've explicitly requested them and the user hasn't opted into reduced hints. I always tell teams to treat the first request as hint-less by design and verify persistence by looking at the second same-origin navigation, not an immediate subresource load.

Implementing Accept-CH Persistence at the Edge: A Production-Ready Recipe

We've seen why the browser won't magically remember your Accept-CH request — now let's make it stick. In production, you can't rely on origin to set the header on every response, especially when 70-80% of your traffic never hits origin. You need to enforce the lifecycle entirely at the edge, and you need to do it without exploding your cache hit ratio.

The trick most teams get wrong is blindly adding Vary: Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-DPR to everything. That'll fragment your cache by up to 40x if you're not careful, and we've seen hit ratios drop from 96% to 62% overnight from that mistake alone. Instead, you want to Vary only where the hint actually changes the response — typically your HTML shell, your image optimization worker, and your client-side JS bundle. For static assets like CSS or fonts where DPR doesn't matter, don't Vary at all.

The pattern that works reliably at scale is to have the edge issue Accept-CH on the first navigation request and cache that decision for the session. We use a short-lived edge dictionary or cookie to avoid re-sending the header on every response, plus Critical-CH if you need a hint to trigger a restart on the very first load. Here's a simplified Cloudflare Workers / Fastly VCL-style approach we run on about 12M req/s:

// Edge Worker - enforce Accept-CH lifecycle without cache busting
const HINTS = "Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-DPR, Sec-CH-Width";
const VARY_HINTS = "Sec-CH-DPR, Sec-CH-Width";

export default {
  async fetch(req, origin) {
    let res = await origin.fetch(req);
    
    // Only persist for document navigations over HTTPS
    const isDocument = req.headers.get("Sec-Fetch-Dest") === "document";
    const isSecure = new URL(req.url).protocol === "https:";
    
    if (isDocument && isSecure) {
      // 1. Request persistence for lifetime of browser session
      res.headers.set("Accept-CH", HINTS);
      res.headers.set("Permissions-Policy", `ch-ua=*, ch-dpr=(self "https://img.example.com")`);
      // 2. Use Critical-CH only if you need to force a reload for layout-critical hints
      // res.headers.set("Critical-CH", "Sec-CH-DPR");
      
      // 3. Persist Vary correctly - don't Vary on the full UA set
      res.headers.append("Vary", VARY_HINTS);
      
      // 4. Cache-key isolation: only key on DPR/Width for image routes
      res.headers.set("Cache-Tag", "accept-ch-v1");
    }
    
    // Strip Accept-CH from cacheable 304s to avoid double counting
    if (res.status === 304) {
      res.headers.delete("Accept-CH");
    }
    return res;
  }
}

Advanced Patterns: Delegation, Critical-CH, and Why Your Hints Still Disappear

Once the basics are live, you'll hit the edge cases that kill persistence in the wild. The biggest one we see: third-party contexts. Client Hints are not delegated by default. If your CDN serves images from img.example.com while your HTML is on www.example.com, the browser will not send Sec-CH-DPR to the image subdomain even after you set Accept-CH on the document. You have to explicitly delegate via Permissions-Policy as shown above. Without that, you'll see 0% hint attachment on your image edge and wonder why your HTTP Trailers for CDN: Post-Body Checksums, Timing, and Logging show no DPR data downstream.

Another failure mode is the Critical-CH restart loop. Critical-CH tells the browser "retry this request if you didn't send these hints," which is great for avoiding layout shifts — but if you set it too broadly (e.g., on Sec-CH-UA-Full-Version), you'll force a full connection restart on 15-20% of navigations, adding 80-150ms of TTFB on HTTP/3. We reserve Critical-CH strictly for viewport-critical images and never for low-entropy hints. For everything else, it's better to accept that the first page view will be hint-less and the second will be correct. That aligns well with how we handle Advanced HTTP Conditional Requests: If-Match, If-Range, and Partial Updates — you optimize for the common revalidation path, not the cold start.

When you're troubleshooting, stop looking at origin logs first. Check three places in order: 1) Was the initial Accept-CH served over HTTPS with a valid cert? Browsers silently drop it on HTTP. 2) Is your edge cache serving a stale Accept-CH-less response? Purge and check Age vs. Accept-CH presence — we've seen a 48-hour TTL cache poison hint deployment for days. 3) Are you in an iframe or privacy sandbox? Safari and Firefox currently cap or block high-entropy hints entirely. For long-lived bidirectional use cases where you need continuous capability negotiation rather than per-request hints, consider moving that logic out of Client Hints entirely into WebTransport Through CDN Proxies: Bidirectional Streams Over HTTP/3, which gives you explicit client-driven feature signaling without the persistence headache.

Frequently Asked Questions