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/9bc70d30-9d6d-4ff4-b09b-394d7ba8cf89n%40chromium.org.
