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.
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. The Document-Policy: expect-no-linked-resources allows a web developer or page to hint to the UA that time spent in linked resource determination can be optimized out, allowing for further performance improvements in loading.
None
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
None
No milestones specified