Intent to Experiment: 103 Early Hints preload during Navigation

200 views
Skip to first unread message

Kenichi Ishibashi

unread,
May 18, 2021, 4:45:43 AMMay 18
to blink-dev, Kinuko Yasuda, Yutaka Hirano, net-dev

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

unread,
May 18, 2021, 5:32:02 AMMay 18
to Kenichi Ishibashi, blink-dev, Kinuko Yasuda, Yutaka Hirano, net-dev
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

unread,
May 18, 2021, 8:54:26 AMMay 18
to Kenichi Ishibashi, blink-dev, Kinuko Yasuda, Yutaka Hirano, net-dev
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

unread,
May 18, 2021, 9:31:12 PMMay 18
to Mike West, blink-dev, Kinuko Yasuda, Yutaka Hirano, net-dev
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.


 

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

Kenichi Ishibashi

unread,
May 18, 2021, 9:32:44 PMMay 18
to Anne van Kesteren, blink-dev, Kinuko Yasuda, Yutaka Hirano, net-dev
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

unread,
May 19, 2021, 5:38:37 AMMay 19
to Kenichi Ishibashi, Mike West, blink-dev, Kinuko Yasuda, Yutaka Hirano, net-dev
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.
 

nocth...@gmail.com

unread,
May 19, 2021, 12:05:48 PMMay 19
to Kenichi Ishibashi, Anne van Kesteren, Yutaka Hirano, net-dev, Kinuko Yasuda, blink-dev

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

unread,
May 20, 2021, 7:16:01 PMMay 20
to Yoav Weiss, Mike West, blink-dev, Kinuko Yasuda, Yutaka Hirano, net-dev
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

unread,
May 21, 2021, 2:55:05 AMMay 21
to Kenichi Ishibashi, Mike West, blink-dev, Kinuko Yasuda, Yutaka Hirano, net-dev
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

unread,
Jun 17, 2021, 5:01:21 AMJun 17
to Yoav Weiss, Mike West, blink-dev, Kinuko Yasuda, Yutaka Hirano, net-dev
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.
 

Thanks,

Yoav Weiss

unread,
Jun 17, 2021, 5:42:07 AMJun 17
to Kenichi Ishibashi, Mike West, blink-dev, Kinuko Yasuda, Yutaka Hirano, net-dev
Still LGTM. I agree that being able to monitor support for a performance optimization is a crucial part of the experiment.
Reply all
Reply to author
Forward
0 new messages