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
<http://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
<mailto:ad...@cr-status.appspotmail.com>> wrote:
Contact emails ale...@google.com
Explainer
https://github.com/explainers-by-googlers/expect-no-linked-resources
<https://github.com/explainers-by-googlers/expect-no-linked-resources>
https://explainers-by-googlers.github.io/expect-no-linked-resources
<https://explainers-by-googlers.github.io/expect-no-linked-resources>
Specification
https://github.com/whatwg/html/pull/10718
<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
<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
<https://github.com/whatwg/html/pull/10718>
WHATNOT discussion minutes:
https://github.com/whatwg/html/issues/10709
<https://github.com/whatwg/html/issues/10709>
https://github.com/whatwg/html/issues/10720
<https://github.com/whatwg/html/issues/10720>
https://github.com/whatwg/html/issues/10734
<https://github.com/whatwg/html/issues/10734>
https://github.com/whatwg/html/issues/10750
<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
<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
<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
<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
<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
<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
<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
<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
<mailto: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
<mailto: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>.
