Intent to Implement: Blocking the load of cross-origin, parser-blocking scripts inserted via document.write in the main frame

5.582 kali dilihat
Langsung ke pesan pertama yang belum dibaca

Shivani Sharma

belum dibaca,
2 Jun 2016, 10.03.2502/06/16
kepadablink-dev

Intent to Implement: Blocking the load of cross-origin, parser-blocking scripts inserted via document.write in the main frame


Contact emails

shiva...@chromium.org, bmcq...@chromium.org,  jka...@chromium.org, kenji...@chromium.org


Spec

The Spec change is being worked on and will be discussed in the following issue:

https://github.com/WICG/interventions/issues/17


Summary

For users on slow connections such as 2G, the performance penalty from third-party scripts loaded via document.write is often so severe as to delay display of main page content for tens of seconds. This feature will block the load of cross-origin, parser-blocking scripts inserted via document.write in case it cannot return the requested script from the cache, for users on a slow connection. The feature will only be applicable to such scripts in the main frame.


Motivation

Historically, third party content such as ads and analytics used document.write to load script resources. Over the past five+ years, non-blocking alternatives, such as async scripts, have become available. Today, nearly all third party snippets support and recommend asynchronous loading. Despite widespread support for asynchronous loading, roughly 10-15% of page loads use document.write to load third party script resources in a way that harms performance.

The expected impact on the web is to steer the ecosystem to a place where third party content loads and runs without interfering with the rest of the content on the page by using the asynchronous alternatives as mentioned above.


Related Documents


Metrics

Blocking the load of third-party scripts inserted via document.write yields dramatic improvements in page load performance for affected pages, reducing time to meaningful paint by up to 30 seconds (example 1, 2). A field trial to evaluate the impact of this feature is currently ongoing on Canary and Dev.  While we intend to only enable this intervention for users on slow connections on Beta and Stable channels, we have enabled this intervention for all Dev and Canary users since May 17, 2016 and May 11, 2016 respectively.

Summary of finch results over 7 days from M53 Canary (Windows) on pages that had a cross-origin, parser-blocking document.written script (which is approximately 15% of the total population size) is given below:


For the 15% of affected pages, Parse Start to First Contentful Paint Duration improved by the following percentages (statistically significant):

Mean: 12%

50th percentile: 10%

90th percentile: 14%


Parse Duration improved by the following percentages (statistically significant):

Mean: 27%

50th percentile: 29%

90th percentile: 30%

Note that out of these 15% of affected pages, some will have the script in cache so the behaviour on those pages will be unaffected.

In addition, number of page reloads, which can be indicative of broken pages, are not statistically significantly different between control and experiment groups.


Canary population is predominantly users on fast connections, so the expected impact on users with slow 2G connections will likely be more in terms of absolute time saved. Running a trial on Canary and Dev allows us to verify that performance does improve and also help to discover broken web pages via bug reports or other feedback from canary and dev users. To date, we have not received any reports of pages broken by this feature. This is consistent with findings from lab tests, where we did not find any page that broke among a set of 200 pages from a random sample of navigations from Google search.


Interoperability and Compatibility Risk

Since most scripts inserted via document.write are for third party content such as ads and analytics, the likelihood of breaking the main content of the page as a result of blocking them is sufficiently less. Having said that, there are certain approaches we are taking to mitigate any such risks:

  • Blocking only cross-origin scripts: If a document.written script has the same domain as the main page, it will not be blocked.

  • Not blocking document.written scripts if it is a page reload.

  • Having UMA to track the count of reloads from pages that had a cross-origin, parser-blocking document.written script. From Finch trials over the last 10 days in Canary and Dev, there is no increase in this count.


As for the interoperability risk, we expect to ramp up the cross browser discussions as we gain confidence in user benefits and the necessary mitigation strategies, if any, through experimentation.


Ongoing technical constraints

None.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This feature will be enabled on Win, Mac, Linux, ChromeOS and Android, but we are still deciding whether it's appropriate to apply this intervention for WebView. Also, for the time being, since this feature will be limited to 2G users, it should trigger primarily on Android. In the future we may broaden coverage to all slow (2G-like) connections, at which point it may trigger on other platforms as well.


OWP launch tracking bug

https://crbug.com/599875


Link to entry on the feature dashboard

https://www.chromestatus.com/features/5718547946799104


Requesting approval to ship?

No




Rick Byers

belum dibaca,
2 Jun 2016, 10.35.2102/06/16
kepadaShivani Sharma, blink-dev, intervention-dev
This is really exciting!  Thanks for the great analysis of the risks from the field trial etc! 

You're running this as an intervention, and so will try to apply the guidance in https://bit.ly/user-agent-intervention, right?  +intervention-dev.

Obviously you've got a great focus on measurement.  What about reporting - what's the workflow for a developer to understand what's happening (especially since it may not reproduce in their lab where connections are fast)?

In terms of guidance, are we confident that there's ALWAYS a better alternative for parser-blocking cross-origin injected script scenarios?  I.e. if someone came up with a scenario they were relying on that really couldn't be solved otherwise, would we be likely to block shipping the intervention on extending the platform somehow to address their scenario otherwise?

A little more inline.

On Thu, Jun 2, 2016 at 10:03 AM, Shivani Sharma <shiva...@chromium.org> wrote:

Intent to Implement: Blocking the load of cross-origin, parser-blocking scripts inserted via document.write in the main frame


Contact emails

shiva...@chromium.org, bmcq...@chromium.org,  jka...@chromium.org, kenji...@chromium.org


Spec

The Spec change is being worked on and will be discussed in the following issue:

https://github.com/WICG/interventions/issues/17


Summary

For users on slow connections such as 2G, the performance penalty from third-party scripts loaded via document.write is often so severe as to delay display of main page content for tens of seconds. This feature will block the load of cross-origin, parser-blocking scripts inserted via document.write in case it cannot return the requested script from the cache, for users on a slow connection. The feature will only be applicable to such scripts in the main frame.


Motivation

Historically, third party content such as ads and analytics used document.write to load script resources. Over the past five+ years, non-blocking alternatives, such as async scripts, have become available. Today, nearly all third party snippets support and recommend asynchronous loading. Despite widespread support for asynchronous loading, roughly 10-15% of page loads use document.write to load third party script resources in a way that harms performance.

The expected impact on the web is to steer the ecosystem to a place where third party content loads and runs without interfering with the rest of the content on the page by using the asynchronous alternatives as mentioned above.


Related Documents


Metrics

Blocking the load of third-party scripts inserted via document.write yields dramatic improvements in page load performance for affected pages, reducing time to meaningful paint by up to 30 seconds (example 1, 2). A field trial to evaluate the impact of this feature is currently ongoing on Canary and Dev.  While we intend to only enable this intervention for users on slow connections on Beta and Stable channels, we have enabled this intervention for all Dev and Canary users since May 17, 2016 and May 11, 2016 respectively.

Summary of finch results over 7 days from M53 Canary (Windows) on pages that had a cross-origin, parser-blocking document.written script (which is approximately 15% of the total population size) is given below:


For the 15% of affected pages, Parse Start to First Contentful Paint Duration improved by the following percentages (statistically significant):

Mean: 12%

50th percentile: 10%

90th percentile: 14%


Do you have enough data to look at 99th percentile?  In our work on touch performance we believe it's really improving 99th that matters most (and where we see the most opportunity for interventions that provide a great user experience vs. platform predictability tradeoff).

Parse Duration improved by the following percentages (statistically significant):

Mean: 27%

50th percentile: 29%

90th percentile: 30%

Note that out of these 15% of affected pages, some will have the script in cache so the behaviour on those pages will be unaffected.

In addition, number of page reloads, which can be indicative of broken pages, are not statistically significantly different between control and experiment groups.


Canary population is predominantly users on fast connections, so the expected impact on users with slow 2G connections will likely be more in terms of absolute time saved. Running a trial on Canary and Dev allows us to verify that performance does improve and also help to discover broken web pages via bug reports or other feedback from canary and dev users. To date, we have not received any reports of pages broken by this feature. This is consistent with findings from lab tests, where we did not find any page that broke among a set of 200 pages from a random sample of navigations from Google search.


Interoperability and Compatibility Risk

Since most scripts inserted via document.write are for third party content such as ads and analytics, the likelihood of breaking the main content of the page as a result of blocking them is sufficiently less. Having said that, there are certain approaches we are taking to mitigate any such risks:

  • Blocking only cross-origin scripts: If a document.written script has the same domain as the main page, it will not be blocked.

  • Not blocking document.written scripts if it is a page reload.

  • Having UMA to track the count of reloads from pages that had a cross-origin, parser-blocking document.written script. From Finch trials over the last 10 days in Canary and Dev, there is no increase in this count.


Oooh, this is an interesting technique.   On the one hand it's a little confusing to have the page behave differently on reload, but on the other hand it's probably a great mitigation in practice.  I'll be interested to hear how well you feel this ends up working for you.  It maybe worth applying this approach to other (even all?) interventions. 

