-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide an opt-in for the very-first-view #16
Comments
This addresses issue WICG#16.
After chatting with folks who are more knowledgeable than me, here are some brainstorms/paraphrases: It would be technically possible to stuff some extra data in DNS records like https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-03. There are issues with that though. Resolvers/intermediaries may mess with results unless you are using DoH. I think it requires extra dns requests to look up the extra records. And I don't know what the politics are about adding more DNS records - maybe a performance issue? especially if that is true & this needs to be done before the first request comes from the user agent. DoH also is per DNS provider support, so this wouldn't be universal for all requests to a site. There are also pre-load lists, like for hsts, but that seems like a bad option. |
This is the client hint reliability problem. We have a description of a solution here and can probably just close this issue. DNS was considered, but it wouldn't really work: |
Let's close here. We think we've solved this with the CH Reliability ideas. New issues on that topic can be filed @ https://github.com/WICG/client-hints-infrastructure |
The current mechanism doesn't enable providing an opt-in to client hints before the navigation request to the very-first-view of a certain origin is triggered.
For hints that are critical for the generation of that navigation response, that may mean that the site would either forfeit the hints, redirect the browser in order to receive the hint, or will perform content adaptation on the client side. Neither of those is ideal.
We should provide a mechanism that enables very-first-view adaptation without the performance tradeoff.
The text was updated successfully, but these errors were encountered: