Re: [w3ctag/design-reviews] Design Review: Speculation Rules (Prefetch) (Issue #721)

Thank you for taking a look. Responses below (not necessarily in order):

---

> This seems inconsistent. If external rule sets are to be discouraged, why have the HTTP header? If they aren't to be discouraged, why not support linking to them in markup?
> (Several minutes after writing the above, having gotten farther down the explainer document, I found this text which goes into this a bit. Maybe link to this directly so that people who wonder about this inconsistency can click to the rationale?)

It isn't discouraged; it simply isn't supported yet. The rationale is linked from the words "future extensions" in the explainer excerpt originally quoted. I can certainly rephrase that sentence if you think the link could be made more apparent, or it could be otherwise clarified.

---

>  it would be useful to state (maybe not normatively?) that ideally implementations should provide a way for the users to set their prefetch preferences, and user preferences should be treated as higher priority than the page-declared eagerness preference

I agree; the specification says so in two places right now, [here](https://wicg.github.io/nav-speculation/speculation-rules.html#:~:text=considerations%20such%20as-,user%20preferences,-%2C%20device%20conditions%2C%20and) in the context of eagerness:

> "eager"
> The author believes this is very likely to be worthwhile. User agents should usually enact the candidate, subject only to considerations such as **user preferences, device conditions, and resource limits**.

and [here](https://wicg.github.io/nav-speculation/speculation-rules.html#privacy-intent) in the context of privacy:
> While efforts have been made to minimize the privacy impact of prefetching, some users may nonetheless prefer that prefetching not occur, even though this may make loading slower. User agents are encouraged to provide a **setting to disable prefetching features** to accommodate such users.

I've [added additional normative text](https://github.com/WICG/nav-speculation/pull/269) to be more explicit.

---

> If you could propose a simpler approach that could cover say, 80% of the use cases as an alternative - we would love to see this. One example that came up in our discussion was an attribute on <a> elements instead of an entirely separate technology. After all, more complex approaches can always be added later, if the need arises.

Would such a feature be useful for some authors? I do agree it might be, if only because it's very easy to explain. I think it would be quite straightforward to add as a "shorthand".

I'm less confident that it is sufficient to address 80% of use cases well, though, for a few reasons.

Firstly, while adopting such a feature for a single link would be very easy, updating many code paths which emit <a> tags, or existing static content which includes <a> tags, would be extremely tedious for many authors, both large and small. While this can to some extent be done dynamically with script, this is significant work (and there are some non-obvious edge cases), and browsers already have much of the infrastructure to do this matching efficiently. Similarly (though more extremely), an author library which replaced CSS rules and cascade with explicit assignment of styles to individual elements would be possible but tricky to get right and harder yet to make perform well.

Secondly, I expect that many authors would find this technology easier to adopt with support from a service provider or product, such as a CDN, hosted CMS, or application proxy. They are well-positioned to reason about the side effects that requests to particular URLs may have, but not necessarily in a position to modify documents, especially their dynamic content.

For example, a hosted CMS might know that particular URLs simply fetch a blog post or product detail page without side effects. A CDN might be configured to allow prefetching only cached HTML resources, so any same-origin link can be prefetched safely (since both hitting the cache and rejecting the request cannot have side effects on the origin server). These providers can then provide a turnkey solution to their customers, in a way that would be much more difficult if they had to modify each link in the DOM.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/721#issuecomment-1520658230
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/721/1520658230@github.com>