As for the interoperability risk, we expect to ramp up the cross browser discussions as we gain confidence in user benefits and the necessary mitigation strategies, if any, through experimentation.


Yep, as expected for interventions we should focus on learning via Chrome (and minimizing compat risk) before worrying too much about interop risk (filing the WICG interventions issue and participating in any discussions there is good enough for now).

Ongoing technical constraints

None.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This feature will be enabled on Win, Mac, Linux, ChromeOS and Android, but we are still deciding whether it's appropriate to apply this intervention for WebView. Also, for the time being, since this feature will be limited to 2G users, it should trigger primarily on Android. In the future we may broaden coverage to all slow (2G-like) connections, at which point it may trigger on other platforms as well.


Will there be / is there already a flag users can use to experiment with forcing this intervention to be enabled regardless of connection speed?

Shivani Sharma

belum dibaca,
2 Jun 2016, 13.43.1502/06/16
kepadaRick Byers, Shivani Sharma, blink-dev, intervention-dev
Thanks for the feedback. Responses inline.

On Thu, Jun 2, 2016 at 10:34 AM, Rick Byers <rby...@chromium.org> wrote:
This is really exciting!  Thanks for the great analysis of the risks from the field trial etc! 

You're running this as an intervention, and so will try to apply the guidance in https://bit.ly/user-agent-intervention, right?  +intervention-dev.
>> That's right. 

Obviously you've got a great focus on measurement.  What about reporting - what's the workflow for a developer to understand what's happening (especially since it may not reproduce in their lab where connections are fast)?
>> For reporting, the plan is to reach out to web developers via notifications in Chrome Developer Tools for pages that load parser-blocking scripts via document.write and encourage developers to migrate from sync to async loading. 

In terms of guidance, are we confident that there's ALWAYS a better alternative for parser-blocking cross-origin injected script scenarios?  I.e. if someone came up with a scenario they were relying on that really couldn't be solved otherwise, would we be likely to block shipping the intervention on extending the platform somehow to address their scenario otherwise?
>> We're not aware of scenarios in which one couldn't replace a parser-blocking cross-origin document.written script with async since third-party ad and analytics providers have moved to async, but if such a scenario were to arise we'd have to consider its impact before proceeding. 
>> Sure, the 99th percentile improvements for first contentful paint duration and parse duration are consistent with the other percentiles, at 12% and 27% respectively.

Parse Duration improved by the following percentages (statistically significant):

Mean: 27%

50th percentile: 29%

90th percentile: 30%

Note that out of these 15% of affected pages, some will have the script in cache so the behaviour on those pages will be unaffected.

In addition, number of page reloads, which can be indicative of broken pages, are not statistically significantly different between control and experiment groups.


Canary population is predominantly users on fast connections, so the expected impact on users with slow 2G connections will likely be more in terms of absolute time saved. Running a trial on Canary and Dev allows us to verify that performance does improve and also help to discover broken web pages via bug reports or other feedback from canary and dev users. To date, we have not received any reports of pages broken by this feature. This is consistent with findings from lab tests, where we did not find any page that broke among a set of 200 pages from a random sample of navigations from Google search.


Interoperability and Compatibility Risk

Since most scripts inserted via document.write are for third party content such as ads and analytics, the likelihood of breaking the main content of the page as a result of blocking them is sufficiently less. Having said that, there are certain approaches we are taking to mitigate any such risks:

  • Blocking only cross-origin scripts: If a document.written script has the same domain as the main page, it will not be blocked.

  • Not blocking document.written scripts if it is a page reload.

  • Having UMA to track the count of reloads from pages that had a cross-origin, parser-blocking document.written script. From Finch trials over the last 10 days in Canary and Dev, there is no increase in this count.


Oooh, this is an interesting technique.   On the one hand it's a little confusing to have the page behave differently on reload, but on the other hand it's probably a great mitigation in practice.  I'll be interested to hear how well you feel this ends up working for you.  It maybe worth applying this approach to other (even all?) interventions. 

As for the interoperability risk, we expect to ramp up the cross browser discussions as we gain confidence in user benefits and the necessary mitigation strategies, if any, through experimentation.


Yep, as expected for interventions we should focus on learning via Chrome (and minimizing compat risk) before worrying too much about interop risk (filing the WICG interventions issue and participating in any discussions there is good enough for now).

Ongoing technical constraints

None.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This feature will be enabled on Win, Mac, Linux, ChromeOS and Android, but we are still deciding whether it's appropriate to apply this intervention for WebView. Also, for the time being, since this feature will be limited to 2G users, it should trigger primarily on Android. In the future we may broaden coverage to all slow (2G-like) connections, at which point it may trigger on other platforms as well.


