こんにちは TAG-さん!

I'm requesting a TAG review of expect-no-linked-resources Document-Policy.

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.

This proposal introduces a configuration point in Document Policy expect-no-linked-resources to explicitly state to the User Agent that it may choose to optimize out the time spent in such linked resource determination.

• Explainer¹: https://github.com/explainers-by-googlers/expect-no-linked-resources
• Specification: https://github.com/whatwg/html/pull/10718
• WPT Tests: TBD.
• User research: Chrome Origin Trial, M125-M130
• Security and Privacy self-review²: https://explainers-by-googlers.github.io/expect-no-linked-resources/blob/main/privacy-security-questionnaire.md
• GitHub repo: https://github.com/explainers-by-googlers/expect-no-linked-resources
• Primary contacts:
  • Alex N. Jose (@alexnj), Google, Author
• Organization/project driving the specification: Google
• Multi-stakeholder support³:
  • Chromium comments: We are excited to have completed the Origin Trial of this feature and are positive about the performance improvement. We are excited to ship this feature to stable.
  • Mozilla comments:
    • https://github.com/whatwg/html/pull/10718#issuecomment-2435861290
    • W3C perf WG meeting notes: https://docs.google.com/document/d/1UtBJA6fQa_8dp2pQCQh_7Fg-snwQKq-A298i-jD0_FI/edit?tab=t.0
    • WHATNOT Meeting 2024-11-7 notes: https://github.com/whatwg/html/issues/10734
  • WebKit comments:
    • https://github.com/whatwg/html/pull/10718#issuecomment-2462217805
    • W3C perf WG meeting notes: https://docs.google.com/document/d/1UtBJA6fQa_8dp2pQCQh_7Fg-snwQKq-A298i-jD0_FI/edit?tab=t.0
    • WHATNOT Meeting 2024-11-7 notes: https://github.com/whatwg/html/issues/10734
• Status/issue trackers for implementations⁴:
  • https://crbug.com/365632977
  • https://chromestatus.com/feature/5202800863346688

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the work on this specification is currently being done: WHATWG
• The group where standardization of this work is intended to be done (if different from the current group): N/A
• Major unresolved issues with or opposition to this specification:
  • Feedback from Mozilla that Gecko does have a single pass speculative parser integrated into document parser, and that this is likely only applicable to WebKit and Chromium who have two separate passes. We do think however that Gecko could choose to ignore the hint if such a performance optimization based on the hint is not possible or not necessary.
  • There is feedback from Mozilla and WebKit around the correctness of relying on hints from the page or web developers. This is however not against the priority of constituencies and very similar optimization to, say, preload directives. This improves the user experience, in terms of perceived performance and reduced computation needs on the user's browser by actioning the hint provided by the page about its nature.
• This work is being funded by: Google

You should also know that:

• There was an earlier version of the specification, which was a full HTTP header Prefer-No-Speculative-Parsing that directly tried to control the speculative parser behavior. After consulting W3PerfWG, the header was renamed into expect-no-linked-resources and repositioned as a Document-Policy configuration point, to avoid controlling the scanner behavior directly, and to create a reusable signal that might benefit more use cases.