Contact emails
Spec
Summary
Client-Hints is a standard destined to improve content negotiation between the browser and the server, and enable the browser to advertise various characteristics to the server along with resource requests, so that the server can adapt its responses to these characteristics in a cache friendly way.
Motivation
In some scenarios, markup-based responsive images solutions come with their own costs: the requirement to modify and update all existing pages may be extremely expensive for legacy web sites, and some developers may prefer to keep image optimization outside of markup and handle it in lower layers or through RESTful means, via content-negotiation. Client-Hints can provide that.
There's already an
existing partial implementation of an older version of the spec (which covers DPR only). I plan to overhaul that implementation and move it from being mostly on the chrome side to the Blink side. That would make the dynamic aspects of the spec (the RW hint) significantly easier to implement.
Compatibility Risk
Low. The solution is based on HTTP negotiation, allowing servers to opt-in to the signals they want to receive from the client, and client is in full control on deciding which signals it wants to send for each request.
As a result, servers cannot rely on a specific hint being sent from the client, so non-supporting browsers won't experience compatibility issues. Also - there's very little to no overhead for sites that don't choose to use CH.
Signals from other browser vendors
Firefox:
Positive &
negative signals. I believe the positive outweighs the negative.
Safari: No public signals.
Ongoing technical constraints
None.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
OWP launch tracking bug?
Link to entry on the feature dashboard
Requesting approval to ship?
Not just yet.