Intent to Ship: Subresource prefetching+loading via Signed HTTP Exchange
Tsuyoshi Horo
Contact emails
ho...@chromium.org, ksak...@chromium.org
Explainer
Specification
https://github.com/WICG/webpackage/issues/347
Design docs
https://docs.google.com/document/d/1wsK0pQYSrB_ETYPvdVr3_KjYpdAPf1le4S5LKSU9sQM/edit?usp=sharing
TAG review
https://github.com/w3ctag/design-reviews/issues/352
Summary
Support signed exchange subresource prefetching and loading by extending the HTTP link header.
Link to “Intent to Prototype” blink-dev discussion
Intent to Implement: https://groups.google.com/a/chromium.org/d/msg/blink-dev/zdvJLcditVA/FPuTNAKnCQAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msg/blink-dev/Wy6Hf9ycIKk/Ne8WRN3GAgAJ
Intent to Extend Origin Trial: https://groups.google.com/a/chromium.org/d/msg/blink-dev/X9HF6MnNXcw/zZx_tHDHAwAJ
Link to Origin Trial feedback summary
https://docs.google.com/document/d/1Ek5tbfTBPPphsHmbwypOz4iNQwCMv11aC1gi2aBPSwA/edit?usp=sharing
We had 18 sign-ups including Google Search and many others. And the result of the experiment with a news publisher indicates 300ms LCP improvement.
Risks
Interoperability and Compatibility
Interoperability - Medium
This feature is an extension of Signed HTTP Exchanges which was shipped at Chrome 73 (https://www.chromestatus.com/feature/5745285984681984) but not shipped by Firefox and Safari.
Compatibility - Low
Web developers can detect this feature by checking "document.createElement('link').relList.supports('allowed-alt-sxg')".
Gecko: No signal Mozilla standards position of Signed HTTP Exchanges is discussed at https://github.com/mozilla/standards-positions/issues/29
WebKit: No signal
Web developers: No signals
Ergonomics
> Are there any other platform APIs this feature will frequently be used in tandem with?
This feature is used with link prefetch.
> Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?
This feature is triggered only when the prefetched resource is a signed exchange and the inner response has preload links and allowed-alt-sxg links and the outer response has alternate links. This feature doesn’t affect other code paths.
Activation
We have a set of Go tools for generating and examining Signed HTTP Exchanges. And also we have NGINX SXG extension which supports subresource prefetching, and an article about how to use this extension.
Security
Chrome checks that the header integrity and inner URL of subresource signed exchange match the allowed-alt-sxg link header in the main signed exchange’s inner header which is signed by the publisher. So Chrome wouldn’t load unexpected subresources.
Debuggability
Devtools will show the information about sigined exchange subresource loading in Network tab.
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?
Yes https://wpt.fyi/results/signed-exchange/subresource
Note: signed exchange related tests are failing in wpt.fyi due to an infra issue (https://github.com/web-platform-tests/wpt/issues/24180).
Tracking bug
Demo links
https://github.com/horo-t/sub-sxg
Link to entry on the Chrome Platform Status
Tsuyoshi Horo
Link to Origin Trial feedback summary
https://docs.google.com/document/d/1Ek5tbfTBPPphsHmbwypOz4iNQwCMv11aC1gi2aBPSwA/edit?usp=sharing
We had 18 sign-ups including Google Search and many others. And the result of the experiment with a news publisher indicates 300ms LCP improvement.
Devin Mullins
The current launch is limited to a set of early adopters, in order to test its efficacy, and results have so far proven successful. Nikkei has deployed an nginx SXG module to production, and early A/B testing has shown roughly 300ms improvement in their 75th percentile Largest Contentful Paint (LCP) and 400ms improvement in First Contentful Paint (FCP) due to SXG prefetching. They believe they can achieve even further benefit through some additional render-critical preloads. We plan to expand coverage to the entire web later this year, and encourage interested publishers to subscribe to this announce list.
This LCP benefit depends on SXG subresource substitution. Last year, we launched prefetching of AMP SXGs and their subresources. The initial SXG feature was sufficient for AMP documents but relied on the fact that AMP allows distributors to rewrite URLs in the HTML without risk of breaking the page.
Additionally, we are interested in backporting SXG subresource substitution to AMP SXG. It provides benefits such as:
- Greater protection from version skew and fingerprinting (discussion).
- Reduces the need for publishers to trust the integrity of AMP caches for which they deliver SXGs.
- Removes need for proactive content negotiation on a provisional AMP-Cache-Transform request header, thus simplifying the configuration of caching intermediaries.
- Simplifies the architecture of both publishers and SXG caches by unifying formats.
- NEL reporting of failures that would lead to the prefetch being unusable, such as not all subresources prefetched before navigation. This will help us monitor the effectiveness of our cache.
- Ship prefetch-src. This will help us guarantee privacy preservation, as defense-in-depth alongside feature detection and our SXG validation code (in the event either has a bug or falls out of sync with changes in the web platform). When subresource substitution is not enabled, Chromium prefetches subresources from the href specified in the inner Link header.
Devin
Chris Harrelson
Summary
Support signed exchange subresource prefetching and loading by extending the HTTP link header.
Link to “Intent to Prototype” blink-dev discussion
Intent to Implement: https://groups.google.com/a/chromium.org/d/msg/blink-dev/zdvJLcditVA/FPuTNAKnCQAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msg/blink-dev/Wy6Hf9ycIKk/Ne8WRN3GAgAJ
Intent to Extend Origin Trial: https://groups.google.com/a/chromium.org/d/msg/blink-dev/X9HF6MnNXcw/zZx_tHDHAwAJ
Link to Origin Trial feedback summary
https://docs.google.com/document/d/1Ek5tbfTBPPphsHmbwypOz4iNQwCMv11aC1gi2aBPSwA/edit?usp=sharing
Risks
Interoperability and Compatibility
Interoperability - Medium
This feature is an extension of Signed HTTP Exchanges which was shipped at Chrome 73 (https://www.chromestatus.com/feature/5745285984681984) but not shipped by Firefox and Safari.
Compatibility - Low
Web developers can detect this feature by checking "document.createElement('link').relList.supports('allowed-alt-sxg')".
Gecko: No signal Mozilla standards position of Signed HTTP Exchanges is discussed at https://github.com/mozilla/standards-positions/issues/29
WebKit: No signal
Web developers: No signals
Ergonomics
> Are there any other platform APIs this feature will frequently be used in tandem with?
This feature is used with link prefetch.
> Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?
This feature is triggered only when the prefetched resource is a signed exchange and the inner response has preload links and allowed-alt-sxg links and the outer response has alternate links. This feature doesn’t affect other code paths.
Activation
We have a set of Go tools for generating and examining Signed HTTP Exchanges. And also we have NGINX SXG extension which supports subresource prefetching, and an article about how to use this extension.
Security
Chrome checks that the header integrity and inner URL of subresource signed exchange match the allowed-alt-sxg link header in the main signed exchange’s inner header which is signed by the publisher. So Chrome wouldn’t load unexpected subresources.
Debuggability
Devtools will show the information about sigined exchange subresource loading in Network tab.
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?
Yes https://wpt.fyi/results/signed-exchange/subresource
Note: signed exchange related tests are failing in wpt.fyi due to an infra issue (https://github.com/web-platform-tests/wpt/issues/24180).
Tracking bug
Demo links
https://github.com/horo-t/sub-sxg
Link to entry on the Chrome Platform Status
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-UoDAnvSi%3DxT5Cp0q0iEfnSk%2BH%2BRaTZAOckHNw%3Dy5HZ5g%40mail.gmail.com.
Tsuyoshi Horo
Hi, some comments inline below.On Wed, Aug 5, 2020 at 7:18 PM Tsuyoshi Horo <ho...@chromium.org> wrote:This is not a specification, it's a spec discussion issue. Could you post to (a collection of) normative spec links for the parts of this proposal?
Glad to see that this TAG review went well!Summary
Support signed exchange subresource prefetching and loading by extending the HTTP link header.
Link to “Intent to Prototype” blink-dev discussion
Intent to Implement: https://groups.google.com/a/chromium.org/d/msg/blink-dev/zdvJLcditVA/FPuTNAKnCQAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msg/blink-dev/Wy6Hf9ycIKk/Ne8WRN3GAgAJ
Intent to Extend Origin Trial: https://groups.google.com/a/chromium.org/d/msg/blink-dev/X9HF6MnNXcw/zZx_tHDHAwAJ
Link to Origin Trial feedback summary
https://docs.google.com/document/d/1Ek5tbfTBPPphsHmbwypOz4iNQwCMv11aC1gi2aBPSwA/edit?usp=sharing
Nice to see the positive performance impact for Nikkei!Two of the bugs raised in this feedback are still open. Are they just bugfixes or refinements to the feature? Are they not blocking in your view?
Risks
Interoperability and Compatibility
Interoperability - Medium
This feature is an extension of Signed HTTP Exchanges which was shipped at Chrome 73 (https://www.chromestatus.com/feature/5745285984681984) but not shipped by Firefox and Safari.
Compatibility - Low
Web developers can detect this feature by checking "document.createElement('link').relList.supports('allowed-alt-sxg')".
Gecko: No signal Mozilla standards position of Signed HTTP Exchanges is discussed at https://github.com/mozilla/standards-positions/issues/29
For the record, I agree that it seems redundant to ask for a position on a refinement to a feature Gecko opposes, so agree you don't need to open a new issue.However, I wonder if any of the objections Gecko raised to the original feature are resolved or mitigated by the additional changes contained in this intent. Could you comment on that here? I also recommend commenting on the above issue 29 with the latest updates including any impact it may have on existing arguments against SXG.
(By the way, I think issue 29 is actually about SXG and not Web Packaging / Web Bundles generally right? The title confused me, which is why I'm asking to confirm.)
WebKit: No signal
Have you reached out to WebKit for a position on SXG or subresource SXG? If not could you start a thread on webkit-dev? Even if it has been discussed elsewhere, I think a webkit-dev thread would be useful.
Web developers: No signals
This one should probably be Positive given the engagement with the Origin Trial, right? Or is there additional possibly negative feedback offsetting the positive?
Yoav Weiss
Hi.Thank you for your comments. I reply inline on your comments below.On Sat, Aug 8, 2020 at 6:19 AM Chris Harrelson <chri...@google.com> wrote:Hi, some comments inline below.On Wed, Aug 5, 2020 at 7:18 PM Tsuyoshi Horo <ho...@chromium.org> wrote:This is not a specification, it's a spec discussion issue. Could you post to (a collection of) normative spec links for the parts of this proposal?The explainer has the "Algorithm sketch" section.I'm trying to update the "Loading Signed Exchanges" spec to support Signed Exchange subresource substitution.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-WW1516wMxL2TeUNHHXCjWPr1bYiePccmJTY0YTJz-8kA%40mail.gmail.com.
jyas...@google.com
On Thu, Aug 13, 2020 at 3:52 AM 'Tsuyoshi Horo' via blink-dev <blin...@chromium.org> wrote:Hi.Thank you for your comments. I reply inline on your comments below.On Sat, Aug 8, 2020 at 6:19 AM Chris Harrelson <chri...@google.com> wrote:Hi, some comments inline below.On Wed, Aug 5, 2020 at 7:18 PM Tsuyoshi Horo <ho...@chromium.org> wrote:This is not a specification, it's a spec discussion issue. Could you post to (a collection of) normative spec links for the parts of this proposal?The explainer has the "Algorithm sketch" section.I'm trying to update the "Loading Signed Exchanges" spec to support Signed Exchange subresource substitution.It'd be good to land that PR before shipping. Looking at the PR itself, it seems like it has a hard-dependency on `prenavigate` which is not yet specified...What's the plan on that front?
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-UoDAnvSi%3DxT5Cp0q0iEfnSk%2BH%2BRaTZAOckHNw%3Dy5HZ5g%40mail.gmail.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 blin...@chromium.org.
sligh...@chromium.org
Yoav Weiss
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5169bc80-d19c-4402-aad5-8cb54020ecc5o%40chromium.org.
