Intent to Experiment: 103 Early Hints preload during Navigation

[Kenichi Ishibashi]

Contact emails

ba...@chromium.org, kin...@chromium.org, yhi...@chromium.org

Specification

https://tools.ietf.org/html/rfc8297

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/DAgWIczGtG0/m/gSXvjYn-AwAJ

Summary

When a 103 Early Hints response is received during navigation and it contains link rel=preload header fields Chrome tries to preload the specified resource before the final response is received. This is a finch experiment. Chrome triggers preload for the limited percentage of traffic. Currently we don’t plan to do an Origin Trial but we might set it up if we realize we need it.

Blink component

Internals>Preload

Activation

Servers send a 103 Early Hints informational response with link rel=preload header fields to ask Chrome to trigger subresource preloads before sending the final response. Chrome preloads subresources if the feature is activated by the experiment configuration.

For testing purposes the feature can also be enabled by `--enable-features=EarlyHintsPreloadForNavigation` command line flag.

Goals for experimentation

To see subresource preloading triggered by Early Hints can improve page rendering performance.

Experimental timeline

M91-M95

Ongoing technical constraints

None

Risks

Interoperability and Compatibility

Several servers/proxies may not understand a 103 response. They may treat the 103 response as a part of the final response when the response is sent over HTTP/1.1. The problem is less likely to happen over HTTP/2 thanks to their frame format. Chromium only handles 103 responses over HTTP/2 and HTTP/3.

Gecko: No signal

WebKit: No signal

Web developers: Positive

