Sorry, yes, we ran as a separate thread until a few years ago. I'd forgotten that things got moved back.
A worklet for handling these fetch types wouldn't be bound to any specific execution location (it's environment would be pretty austere; not the whole regular JS heap) and would likely only be able to rewrite fetches or cancel them, rather than pause parsing. That won't solve anything for the Search use-cases, but might be more durable for the consent managers. On Friday, December 13, 2024 at 5:12:23 AM UTC-8 ale...@google.com wrote: > Re: the consent management use case — that's right; a directive that > disables speculative scan explicitly would help the consent use case more. > However, future optimizations would find it difficult to wiggle out of such > a contract. Hence a hint was chosen. From what Transcend described on the > issue <https://g-issues.chromium.org/issues/330802493#comment8>, they use > a CSP meta tag, which would stop the scanner in some versions of Chromium > (perhaps until this > <https://chromium-review.googlesource.com/c/chromium/src/+/5832754> > landed). > > Re: background thread, IIUC, speculative parsing runs on the main thread > at the moment. There might have been experiments in the past that tried to > make it run in a background thread, but those did not have the same results > as the current implementation, as far as I gathered. > > For the cases that this feature is trying to help, i.e., large html > payloads that consume significant time on main thread while speculative > parsing, as well as pages that are better off with explicit header-preload > directives or inlining resources and avoid the delay altogether, a hint is > the only viable method. The browser cannot pre-determine that piece of > information (whether there's a resource coming), on its own — thus a hint > works best here. > > > > On Fri, Dec 13, 2024 at 12:21 AM Alex Russell <slightly...@chromium.org> > wrote: > >> The consent manager case seems particularly brittle, as any future >> improvements to reduce parser blockage by <script> elements will allow the >> regular document parser to process the elements in question. Presumably the >> transcend system works using document.write()? >> >> We've talked in the past about providing something like an inline worklet >> for pre-processing resource fetches (that would, conceptually, run on the >> preload scanner thread). Until we have something like that in the platform, >> I worry that hint-based workarounds are always going to fail. >> >> Best, >> >> Alex >> >> On Thursday, December 12, 2024 at 5:36:08 AM UTC-8 ale...@google.com >> wrote: >> >>> Re: additional interest, Transcend.io had expressed >>> <https://g-issues.chromium.org/issues/330802493#comment8> interest in >>> using the feature for preventing the preload scanner from loading URLs in >>> sensitive contexts, prior to consent (non-performance improvement use >>> case). Search is currently the only report available from the feature's >>> Origin Trial period. >>> >>> Additionally, I have collected benchmarks of pages where the feature >>> would add significant performance to page loading, as shared on HTML spec >>> discussion. One could do the same against a page of interest that matches >>> the target of this feature with the experimental flag it’s currently under. >>> >>> Regarding rearchitecting the scanner itself — my analysis of Gecko’s >>> speculative scanner >>> <https://developer.mozilla.org/en-US/docs/Glossary/Speculative_parsing> >>> implementation against Chromium’s separate but lightweight scanner reached >>> the conclusion that merging them will very likely regress Chromium’s >>> speculative fetch performance. Thus there are currently no planned projects >>> in that direction. >>> >>> There is an advantage to having a lighter scan as it’s done today which >>> can discover fetches earlier than in lockstep with actual tree >>> construction, and I think it’s still the right tradeoff aligned with the >>> majority of the web who benefit from speculative scanning. A hint from >>> pages that don’t benefit from the speculative scanner, which is a very >>> specific use case indeed, is a better tradeoff and incremental improvement, >>> thus this feature. >>> >>> On Wed, Dec 11, 2024 at 11:34 PM Vladimir Levin <vmp...@chromium.org> >>> wrote: >>> >>>> Hey, >>>> >>>> We discussed this at API Owners today: >>>> 1. As Stephen mentioned, it would be nice if there was more support for >>>> this feature. Do you have partners or developers that are aware of this >>>> and >>>> are looking forward to using the feature? >>>> 2. In terms of approving this feature, we typically want the spec >>>> changes to exist in a stable forum (HTML, WICG, CSS, etc). Currently this >>>> is a spec PR that has concerns from other implementors, which isn't >>>> sufficient. Please let us know when the spec changes land in one of the >>>> accepted forums. >>>> >>>> Thank you and let me know if you have questions! >>>> >>>> Vlad >>>> >>>> On Wednesday, December 11, 2024 at 9:31:21 AM UTC-5 Stephen Chenney >>>> wrote: >>>> >>>> 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/ac7397ee-386c-47b4-a170-1e0034a58966n%40chromium.org >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ac7397ee-386c-47b4-a170-1e0034a58966n%40chromium.org?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/bd56d28f-870d-4143-a4a3-2047fdc5946cn%40chromium.org.
