Contact emails ale...@google.com
Explainer https://github.com/explainers-by-googlers/expect-no-linked-resources https://explainers-by-googlers.github.io/expect-no-linked-resources Specification https://github.com/whatwg/html/pull/10718 Summary The expect-no-linked-resources configuration point in Document Policy allows a document to hint to the user agent to better optimize its loading sequence, such as not using the default speculative parsing behavior. User Agents have implemented speculative parsing of HTML to speculatively fetch resources that are present in the HTML markup, to speed up page loading. For the vast majority of pages on the Web that have resources declared in the HTML markup, the optimization is beneficial and the cost paid in determining such resources is a sound tradeoff. However, the following scenarios might result in a sub-optimal performance tradeoff vs. the explicit time spent parsing HTML for determining sub resources to fetch: * Pages that do not have any resources declared in the HTML. * Large HTML pages with minimal or no resource loads that could explicitly control preloading resources via other preload mechanisms available. `expect-no-linked-resources` Document-Policy hints the User Agent that it may choose to optimize out the time spent in such sub resource determination. Blink component Blink TAG review https://github.com/w3ctag/design-reviews/issues/1014 TAG review status Pending Risks Interoperability and Compatibility Gecko has its speculative parsing pass integrated into document parser and hypothesizes that it might not have any benefit by adopting this standard. WebKit's stance is that it might want to invest in Gecko's architecture wrt. speculative parsing vs. receiving a hint from the web developer to optimize the hint. Thus this feature might not become interoperable. We believe that it is worth proceeding anyways, as our experimentation with parsing architectures suggests that there is a real tradeoff here that cannot be solved without a web developer hint. As a document-policy hint, the interoperability cost of this not being implemented everywhere is low: its presence will only cause small differences in speculative parsing timing, which are already permitted by the HTML Standard. Similarly, the compatibility risk of this feature is low. If we were to eventually remove it, it would be very hard for web developers to notice. More of the discussions at the HTML standard pull request and the subsequent WHATNOT meeting notes below: https://github.com/whatwg/html/pull/10718 WHATNOT discussion minutes: https://github.com/whatwg/html/issues/10709 https://github.com/whatwg/html/issues/10720 https://github.com/whatwg/html/issues/10734 https://github.com/whatwg/html/issues/10750 Gecko: Negative (https://github.com/whatwg/html/pull/10718) Gecko has its speculative parsing pass integrated into document parser and hypothesizes that it might not have any benefit by adopting this standard. Given their comments on the pull requests and at WHATNOT meetings, we believe it's not necessary to file for a formal standards position. WebKit: Negative (https://github.com/whatwg/html/pull/10718) Given their comments on the pull requests and at WHATNOT meetings, we believe it's not necessary to file for a formal standards position. Web developers: Positive (https://docs.google.com/document/d/1VhztmwDUz40sb2HEBfNJjplva8hXgAP3C6qlyTFbfr0/edit?tab=t.0#heading=h.9mt7t18673oo) Other signals: Ergonomics None. The feature is opted-in on a per-response basis by a page that does not benefit from speculative parsing, and is off by default. Activation None. Security This feature does not change security risks. WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? None Debuggability The feature usage, ie, opt-in by the page, will be visible under page Headers in network panel of the DevTools interface. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? Yes https://github.com/web-platform-tests/wpt/pull/49617 Flag name on about://flags Finch feature name DocumentPolicyExpectNoEmbeddedResources Requires code in //chrome? False Tracking bug https://issues.chromium.org/issues/365632977 Estimated milestones Shipping on desktop 133 Shipping on Android 133 Shipping on WebView 133 Anticipated spec changes Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (eg links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (eg, changing to naming or structure of the API in a non-backward-compatible way). None Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5202800863346688?gate=5195231151259648 Links to previous Intent discussions Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/00000000000050b3190621c328c4%40google.com This intent message was generated by Chrome Platform Status. -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6759101e.2b0a0220.23f11c.0000.GAE%40google.com.
