LGTM3 Discussed a bit in API owners meeting today. There are some risks here, but IMHO it's all stuff we should be able to measure, detect and respond to (eg. if sites actually get slower due to incorrect use of this API). So those concerns don't seem worth blocking on to me.
On Wed, Dec 25, 2024 at 2:40 AM 'Alex N. Jose' via blink-dev < blink-dev@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BN7OXdEMU%3DMhpnv_YwjzeTnQnfjN7SvkveG9JfM0CjrAq21pg%40mail.gmail.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/CAFUtAY8my6X7APnWWoXzn7k8iEuaHqbuvOGQJcPMTarc6610HA%40mail.gmail.com.
