Intent to Ship: Subresource prefetching+loading via Signed HTTP Exchange

406 views
Skip to first unread message

Tsuyoshi Horo

unread,
Aug 5, 2020, 10:18:40 PM8/5/20
to blink-dev, ksak...@chromium.org, Kinuko Yasuda

Contact emails

ho...@chromium.org, ksak...@chromium.org


Explainer

https://github.com/WICG/webpackage/blob/master/explainers/signed-exchange-subresource-subtitution-explainer.md


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

https://crbug.com/935267


Demo links

https://github.com/horo-t/sub-sxg


Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5126805474246656


Tsuyoshi Horo

unread,
Aug 6, 2020, 1:59:00 AM8/6/20
to blink-dev, ksak...@chromium.org, Kinuko Yasuda
Forgot to mention, let me clarify.

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.


This publisher's site is a regular web page, not an AMP page.
 

Devin Mullins

unread,
Aug 6, 2020, 12:58:03 PM8/6/20
to blink-dev, Tsuyoshi Horo, Kunihiko Sakamoto, Kinuko Yasuda
Hi, I just wanted to chime in with feedback from an experiment using this origin trial. We have used this to ship a feature whereby Google Search can prefetch signed exchanges (SXGs) for pages and their preloaded subresources, in anticipation of a result click. This enables the same instant loading that AMP enables, but for all web content from publishers who so desire (including non-AMP). This should serve as another tool in the toolbox for web developers to improve their Web Vitals, which should in turn lead to greater user engagement.

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.
Going forward, we have a couple of follow-up feature requests that will enable our long-term success:
  • 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.
Thanks,
Devin

Chris Harrelson

unread,
Aug 7, 2020, 5:20:04 PM8/7/20
to Tsuyoshi Horo, blink-dev, Kunihiko Sakamoto, Kinuko Yasuda
Hi, some comments inline below.

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?
 


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

https://crbug.com/935267


Demo links

https://github.com/horo-t/sub-sxg


Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5126805474246656


--
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

unread,
Aug 12, 2020, 9:52:09 PM8/12/20
to Chris Harrelson, blink-dev, Kunihiko Sakamoto, Kinuko Yasuda
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.

 
 

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?

The two issues are nice-to-have features. They are not blocking issues.

 
 

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.)

The issue 29 is about SXG. 264 is the Mozilla standards position issue for Web Bundles.

 
 

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.

I sent a request for WebKit position on this feature to webkit-dev.
 
 

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?

Sorry I forgot to update this section when I generated this Intent to ship in chromestatus.com.
The feedback from Web developers is Positive.

Yoav Weiss

unread,
Aug 13, 2020, 10:41:44 AM8/13/20
to Tsuyoshi Horo, Chris Harrelson, blink-dev, Kunihiko Sakamoto, Kinuko Yasuda
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?
 

jyas...@google.com

unread,
Sep 3, 2020, 3:27:03 PM9/3/20
to blink-dev, ho...@google.com, chri...@google.com, ksak...@chromium.org, kin...@chromium.org
On Thursday, August 13, 2020 at 7:41:44 AM UTC-7, Yoav Weiss wrote:


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?

I've been (slowly, sorry) reviewing and touching up the specification PR. It and the implementation actually depend on `prefetch` rather than `prenavigate`, and the remaining issues (if any) look to be around wording tweaks and changing vague words like "matches" to [=url/equals=]. I don't expect the PR review to result in any implementation changes.

Jeffrey

 
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

--
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

unread,
Sep 3, 2020, 7:33:41 PM9/3/20
to blink-dev, ho...@google.com, chri...@google.com, ksak...@chromium.org, kin...@chromium.org
Thanks for clarifying that.

LGTM1

Yoav Weiss

unread,
Sep 7, 2020, 6:00:32 AM9/7/20
to Alex Russell, blink-dev, Tsuyoshi Horo, Chris Harrelson, Kunihiko Sakamoto, Kinuko Yasuda
I reviewed the PR and LGTMed it. My previous impression that this relies heavily on "prenavigate" was not accurate. At the same time, it does rely on prefetch, preload and Link header processing which are all under-specified, but shipped.
As part of the PR's processing model changes, it explicitly defines when processing of Link headers for this case is done, which is an improvement on the status quo, and can perhaps be generalized to tackle the same definitions for other rel types. 
It also explicitly mentions the reliance on "when the document's viewport is known" which is something Link header's implementation relies on when triggering `media` based preloads.
While it would've been better to fully specify when that happens rather than hand-wave it, it entails specifying the preloadScanner, which seems like a large project on its own. I felt that a note to that effect would be sufficient at the moment, and better than the "completely undefined" status-quo.

Beyond that, I think it'd be good for us to have an overall plan for defining the underlying primitives for preload, prefetch and beyond. I wrote such a plan and hope that a cross-team effort can make it a reality.
All that to say...

LGTM2
 




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.

Chris Harrelson

unread,
Sep 8, 2020, 11:54:45 AM9/8/20
to Yoav Weiss, Alex Russell, blink-dev, Tsuyoshi Horo, Kunihiko Sakamoto, Kinuko Yasuda
LGTM3
Reply all
Reply to author
Forward
0 new messages