Hi all,
I’ve just added a new document, Client Hint Reliability, to the Client Hints infrastructure repository. It outlines a solution to the first request problem, as well as the more general problem when the origin’s Client Hint preferences have changed since the last page load.
Please provide feedback either here or on the repo’s issues.
I think that Critical-CH is a reasonable approach and worthwhile prototyping.
The rest of the proposal – dropping Accept-CH down into SETTINGS and/or TLS – is overcomplicated, violates layering, and isn’t worth the benefits it provides (1RTT when all caches are cold).
The feedback we got from site authors on Client Hints was that the RTT cost was crucial. Latency the first time a user visits a site has a lot of impact, so, without a solution the RTT hit, Client Hints are unattractive for top-level resources.
The HTML Priority of Constituencies thus says we should look to solving the RTT issue over layering. But layering is still important to consider. Could you elaborate on the issue? The proposed solution has many pieces, but the aim was to help with layering. ALPS is a generic TLS extension meant to solve H2 and H3’s reliable settings problem overall. That lets us leave Accept-CH in HTTP and using existing building blocks. Would a different shape be preferable? Exactly how to get the data into that round-trip is, ultimately, a protocol engineering/aesthetics issue, so I could imagine other ways to slice it.