Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document-Policy: expect-no-linked-resources #169

Open
alexnj opened this issue Sep 9, 2024 · 0 comments
Open

Document-Policy: expect-no-linked-resources #169

alexnj opened this issue Sep 9, 2024 · 0 comments

Comments

@alexnj
Copy link
Member

alexnj commented Sep 9, 2024

Introduction

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 by the name expect-no-linked-resources to hint to the User Agent that it may choose to optimize out the time spent in such sub resource determination.

Read the complete Explainer and spec changes proposed.

Additional context

An earlier version of the proposal, named Prefer-No-Speculative-Parsing that controlled speculative parser behavior more directly via a header was presented at W3C Performance Working Group on August 29, 2024. This revised proposal adjusts for feedback received from the forum to (1) integrate the signal into Document-Policy and (2) convert into a hint that a UA could base current and future optimizations on (vs. a direct control of speculative parser).

Feedback

I welcome feedback in this thread, but encourage you to file bugs against the proposal repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant