LGTM to extend the experiment until 101
/Daniel
On 2021-10-29 10:06, Hayato Ito wrote:
Hi Mike,
Thanks for the comment. We appreciate that. Let me add some
clarifications and additional info.
On Fri, Oct 29, 2021 at 3:38 AM Mike West <[email protected]> wrote:
On Thu, Oct 28, 2021 at 6:49 AM Daisuke Enomoto
<[email protected]> wrote:
Contact emails
[email protected], [email protected]
Explainer
https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md
<https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md>
Specification
Design docs
https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/content/browser/web_package/subresource_loading_origin_trial.md
<https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/content/browser/web_package/subresource_loading_origin_trial.md>
Summary
Provides a new approach to load a large number of resources
efficiently using a format that allows multiple resources to
be bundled, e.g. Web Bundles.
Blink component
Blink>Loader>WebPackaging
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader%3EWebPackaging>
TAG review
https://github.com/w3ctag/design-reviews/issues/616
<https://github.com/w3ctag/design-reviews/issues/616>
(We’ll reopen this once we can have a consensus in the
discussion here <https://github.com/WICG/webpackage/issues/699>)
TAG review status
Pending
Risks
Interoperability and Compatibility
No interoperability and compatibility risk has been identified
for the prototype phase. This is purely a feature addition for
the performance optimization for now.
It is expected that a browser which doesn’t support this
feature should load subresources from the network, as usual.
Gecko: No signal
WebKit: No signal
Web developers: No signals
This might be a good time to ask, as per
https://bit.ly/blink-signals. :)
That makes sense. Let us do that soon. We'll update this thread when done.
Ergonomics
Activation
Developers need to package their subresoruces beforehand in
order to take advantage of this feature. We'll work with JS
bundler ecosystems to provide a plugin to package subresources
as Web Bundles.
Security
No security risk has been identified for the prototype phase.
Goals for experimentation
<Key change included in the Intent to Extend>
This Intent to Extend includes a few major changes based on
the feedback collected during the original OT, which are 1)
<script>-based API from <link>-based API, 2) new scheme:
uuid-in-package, and 3) New Web Bundle format version. The
extension allows us to get sufficient data before shipping the
feature.
Does #1 refer to
https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading.md#link-based-api?
I'm a little confused about this, as I thought we'd decided not to
rely on <link> due to the concerns in
https://github.com/WICG/webpackage/issues/580.
Our intention was that #1 refer to the new <script>-based API
<https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading.md#script-based-api>,
which is aiming to replace the <link>-based API.
> as I thought we'd decided not to rely on <link> due to the concerns
in https://github.com/WICG/webpackage/issues/580.
That's right. Exactly for that reason, we've designed and implemented
a new <script type=webbundle> API. The design doc of <script
type=webbundle>
<https://docs.google.com/document/d/1q_SodTcLuwya4cXt1gIRaVrkiaBfwWyPvkY1fqRKkgM/edit?resourcekey=0-dqrFOGVCYsg8WRZ4RFgwuw> explains
the reason as well.
New <script>-based API will be available from M97 in the extended OT.
Note: we plan to remove <link>-based APIs at an appropriate timing
after a good communication with OT customers.
More broadly, these changes don't appear to be included in the
explainer. I might be misunderstanding the scope, but I'd suggest
some clarification there so developers know what to expect.
That makes sense. Since it might be difficult for developers to
understand "what's changed" by looking at one explainer, we have been
trying to have a migration guide for developers. I've just made the
internal one public here
<https://docs.google.com/document/d/1hAl7jb-a9WET_mSeHBD9HxIBUwUe65Dbyn6u6LRB61s/edit?usp=sharing>.
That's still draft, however, let us keep this up-to-date.
It seems the original trial guide
<https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/content/browser/web_package/subresource_loading_origin_trial.md> is
out of date. We'll update this guide too, incorporating the public
migration guide doc. Hopefully, the origin trial guide
<https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/content/browser/web_package/subresource_loading_origin_trial.md> will
be the source of truth for this extended OT.
See these documents for details.
*
<script type=webbundle> (public)
<https://docs.google.com/document/d/1q_SodTcLuwya4cXt1gIRaVrkiaBfwWyPvkY1fqRKkgM/edit?resourcekey=0-dqrFOGVCYsg8WRZ4RFgwuw#>
*
https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading-opaque-origin-iframes.md
<https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading-opaque-origin-iframes.md>
*
https://wpack-wg.github.io/bundled-responses/draft-ietf-wpack-bundled-responses.html
<https://wpack-wg.github.io/bundled-responses/draft-ietf-wpack-bundled-responses.html>
In addition, the original main goals remain unchanged:
1. Measure how this feature makes a subresource loading faster
in real sites.
2. Measure how this feature improves Ad Serving. See
WebBundles for Ad Serving
(https://github.com/WICG/webpackage/issues/624
<https://github.com/WICG/webpackage/issues/624>) for details.
3. Collect feedback on the API surface so that we can discuss
how this and alternative approaches like resource-bundles
(https://github.com/WICG/resource-bundles
<https://github.com/WICG/resource-bundles>) could potentially
converge in the future.
Reason this experiment is being extended
We started with <link>-based API in the original OT to allow
quicker availability and confirmed the intended effect of the
feature. We are extending the OT to experiment with
<script>-based API we had originally planned along with other
changes we decided to apply based on the feedback collected in
the original OT.
1) <script>-based API from <link>-based API
2) new scheme: uuid-in-package
3) Web Bundle format version
It would be nice that we have a chance of a few more
iterations so that we can fix our implementation in case we
find something is wrong in M97. Therefore, we plan to extend
the OT to M101.
Original
I2E:https://groups.google.com/a/chromium.org/g/blink-dev/c/9CwkzaF_eQ4/m/kuR07FTTCAAJ
<https://groups.google.com/a/chromium.org/g/blink-dev/c/9CwkzaF_eQ4/m/kuR07FTTCAAJ>
Ongoing technical constraints
None
Debuggability
Developers have the ability to test this functionality on
their pages by opening DevTools and selecting the Network tab.
This allows the DevTools to represent Web Bundles and the
resources that originate from it being attributed to the Web
Bundle.
Will this feature be supported on all six Blink
platforms (Windows, Mac, Linux, Chrome OS, Android,
and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
No
Flag name
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1082020
<https://bugs.chromium.org/p/chromium/issues/detail?id=1082020>
Launch bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1133108
<https://bugs.chromium.org/p/chromium/issues/detail?id=1133108>
Estimated milestones
OriginTrial desktop last
101
OriginTrial desktop first
90
OriginTrial android last
101
OriginTrial android first
90
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5710618575241216
<https://chromestatus.com/feature/5710618575241216>
Links to previous Intent discussions
Intent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/wYn13HabRN0/m/L4y4iY1-AgAJ
<https://groups.google.com/a/chromium.org/g/blink-dev/c/wYn13HabRN0/m/L4y4iY1-AgAJ>
Intent to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/9CwkzaF_eQ4/m/kuR07FTTCAAJ
<https://groups.google.com/a/chromium.org/g/blink-dev/c/9CwkzaF_eQ4/m/kuR07FTTCAAJ>
This intent message was generated by Chrome Platform Status
<https://www.chromestatus.com/>.
-----------
Thanks
Daisuke
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e698pi1FC6NCiY0KpxXuqbO8%2BeQ6dNiVkZ9OSq0LBdX089g%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e698pi1FC6NCiY0KpxXuqbO8%2BeQ6dNiVkZ9OSq0LBdX089g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
Hayato
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_1FmjsZBVJaxhLheM025jbBG_-N4k%3DDcr1o8HQ316Tq9w%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_1FmjsZBVJaxhLheM025jbBG_-N4k%3DDcr1o8HQ316Tq9w%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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dc1e49c7-19be-9187-b5b3-3b1d20747d34%40gmail.com.
