Intent to Experiment: Speculation Rules - Document rules, response header, deliveryType

266 views
Skip to first unread message

Jeremy Roman

unread,
Dec 16, 2022, 1:54:36 PM12/16/22
to blink-dev

Contact emails

jbr...@chromium.org, adit...@chromium.org, isab...@google.com, dom...@chromium.org, kenji...@chromium.org


Explainer

https://github.com/WICG/nav-speculation/blob/main/triggers.md

https://github.com/w3c/resource-timing/issues/332


Specification

https://wicg.github.io/nav-speculation/speculation-rules.html

https://github.com/w3c/resource-timing/pull/343

https://github.com/WICG/nav-speculation/pull/180


Summary


Three enhancements to preloading, under a combined experiment:


An extension to speculation rules syntax that lets the browser obtain URLs for speculation from link elements in a page. They may include criteria which restrict which of these links can be used.


Currently developers can only specify speculation rules using inline script tags.  The proposed feature provides an alternative through the "Speculation-Rules" header. Its value must be a URL to a text resource with "application/speculationrules+json" MIME type. The resource's rules will be added to the document's rule set.


Expose information about how a resource was delivered. For example, resources which were delivered from the cache (currently exposed through transferSize) and navigations which were prefetched by the previous page are useful to identify.


An overview of this experiment is drafted (once reviewed, this will be merged into WICG/nav-speculation):

https://github.com/jeremyroman/nav-speculation/blob/experiment-summary/chrome-2023q1-experiment-overview.md

Of particular note is that due to the oddity of needing to enable the origin trial for a potentially third-party origin serving speculation rules, this trial will be enabled for third-party use and with a bit of special logic allowing the OT token to be supplied in the document response headers, providing its origin matches the origin of the external speculation rules.


Blink component

Internals>Preload


TAG review

https://github.com/w3ctag/design-reviews/issues/721


TAG review status

Pending


Risks



Interoperability and Compatibility

Because authors cannot rely on speculation rules being evaluated (or preloading generally), applications which use them should function correctly in other browsers and should continue to function correctly were the feature to be deprecated. Of course, ideally other browsers do find it compelling to implement this feature.



Gecko: No signal (https://github.com/mozilla/standards-positions/issues/620)


WebKit: No signal (https://github.com/WebKit/standards-positions/issues/54)


Web developers: We built these enhancements specifically upon requests from partners that found the current speculation rules too hard to integrate into their sites, and have at least one partner lined up to participate in the origin trial.


Other signals:


Activation

Some developers might not be immediately aware of which URLs they can preload without side effects. This risk is reduced if they primarily use the feature for same-origin URL patterns they are familiar with.



Security

See https://wicg.github.io/nav-speculation/speculation-rules.html#security-considerations.



WebView application risks

None that are specifically anticipated.



Goals for experimentation

We're hoping to gain experience about the ergonomics and impact of declarative browser-driven preloading of links in the document, tuning heuristics to provide useful tradeoffs, and refining the API surface to be easy to use.


We're hoping to confirm that the Speculation-Rules header is a useful way for servers to deliver speculation rules, that the ergonomics work sufficiently well, and that this fetch does not have adverse performance effects.


Finally, we would like to validate that this API shape of PerformanceResourceTiming's deliveryType allows developers to conveniently distinguish how a document resource was delivered.



Ongoing technical constraints

At this time the constraints are believed to be minimal.



Debuggability

Preloading and speculation rules fetches which occur are both visible in the Network panel and the in-development Preloading panel. Console warnings are logged when several types of issues are encountered.


See, e.g.

https://bugs.chromium.org/p/chromium/issues/detail?id=1315706

https://bugs.chromium.org/p/chromium/issues/detail?id=1384419



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests?

Yes


Flag name

Origin trial name "SpeculationRulesPrefetchFuture", spanning multiple underlying feature flags.


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1371522

https://bugs.chromium.org/p/chromium/issues/detail?id=1366940

https://bugs.chromium.org/p/chromium/issues/detail?id=1358591


Estimated milestones


110-115 (inclusive) on all Chrome platforms



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5112150536749056

https://chromestatus.com/feature/5069400512659456

https://chromestatus.com/feature/6347141115543552


Links to previous Intent discussions

Intents to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B5JZsPqZakqnGx2zgreGEfRCJ1Xrr16cL2gcqGF7577dFhvsw%40mail.gmail.com

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC2TYLVmZ%2BC%3Dct9VkfMi86RmypyfDOc14o1O4%3DiynRy%2B3rnyxg%40mail.gmail.com

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13cZU8%3D7Ka3SWSf4E2dgDuhRRBRt_fGgDeC6d%3DqHP%3Durrw%40mail.gmail.com


This intent message was generated by Chrome Platform Status (or rather, three of them were, and then mashed together).

Rick Byers

unread,
Dec 16, 2022, 2:58:14 PM12/16/22
to Jeremy Roman, blink-dev
LGTM

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13fCBTneL%2BmDJewBQ81A3otF9Ux4aXBVcjthkT6hfQfHJg%40mail.gmail.com.

Camille Lamy

unread,
Dec 27, 2022, 4:56:43 AM12/27/22
to blink-dev, Rick Byers, blink-dev, Jeremy Roman
Hi Jeremy,

We've been reviewing this intent as part of the S&P review process and had a few questions:
  • Does the document rules only apply to same-origin links in the page?
  • Is the delivery type gated behind TAO?
Thanks!
Camille

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Jeremy Roman

unread,
Jan 9, 2023, 2:03:53 PM1/9/23
to Camille Lamy, blink-dev, Rick Byers
On Tue, Dec 27, 2022 at 4:56 AM Camille Lamy <cl...@chromium.org> wrote:
Hi Jeremy,

We've been reviewing this intent as part of the S&P review process and had a few questions:
  • Does the document rules only apply to same-origin links in the page?
It can apply to cross-origin links if such links are selected by the author. The same restrictions apply if list rules contained the same URLs; e.g., cross-site URLs are fetched with an isolated network state (cookies, etc) and cannot be used if cookies already exist. 
  • Is the delivery type gated behind TAO?
Yes, though for the document resource itself it's pretty vacuous -- same-origin resources always pass the TAO check, and a prefetched document is same-origin to itself.

Thanks!
Camille

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Reply all
Reply to author
Forward
0 new messages