Positive interest and intent of support by popular CDNs (e.g. https://www.fastly.com/blog/faster-websites-early-priority-hints).

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?

No. We plan to figure out what kind of web-platform-tests we should have once the spec issue is resolved. We already have browser_tests and unittests.

Flag name

EarlyHintsPreloadForNavigation

Tracking bug

https://crbug.com/671310

Launch bug

https://crbug.com/1197989

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5207422375297024

This intent message was generated by Chrome Platform Status.

[Mike West]

On Tue, May 18, 2021 at 10:45 AM Kenichi Ishibashi <ba...@chromium.org> wrote:

Contact emails

ba...@chromium.org, kin...@chromium.org, yhi...@chromium.org

Specification

https://tools.ietf.org/html/rfc8297

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/DAgWIczGtG0/m/gSXvjYn-AwAJ

Summary

When a 103 Early Hints response is received during navigation and it contains link rel=preload header fields Chrome tries to preload the specified resource before the final response is received. This is a finch experiment. Chrome triggers preload for the limited percentage of traffic. Currently we don’t plan to do an Origin Trial but we might set it up if we realize we need it.

What percentage of traffic are you planning to experiment with? It seems like the percentage is going to need to be quite large to gather useful data, given that servers need to opt-in to sending early hints, and include a set of resources which might be useful.

Do you have partners lined up for such an experiment?

 

Blink component

Internals>Preload

Activation

Servers send a 103 Early Hints informational response with link rel=preload header fields to ask Chrome to trigger subresource preloads before sending the final response. Chrome preloads subresources if the feature is activated by the experiment configuration.

What's Chromium's current behavior if a 103 response is sent for a subresource?

For testing purposes the feature can also be enabled by `--enable-features=EarlyHintsPreloadForNavigation` command line flag.

Is this wired up to the `--enable-experimental-web-platform-features` flag as well?

Goals for experimentation

To see subresource preloading triggered by Early Hints can improve page rendering performance.

Experimental timeline

M91-M95

Ongoing technical constraints

None

Risks

Interoperability and Compatibility

Several servers/proxies may not understand a 103 response. They may treat the 103 response as a part of the final response when the response is sent over HTTP/1.1. The problem is less likely to happen over HTTP/2 thanks to their frame format. Chromium only handles 103 responses over HTTP/2 and HTTP/3.

Gecko: No signal

WebKit: No signal

Please ask for signals via the mechanism described in https://bit.ly/blink-signals.

I also note that the TAG design review section of this email is missing. Can you link to your request?

Web developers: Positive

Positive interest and intent of support by popular CDNs (e.g. https://www.fastly.com/blog/faster-websites-early-priority-hints).

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?

No. We plan to figure out what kind of web-platform-tests we should have once the spec issue is resolved. We already have browser_tests and unittests.

Flag name

EarlyHintsPreloadForNavigation

Tracking bug

https://crbug.com/671310

Launch bug

https://crbug.com/1197989

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5207422375297024

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAPLXX-_4%2B_yP44kZrJyOcc48CZqLTRQsupyqtooq%3D1u4PWWFbQ%40mail.gmail.com.

[Anne van Kesteren]

On Tue, May 18, 2021 at 10:45 AM Kenichi Ishibashi <ba...@chromium.org> wrote:

> Specification
>
> https://tools.ietf.org/html/rfc8297

I think I noted this before in a document and it doesn't necessarily
matter for an experiment, but this is not sufficient for the web
platform. The way these responses and their resulting fetches
integrate with Fetch (and its policies) is an important aspect to get
standardized (and ideally would have been considered more during the
standardization of 103 itself).

[Kenichi Ishibashi]

Hi Mike, thank you for your questions!

On Tue, May 18, 2021 at 6:31 PM Mike West <mk...@chromium.org> wrote:

On Tue, May 18, 2021 at 10:45 AM Kenichi Ishibashi <ba...@chromium.org> wrote:

Contact emails

ba...@chromium.org, kin...@chromium.org, yhi...@chromium.org

Specification

https://tools.ietf.org/html/rfc8297

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/DAgWIczGtG0/m/gSXvjYn-AwAJ

Summary

When a 103 Early Hints response is received during navigation and it contains link rel=preload header fields Chrome tries to preload the specified resource before the final response is received. This is a finch experiment. Chrome triggers preload for the limited percentage of traffic. Currently we don’t plan to do an Origin Trial but we might set it up if we realize we need it.

What percentage of traffic are you planning to experiment with? It seems like the percentage is going to need to be quite large to gather useful data, given that servers need to opt-in to sending early hints, and include a set of resources which might be useful.

Currently we plan to enable 50% on Canary, Dev and Beta, and 1% on Stable. We will revisit the percentage if the configuration doesn't provide enough numbers.

 

Do you have partners lined up for such an experiment?

Yes, we have partners who are interested in experimenting with the feature. We've been talking about the experiment details. When we have updates I'll post follow up emails to this thread.

 

 

Blink component

Internals>Preload

Activation

Servers send a 103 Early Hints informational response with link rel=preload header fields to ask Chrome to trigger subresource preloads before sending the final response. Chrome preloads subresources if the feature is activated by the experiment configuration.

What's Chromium's current behavior if a 103 response is sent for a subresource?

Chromium ignores a 103 response that is sent for a subresource. Details can be found in a crbug.com entry.

 

For testing purposes the feature can also be enabled by `--enable-features=EarlyHintsPreloadForNavigation` command line flag.

Is this wired up to the `--enable-experimental-web-platform-features` flag as well?

No, but I think we can do that if that's preferable.

 

Goals for experimentation

To see subresource preloading triggered by Early Hints can improve page rendering performance.

Experimental timeline

M91-M95

Ongoing technical constraints

None

Risks

Interoperability and Compatibility

Several servers/proxies may not understand a 103 response. They may treat the 103 response as a part of the final response when the response is sent over HTTP/1.1. The problem is less likely to happen over HTTP/2 thanks to their frame format. Chromium only handles 103 responses over HTTP/2 and HTTP/3.

Gecko: No signal

WebKit: No signal

Please ask for signals via the mechanism described in https://bit.ly/blink-signals.

Done:

Gecko: https://github.com/mozilla/standards-positions/issues/530
WebKit: https://lists.webkit.org/pipermail/webkit-dev/2021-May/031861.html

 

I also note that the TAG design review section of this email is missing. Can you link to your request?

Tag review: https://github.com/w3ctag/design-reviews/issues/638

[Kenichi Ishibashi]

Hi Anne,

Sorry I forgot to mention that. We filed a spec issue (https://github.com/whatwg/fetch/issues/1225) to discuss how to integrate with the Fetch standard. We plan to work on the integration once the experiment goes well.

[Yoav Weiss]

Thanks for experimenting with this!

What's the plan in terms of monitoring? I know we discussed offline the possibility of adding an Early Hints indication as part of Resource Timing.

Is that planned to be part of that experiment? Or are you planning to send a separate intent for that? 

On Wed, May 19, 2021 at 3:31 AM Kenichi Ishibashi <ba...@chromium.org> wrote:

Hi Mike, thank you for your questions!

On Tue, May 18, 2021 at 6:31 PM Mike West <mk...@chromium.org> wrote:

On Tue, May 18, 2021 at 10:45 AM Kenichi Ishibashi <ba...@chromium.org> wrote:

Contact emails

ba...@chromium.org, kin...@chromium.org, yhi...@chromium.org

Specification

https://tools.ietf.org/html/rfc8297

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/DAgWIczGtG0/m/gSXvjYn-AwAJ

Summary

When a 103 Early Hints response is received during navigation and it contains link rel=preload header fields Chrome tries to preload the specified resource before the final response is received. This is a finch experiment. Chrome triggers preload for the limited percentage of traffic. Currently we don’t plan to do an Origin Trial but we might set it up if we realize we need it.

What percentage of traffic are you planning to experiment with? It seems like the percentage is going to need to be quite large to gather useful data, given that servers need to opt-in to sending early hints, and include a set of resources which might be useful.

Currently we plan to enable 50% on Canary, Dev and Beta, and 1% on Stable. We will revisit the percentage if the configuration doesn't provide enough numbers.

 

Do you have partners lined up for such an experiment?

Yes, we have partners who are interested in experimenting with the feature. We've been talking about the experiment details. When we have updates I'll post follow up emails to this thread.

It might be worthwhile to verify with your partners that 1% of stable traffic would be sufficient for them.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAPLXX--Axo8G20pFp%3DqJZW1agAuK_mZEoGvnG%3Dz_Y3-JWPkY-g%40mail.gmail.com.

[nocth...@gmail.com]

Gracias

Sent from Nine

---

De:Kenichi Ishibashi <ba...@chromium.org>
Enviado:18 may 2021 20:32
Para:Anne van Kesteren
Cc: blink-dev; Kinuko Yasuda; Yutaka Hirano; net-dev
Asunto: Re: [blink-dev] Intent to Experiment: 103 Early Hints preload during Navigation

--
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/CAPLXX-_Q73mo1v-nzvpErEXF-FPdDAJByz_NyybdQpNP1_2dZQ%40mail.gmail.com.

[Kenichi Ishibashi]

Hi Yoav, sorry for the late reply.

On Wed, May 19, 2021 at 6:38 PM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for experimenting with this!

What's the plan in terms of monitoring? I know we discussed offline the possibility of adding an Early Hints indication as part of Resource Timing.

Is that planned to be part of that experiment? Or are you planning to send a separate intent for that? 

We likely propose adding a new attribute to PerformanceResourceTiming or adding a new value for `initiatorType`. I'm planning to send a separate intent as needed.

On Wed, May 19, 2021 at 3:31 AM Kenichi Ishibashi <ba...@chromium.org> wrote:

Hi Mike, thank you for your questions!

On Tue, May 18, 2021 at 6:31 PM Mike West <mk...@chromium.org> wrote:

On Tue, May 18, 2021 at 10:45 AM Kenichi Ishibashi <ba...@chromium.org> wrote:

Contact emails

ba...@chromium.org, kin...@chromium.org, yhi...@chromium.org

Specification

https://tools.ietf.org/html/rfc8297

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/DAgWIczGtG0/m/gSXvjYn-AwAJ

Summary

When a 103 Early Hints response is received during navigation and it contains link rel=preload header fields Chrome tries to preload the specified resource before the final response is received. This is a finch experiment. Chrome triggers preload for the limited percentage of traffic. Currently we don’t plan to do an Origin Trial but we might set it up if we realize we need it.

What percentage of traffic are you planning to experiment with? It seems like the percentage is going to need to be quite large to gather useful data, given that servers need to opt-in to sending early hints, and include a set of resources which might be useful.

Currently we plan to enable 50% on Canary, Dev and Beta, and 1% on Stable. We will revisit the percentage if the configuration doesn't provide enough numbers.

 

Do you have partners lined up for such an experiment?

Yes, we have partners who are interested in experimenting with the feature. We've been talking about the experiment details. When we have updates I'll post follow up emails to this thread.

It might be worthwhile to verify with your partners that 1% of stable traffic would be sufficient for them.

Yes, we talked about the percentages. I'll post an update when we decide to change the percentages. Currently we don't plan to change the percentages.

[Yoav Weiss]

LGTM to experiment M91-M95

On Fri, May 21, 2021 at 1:15 AM Kenichi Ishibashi <ba...@chromium.org> wrote:

Hi Yoav, sorry for the late reply.

On Wed, May 19, 2021 at 6:38 PM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for experimenting with this!

What's the plan in terms of monitoring? I know we discussed offline the possibility of adding an Early Hints indication as part of Resource Timing.

Is that planned to be part of that experiment? Or are you planning to send a separate intent for that? 

We likely propose adding a new attribute to PerformanceResourceTiming or adding a new value for `initiatorType`. I'm planning to send a separate intent as needed.

That sounds great, thanks! :)

[Kenichi Ishibashi]

Hi API owners,

Regarding a PerformanceResourceTiming change for monitoring, we are going to add a new value "early-hints" for `initiatorType` [1].

We consider this web-exposing change is a crucial part of this intent to experiment. We would like to make the change as a part of this intent. I added a section for the change to the design doc [2]. The explainer for TAG review also mentions the change [3].

Please let us know if we need a separate intent for the change.

 

[1] https://github.com/w3c/resource-timing/issues/273

[2] https://docs.google.com/document/d/1gCh_CnfrJq_VL7aGoq6skc7sn4yn5pKsM0gkHe5B9go/edit#heading=h.vsk6lnrdp6xp

[3] https://github.com/bashi/early-hints-explainer/blob/main/explainer.md#extension-to-the-performanceresourcetiming

Thanks,

[Yoav Weiss]

Still LGTM. I agree that being able to monitor support for a performance optimization is a crucial part of the experiment.

[Kenichi Ishibashi]

Hi blink-dev,

We now plan to run an origin trial for Early Hints preload. We realized that running an origin trial is useful for developers to try the feature. CL for integrating with the origin trial frame is under review. Experiment timeline unchanged (until M95).

Thanks,

[Kenichi Ishibashi]

Hi API owners,

We would like to add preconnect [1] support in this experiment. The purpose of preconnect is similar to preload but it's more lightweight: preload tries to fetch resources, preconnect just tries to establish connections. If this addition is reasonable, we will update relevant documents and work on relevant spec works.

[1] https://www.w3.org/TR/resource-hints/#preconnect

[Yoav Weiss]

I think the addition is reasonable, and it makes perfect sense to add it as part of the same Origin Trial.

Is the addition a result of feedback from OT participants? If so, I think it makes sense to add that support without requiring much process.

On Fri, Aug 27, 2021 at 9:45 AM Kenichi Ishibashi <ba...@chromium.org> wrote:

Hi API owners,

We would like to add preconnect [1] support in this experiment. The purpose of preconnect is similar to preload but it's more lightweight: preload tries to fetch resources, preconnect just tries to establish connections. If this addition is reasonable, we will update relevant documents and work on relevant spec works.

Updating the documentation seems critical, so thanks for doing that!

[Kenichi Ishibashi]

Hi Yoav,

On Fri, Aug 27, 2021 at 5:25 PM Yoav Weiss <yoav...@chromium.org> wrote:

I think the addition is reasonable, and it makes perfect sense to add it as part of the same Origin Trial.

Is the addition a result of feedback from OT participants? If so, I think it makes sense to add that support without requiring much process.

Yes, we got feedback from our partners that preconnect will be beneficial to them.