Will there be / is there already a flag users can use to experiment with forcing this intervention to be enabled regardless of connection speed?
>> Yes, the flag is "Block scripts loaded via document.write"
 

OWP launch tracking bug

https://crbug.com/599875


Link to entry on the feature dashboard

https://www.chromestatus.com/features/5718547946799104


Requesting approval to ship?

No








--
Shivani

Rick Byers

belum dibaca,
2 Jun 2016, 16.37.0902/06/16
kepadaShivani Sharma, Shivani Sharma, blink-dev, intervention-dev
Perfect, thank you!

Aw shucks.  I thought that we might see (as we have with touch latency) that the impact at the 99th percentile is much larger :-).  Oh well, still clearly worth investing in.

Kenji Baheux

belum dibaca,
2 Jun 2016, 20.33.3202/06/16
kepadaRick Byers, Shivani Sharma, Shivani Sharma, blink-dev, intervention-dev


Obviously you've got a great focus on measurement.  What about reporting - what's the workflow for a developer to understand what's happening (especially since it may not reproduce in their lab where connections are fast)?
>> For reporting, the plan is to reach out to web developers via notifications in Chrome Developer Tools for pages that load parser-blocking scripts via document.write and encourage developers to migrate from sync to async loading. 

We've been reaching out to various stakeholders to gather feedback on the intervention and determine if there truly are use cases with no alternative to doc.written scripts.

One piece of feedback we got: "there is a lot of value in having a way to know that an intervention will/might or did trigger". 

For instance, if an ad network knew in advance that doc.written scripts are at risk of an intervention, they would let the auction server know about this extra requirement.

I feel that this is not specific to this intervention though.
So, here is our current plan:
  1. confirm the potential of the intervention by running experiments on the stable channel
  2. in the meantime, revive the discussion of a generic mechanism to advertise and report interventions to let developers opt for different strategies on the fly and close the feedback loop.

 
--
You received this message because you are subscribed to the Google Groups "intervention-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intervention-d...@chromium.org.
To post to this group, send email to interven...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CAFUtAY8TC5RxrkpUMRTQG-1OTDA%2Bjvzsd6FD9yi0NCAksKQF8A%40mail.gmail.com.

Kentaro Hara

belum dibaca,
2 Jun 2016, 20.59.0002/06/16
kepadaKenji Baheux, Rick Byers, Shivani Sharma, Shivani Sharma, blink-dev, intervention-dev
I'm more than happy to see progress in this area!

