How to Opt-In and Delegate Client-Hints

This is a moving target! I’ve been covering the topic before both in Client Hints in general and for User-Agent Client Hints.

The architecture is pretty complicated when you first experience it, but it makes sense: First, the website must opt in to the hints it needs, then the browser sends them to the server on the next request. However, if you need to send the hints to a different domain (origin) than the domain of your website, you’ll have to explicitly delegate the hints to that domain/origin.

This has been possible for a while (since Chrome 84) using Permission-Policy headers. However, HTTP headers is not very convenient if you’re a front end dev.

So, since Chrome v100, it is now possible (after some changes to the syntax) to both opt-in for Client Hints and delegate in one single <meta> tag:

<meta http-equiv="delegate-ch" content="sec-ch-dpr;">

As you can imagine, this meta tag gan grow very ugly if you need a lot of hints distributed to all your origins.

I’ve made a glitch demoing the meta tag for opting in , and delegating to a third party.

A <meta> tag to enable user-agent client hints for will for example look like this:

<meta http-equiv="delegate-ch" content="sec-ch-dpr; sec-ch-ua-bitness; sec-ch-ua-arch; sec-ch-ua-model; sec-ch-ua-platform; sec-ch-ua-platform-version; sec-ch-ua-full-version; sec-ch-ua-full-version-list ">

One difference from the HTTP-header approach is the sec- prefix. With the HTTP header the sec- prefix is not needed, but with the <meta> tag it is required.

Aside from UA-CH, users of Image CDNs may find hints like width, height, viewport-width and dpr more interesting. Here’s a little demo of that too, using the <meta> tag approach.

(The image is a 404, but look at its request headers in the developer tools)

Comments are closed.