On Tue, Dec 10, 2024 at 11:08 PM Chromestatus < ad...@cr-status.appspotmail.com> wrote:
> 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 > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%22> > > 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 > > Did you consider investing in Gecko's architecture? In other words, is this introducing a non-compatible web feature to address a chromium-specific software design choice? > > *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 > ) > Do you have more than 1 piece of public web developer feedback, ideally from a non-Google product? > > *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, i.e., 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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? 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 (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., 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 > <https://chromestatus.com>. > > -- > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6759101e.2b0a0220.23f11c.0000.GAE%40google.com?utm_medium=email&utm_source=footer> > . > -- 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/CAGsbWzS6pmfiuFB1vNnF0okBWOiPUVsDMuSHrFEeXpigRW3YFQ%40mail.gmail.com.