(I've wanted to remove synchronous document.writes and did some experiments to automatically convert the scripts with async scripts etc a couple of years ago, but failed :)



--
Kentaro Hara, Tokyo, Japan

Philip Jägenstedt

belum dibaca,
3 Jun 2016, 04.16.3403/06/16
kepadaKentaro Hara, Kenji Baheux, Rick Byers, Shivani Sharma, Shivani Sharma, blink-dev, intervention-dev
Making the behavior depend on the contents of the cache and reloading sounds like it will make this rather hard to debug. Any ideas for helping developers ensure sure that their sites will work when this intervention kicks in?

Shivani Sharma

belum dibaca,
3 Jun 2016, 13.36.3903/06/16
kepadaPhilip Jägenstedt, Kentaro Hara, Kenji Baheux, Rick Byers, Shivani Sharma, blink-dev, intervention-dev
On Fri, Jun 3, 2016 at 4:16 AM, Philip Jägenstedt <foo...@chromium.org> wrote:
Making the behavior depend on the contents of the cache and reloading sounds like it will make this rather hard to debug. Any ideas for helping developers ensure sure that their sites will work when this intervention kicks in?
>>  As Kenji mentioned earlier, having a way for developers to opt for different strategies on the fly by having an interventions API should help them ensure that the site works. Here is the link to the interventions issue for this functionality: https://github.com/WICG/interventions/issues/22



--
Shivani

Philip Jägenstedt

belum dibaca,
3 Jun 2016, 16.30.1403/06/16
kepadaShivani Sharma, Kentaro Hara, Kenji Baheux, Rick Byers, Shivani Sharma, blink-dev, intervention-dev
On Fri, Jun 3, 2016 at 7:36 PM Shivani Sharma <shiva...@google.com> wrote:
On Fri, Jun 3, 2016 at 4:16 AM, Philip Jägenstedt <foo...@chromium.org> wrote:
Making the behavior depend on the contents of the cache and reloading sounds like it will make this rather hard to debug. Any ideas for helping developers ensure sure that their sites will work when this intervention kicks in?
>>  As Kenji mentioned earlier, having a way for developers to opt for different strategies on the fly by having an interventions API should help them ensure that the site works. Here is the link to the interventions issue for this functionality: https://github.com/WICG/interventions/issues/22

That sounds like a good idea, but how do we help developers discover what's going on in the first place, if they have a report of breakage from a user? Maybe emit a console message even when the intervention doesn't kick in, to say that it might under different conditions?

And, just to cover all possibilities, how do you judge the chances of just blocking these loads always, regardless of connection, cache state or reloads? That would at least be easy to explain, spec and get interoperably implemented. I understand that this experiment is intended to inform the standards discussion, but an idea of the most desirable end state would be nice.

Philip

Kenji Baheux

belum dibaca,
5 Jun 2016, 19.29.0205/06/16
kepadaPhilip Jägenstedt, Shivani Sharma, Kentaro Hara, Rick Byers, Shivani Sharma, blink-dev, intervention-dev

In parallel to this work, for users on reasonably fast connection, we are assessing an optimization that tries to extract and prefetch the document.written scripts, hopefully mitigating the performance bottleneck we observed.

The likelihood of extending the blocking to faster connections will depend, in part, with what we learn from this complementary approach.

In an ideal world,  we believe that document.written scripts should not exist: better alternatives exist. That being said, we are interested to hear about use cases for which a doc.written script is the only viable approach.

Shivani Sharma

belum dibaca,
6 Jun 2016, 10.32.3506/06/16
kepadaPhilip Jägenstedt, Kentaro Hara, Kenji Baheux, Rick Byers, Shivani Sharma, blink-dev, intervention-dev
On Fri, Jun 3, 2016 at 4:29 PM, Philip Jägenstedt <foo...@chromium.org> wrote:
On Fri, Jun 3, 2016 at 7:36 PM Shivani Sharma <shiva...@google.com> wrote:
On Fri, Jun 3, 2016 at 4:16 AM, Philip Jägenstedt <foo...@chromium.org> wrote:
Making the behavior depend on the contents of the cache and reloading sounds like it will make this rather hard to debug. Any ideas for helping developers ensure sure that their sites will work when this intervention kicks in?
>>  As Kenji mentioned earlier, having a way for developers to opt for different strategies on the fly by having an interventions API should help them ensure that the site works. Here is the link to the interventions issue for this functionality: https://github.com/WICG/interventions/issues/22

That sounds like a good idea, but how do we help developers discover what's going on in the first place, if they have a report of breakage from a user? Maybe emit a console message even when the intervention doesn't kick in, to say that it might under different conditions?
 
>> If the developer receives a report of breakage from a user, on reproducing the page load with chrome developer tools, dev tools should be able to point her to a potentially blocking document.written script, even if it did not block in that execution. Emitting a console message sounds like a good idea too.

And, just to cover all possibilities, how do you judge the chances of just blocking these loads always, regardless of connection, cache state or reloads? That would at least be easy to explain, spec and get interoperably implemented. I understand that this experiment is intended to inform the standards discussion, but an idea of the most desirable end state would be nice.
 
>> On faster connections, we are approaching the document.written scripts issue with the prefetching optimization (See Kenji's response) and expanding the blocking intervention to all connections will in part depend on the results from that experiment. Regarding reloads, since its a risk mitigating technique, I expect it to be there for some time at least and not blocking cached resources seems more in-line with user expectations. I agree its not easy to explain conditional blocking but the message for the developers here is to stay away/move away from using document.written scripts as they might risk blocking them in some scenarios. 

Philip



--
Shivani

andrew.s...@gmail.com

belum dibaca,
8 Sep 2016, 09.03.3808/09/16
kepadablink-dev
Older sites that were built with the scriptaculous lib would break due to this change as it used to load components in this way. 

eri...@gmail.com

belum dibaca,
12 Sep 2016, 16.41.0712/09/16
kepadablink-dev
When this hits Stable, will the console error change from a warning to a full error? Will it throw an error that can be caught by page level javascript error handlers? 
It would be nice to give pages insight into when this sort of thing is happening - especially in the case of third party ad or tracking code, it can be hard to stay on top of changes going on. 


i...@biancashouse.com

belum dibaca,
7 Okt 2016, 21.31.2707/10/16
kepadablink-dev
I am developing a GWT app that actually parses all the css and js includes of the html and fetched those resources, replacing the urls with data urls.
It would be nice if this blocking feature could be easily overriden by the user (say via Chrome settings).
Balas ke semua
Balas ke penulis
Teruskan
0 pesan baru