Just idea - Should we invoke GlowPlug on PreconnectNavigation?

[Kouhei Ueno]

Hi jam@,

cc: haraken, loading-dev

I was wondering if a simple extension to your PreconnectNavigation optimization makes sense.

Context: I was poking around with Omnibox autocomplete predictor code and noticed that "preconnect" there is not actually preconnect but triggers Glowplug prefetch + subresource orrigins preconnect [code].

I was wondering if we should upgrade the NagivationRequest preconnect trigger to do that too.

Your instinct on the idea is appreciated. I can write a CL if this sounds worth experimenting.

Thanks,

kouhei

[Kouhei Ueno]

On Mon, Aug 7, 2023 at 1:57 PM Kentaro Hara <har...@chromium.org> wrote:

Context: I was poking around with Omnibox autocomplete predictor code and noticed that "preconnect" there is not actually preconnect but triggers Glowplug prefetch + subresource orrigins preconnect [code].

Is this the same thing as Reactive Prefetch (which is enabled on Android)?

TBH I'm not super familiar with the difference between ReactivePrefetch and GlowPlug.

One thing that I can add is that LoadingPredictor also has a local database based subresource origin preconnect [code], which IIUC is different from reactive preconnect?

 

I was wondering if we should upgrade the NagivationRequest preconnect trigger to do that too.
Your instinct on the idea is appreciated. I can write a CL if this sounds worth experimenting.

Do we have any data about how much head start time we have for NavigationRequest? Is it mostly consumed by preconnect, or do we have more time? (I guess we have enough head start time only when there is an onbeforeunload handler.) If we have more time, I'm wondering if we should start with prefetching the main resource before prefetching subresources.

BTW I'm surprised we are prefetching subresources in LoadingPredictor::MaybeAdd"Preconnect". We should probably refactor the code a bit :)

--

Kentaro Hara, Tokyo

--

kouhei

[Kentaro Hara]

(Re-sending since I didn't have permission to send to loading-dev@.)

 

TBH I'm not super familiar with the difference between ReactivePrefetch and GlowPlug.

I'm not sure about the history of GlowPlug but my guess is that the idea of GlowPlug was absorbed in ReactivePrefetch and launched.

One thing that I can add is that LoadingPredictor also has a local database based subresource origin preconnect [code], which IIUC is different from reactive preconnect?

Reactive Prefetch is about "prefetch", not "preconnect".

Context: I was poking around with Omnibox autocomplete predictor code and noticed that "preconnect" there is not actually preconnect but triggers Glowplug prefetch + subresource orrigins preconnect [code].

Is this the same thing as Reactive Prefetch (which is enabled on Android)?

...and I got the answer myself. It is the same thing :)

Reactive Prefetch was enabled on Android in this CL. It is controlled by the flag named "kLoadingPredictorPrefetch". You are now talking about the code behind the flag :)

On Mon, Aug 7, 2023 at 2:42 PM Kentaro Hara <har...@chromium.org> wrote:

TBH I'm not super familiar with the difference between ReactivePrefetch and GlowPlug.

I'm not sure about the history of GlowPlug but my guess is that the idea of GlowPlug was absorbed in ReactivePrefetch and launched.

One thing that I can add is that LoadingPredictor also has a local database based subresource origin preconnect [code], which IIUC is different from reactive preconnect?

Reactive Prefetch is about "prefetch", not "preconnect".

Context: I was poking around with Omnibox autocomplete predictor code and noticed that "preconnect" there is not actually preconnect but triggers Glowplug prefetch + subresource orrigins preconnect [code].

Is this the same thing as Reactive Prefetch (which is enabled on Android)?

...and I got the answer myself. It is the same thing :)

Reactive Prefetch was enabled on Android in this CL. It is controlled by the flag named "kLoadingPredictorPrefetch". You are now talking about the code behind the flag :)

--

Kentaro Hara, Tokyo

[Kouhei Ueno]

@John Abd-El-Malek @Scott Violet Do you have insight into the following haraken's question?

> Do we have any data about how much head start time we have for NavigationRequest? Is it mostly consumed by preconnect, or do we have more time? (I guess we have enough head start time only when there is an onbeforeunload handler.) If we have more time, I'm wondering if we should start with prefetching the main resource before prefetching subresources.

This sounds like the question we should ask for determining if earlier GlowPlug is worth investigating or not.

--

kouhei

[Kentaro Hara]

Head start time = how much time we have to do something (preconnect, main resource prefetch, subresource prefetch etc). If the "head start time" is mostly consumed by preconnecting, it won't make sense to implement the main resource prefetch.

On Tue, Aug 8, 2023 at 10:27 PM Scott Violet <s...@google.com> wrote:

On Mon, Aug 7, 2023 at 8:56 PM Kouhei Ueno <kou...@google.com> wrote:

@John Abd-El-Malek @Scott Violet Do you have insight into the following haraken's question?

> Do we have any data about how much head start time we have for NavigationRequest? Is it mostly consumed by preconnect, or do we have more time? (I guess we have enough head start time only when there is an onbeforeunload handler.) If we have more time, I'm wondering if we should start with prefetching the main resource before prefetching subresources.

This sounds like the question we should ask for determining if earlier GlowPlug is worth investigating or not.

What do you mean by 'head start time'? I think John is the most familiar with preconnect for NavigationRequest and has more insight than I do.

  -Scott

--

Kentaro Hara, Tokyo