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
Link to entry on the feature dashboard
https://www.chromestatus.com/features/5718547946799104
Requesting approval to ship?
No
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?
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
Link to entry on the feature dashboard
https://www.chromestatus.com/features/5718547946799104
Requesting approval to ship?
No
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.
--
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.
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?
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
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.
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/22That 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