I2P/I2E for Skip Preloadscan (Origin Trial)

[Alex N. Jose]

Hi!

I'm looking at experimenting with skipping the HTMLPreloadScan step of the browser (as an Origin Trial), to evaluate performance tradeoff for pages that don't benefit from the PreloadScan step (advanced web-devs / pages that have inlined most resources that benefit preloading). 

I've drafted a document with more details, and created a chromestatus entry so far. There is no spec being proposed yet  — it could come out of the OT study as a separate proposal, or as an  enhancement on the current scanner implementation. This is also my first time creating an Origin Trial, so I'm learning the process as I walk through it. What should be my next step? I2P or I2E, and could I combine these two? 

I was planning to send the following I2P to blink-dev@, but I felt I should reach out first to ask for guidance.

Thanks so much,

Alex

---- 

Contact emails

ale...@chromium.org

Explainer

https://docs.google.com/document/d/1wiaTL5TeONTZamycMVMjo76nMcbhHNYznQy7I_zCVRY/edit?usp=sharing

Specification

None

Summary

Skips the PreloadScan step of the browser to explore performance tradeoffs for pages with no sub-resource fetches. PreloadScan step of Chromium is implemented as a blocking step that benefits performance of pages with sub-resource fetches, via implementation of the speculative prefetch. However, for pages that don’t benefit from this step, i.e., for pages with no sub-resources, this is additional processing overhead with little benefit. For advanced web users who would like to benefit by reducing this overhead, this experiment provides a page-level control to disable the the PreloadScanner. Data collected from this experiment could evaluate if a modified API or a different implementation of HTMLPreloadScanner would be helpful.

Blink component

Blink>Loader

Motivation

PreloadScan step of Chromium is implemented as a blocking step that benefits performance of pages with sub-resource fetches, via implementation of the speculative prefetch. However, for pages that don’t benefit from this step, i.e., for pages with no sub-resources, this is additional processing overhead with little benefit. For advanced web users who would like to benefit by reducing this overhead, this experiment provides a page-level control to disable the the PreloadScanner. Data collected from this experiment could evaluate if a modified API or a different implementation of HTMLPreloadScanner would be helpful.

Initial public proposal

https://docs.google.com/document/d/1wiaTL5TeONTZamycMVMjo76nMcbhHNYznQy7I_zCVRY/edit?usp=sharing

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?

No

No, since in this iteration we don’t have a web exposed API, and the valid OriginTrial token itself is currently used to trigger the feature. We plan to fully test the API via web-platform-tests once they are proposed.

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5190976638550016

This intent message was generated by Chrome Platform Status.

[Noam Rosenthal]

Hi Alex!

On Wed, Mar 20, 2024 at 7:40 PM Alex N. Jose <ale...@chromium.org> wrote:
>
> Hi!
>
> I'm looking at experimenting with skipping the HTMLPreloadScan step of the browser (as an Origin Trial), to evaluate performance tradeoff for pages that don't benefit from the PreloadScan step (advanced web-devs / pages that have inlined most resources that benefit preloading).

Seems reasonable.

>
> I've drafted a document with more details, and created a chromestatus entry so far. There is no spec being proposed yet — it could come out of the OT study as a separate proposal, or as an enhancement on the current scanner implementation. This is also my first time creating an Origin Trial, so I'm learning the process as I walk through it. What should be my next step? I2P or I2E, and could I combine these two?

Does this have web-observable implications, or is it just a
performance optimization?
This seems to be in line with
https://html.spec.whatwg.org/multipage/parsing.html#speculative-html-parsing,
where speculative parsing is an optional optimization, in which case
this doesn't warrant any spec change.

[Mike Taylor]

On 3/20/24 3:40 PM, Alex N. Jose wrote:

Hi!

I'm looking at experimenting with skipping the HTMLPreloadScan step of the browser (as an Origin Trial), to evaluate performance tradeoff for pages that don't benefit from the PreloadScan step (advanced web-devs / pages that have inlined most resources that benefit preloading). 

I've drafted a document with more details, and created a chromestatus entry so far. There is no spec being proposed yet  — it could come out of the OT study as a separate proposal, or as an  enhancement on the current scanner implementation. This is also my first time creating an Origin Trial, so I'm learning the process as I walk through it. What should be my next step? I2P or I2E, and could I combine these two?

You can hop straight to I2E if you'd like, but it's also fine to send an I2P before that if you want to boost your Intents numbers. :)

--
You received this message because you are subscribed to the Google Groups "spec-mentors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spec-mentors...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/spec-mentors/CAC6ceCEcCSdQ3XfrMyzkpAecZ2of__PHcpJ8n80XXZYzXCmgFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Alex N. Jose]

Thank you so much for your guidance, Mike and Noam! I sent out the I2E.