Thanks Mike and Yoav. Acknowledging the non-blocking follow up work.
On Fri, Dec 20, 2024 at 3:14 PM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > LGTM2 > > +1 for a continuous holdback study that can help us detect abuse resulting > in real-life regressions. > > On Wednesday, December 18, 2024 at 5:54:54 PM UTC+1 Mike Taylor wrote: > >> LGTM1 to ship, with some non-blocking homework. >> >> Could you please do the work to add a DevTools Issue so developers are >> aware when this hint is harming performance rather than helping? >> >> It would also be good to try to do some HTTP Archive queries (or have a >> use counter, if that's feasible) to help us better understand how many >> sites would benefit from the feature. >> >> And finally, please consider a holdback study so we can be sure there's >> not a net-negative effect to shipping. >> >> thanks, >> Mike >> On 12/13/24 12:01 PM, Alex Russell wrote: >> >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bd56d28f-870d-4143-a4a3-2047fdc5946cn%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/CA%2BN7OXdEMU%3DMhpnv_YwjzeTnQnfjN7SvkveG9JfM0CjrAq21pg%40mail.gmail.com.
