search

eligrey / speculative-request-control

Speculative Request Control explainer
3 stars 0 forks source link

Claims about preloader are not backed by data #1

Open yoavweiss opened 4 years ago

yoavweiss commented 4 years ago

The explainer says: "While this indeed benefited typical websites of the time, it does not benefit modern sites that are properly marked up with async/defer scripts where appropriate"

It'd be good to show data that proves this is indeed the case

eligrey commented 4 years ago

True, it would be nice to see that data. Is it possible to easily disable speculative loading alone in the Chrome source code, or is it too deeply intertwined with speculative parsing? I skimmed some of the relevant source and it seems like this should be doable.

I'd like to note a distinction between the goals of this API and the benefits being mentioned. Preload definitely benefits the speed of typical websites, and 'no-preload' even with a speed decrease still infers privacy benefits to the end-user in the third party JS library use-case.

yoavweiss commented 4 years ago

True, it would be nice to see that data. Is it possible to easily disable speculative loading alone in the Chrome source code, or is it too deeply intertwined with speculative parsing? I skimmed some of the relevant source and it seems like this should be doable.

One could create a custom Chromium build which bails early on HTMLPreloadScanner::Scan to test your hypothesis.

'no-preload' even with a speed decrease still infers privacy benefits to the end-user in the third party JS library use-case.

I believe the behavior you're after is the one implemented in Chromium when markup based meta CSP is present. (done with the same tradeoffs in mind)

eligrey commented 4 years ago

I believe the behavior you're after is the one implemented in Chromium when markup based meta CSP is present. (done with the same tradeoffs in mind)

I tried triggering this code path with a lax in-markup meta CSP to no avail. This was in combination with a JS library that also (synchronously) emits a generated strict meta CSP.

eligrey commented 4 years ago

I'll look into getting some benchmarks later. I might not have figures ready for the F2F this thursday though.

I've also changed the proposal text to state "[…] it does not always benefit […]" instead of "[…] it does not benefit […]"

yoavweiss commented 4 years ago

I tried triggering this code path with a lax in-markup meta CSP to no avail. This was in combination with a JS library that also (synchronously) emits a generated strict meta CSP.

Seems like this works in some cases, but not others sigh I'll file a crbug to figure this out

yoavweiss commented 4 years ago

Digging further, it seems like Chromium is doing the right thing, and stalling the preloads until the HTML-based meta CSP is processed, but doesn't stop the preload scanner altogether, so it's not something you could use here.