For users on very slow connections, block document.written scripts #17

Open
KenjiBaheux opened this Issue Apr 22, 2016 · 63 comments

Comments

Projects
None yet
@KenjiBaheux
Collaborator

KenjiBaheux commented Apr 22, 2016

For users on high latency connections, parser-blocking scripts loaded via document.write cause significant delays in user perceived page load latency.

Most scripts inserted via document.write are for third party content. A quick survey of the third parties suggests that async solutions are commonly offered. Given how bad the user experience can get for users on slow connections, it's quite likely that a large fraction of page visits never succeeds. The hope is that these newly rescued page views would incentivize publishers to adopt async solutions.

Chrome is exploring the following intervention:

  • for users on slow connections, block network requests for document.written scripts
  • design doc
  • crbug
@shivanigithub

This comment has been minimized.

Show comment
Hide comment
@shivanigithub

shivanigithub May 27, 2016

Possible Spec edits:
The "Note" in 4.12.1 mentions about scripts inserted using document.write in https://html.spec.whatwg.org/multipage/scripting.html#the-script-element:
"When inserted using the document.write() method, script elements execute (typically blocking further script execution or HTML parsing), but when inserted using innerHTML and outerHTML attributes, they do not execute at all."
We can add to this saying:
"The user agent may elect not to load synchronously loaded script elements inserted using document.write e.g. document.write('<scr' + 'ipt src="' + src + '" ></scr' + 'ipt>'). This is because such usage can cause significant delays in user perceived page load latency."

And also add similar statement in the Warning section in https://html.spec.whatwg.org/multipage/webappapis.html#document.write()

Possible Spec edits:
The "Note" in 4.12.1 mentions about scripts inserted using document.write in https://html.spec.whatwg.org/multipage/scripting.html#the-script-element:
"When inserted using the document.write() method, script elements execute (typically blocking further script execution or HTML parsing), but when inserted using innerHTML and outerHTML attributes, they do not execute at all."
We can add to this saying:
"The user agent may elect not to load synchronously loaded script elements inserted using document.write e.g. document.write('<scr' + 'ipt src="' + src + '" ></scr' + 'ipt>'). This is because such usage can cause significant delays in user perceived page load latency."

And also add similar statement in the Warning section in https://html.spec.whatwg.org/multipage/webappapis.html#document.write()

@shivanigithub

This comment has been minimized.

Show comment
Hide comment
@shivanigithub

shivanigithub May 27, 2016

Summarizing mail thread discussing the spec changes here:

As per feedback from ojan@ and domenic@ on the process of spec change:
"In another thread, Domenic suggested that we not add a diff to the interventions repo. Instead we can do a pull request to the HTML spec at the WHATWG and link to it from the issue in the interventions repo."

Summarizing mail thread discussing the spec changes here:

As per feedback from ojan@ and domenic@ on the process of spec change:
"In another thread, Domenic suggested that we not add a diff to the interventions repo. Instead we can do a pull request to the HTML spec at the WHATWG and link to it from the issue in the interventions repo."

@toddreifsteck

This comment has been minimized.

Show comment
Hide comment
@toddreifsteck

toddreifsteck May 27, 2016

Per above, I've opened the linked issue on W3C HTML5 spec.

Per above, I've opened the linked issue on W3C HTML5 spec.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic May 31, 2016

Per above, I've opened the linked issue on W3C HTML5 spec.

Wrong repo :). We were talking about a pull request to https://github.com/whatwg/html, which is what is implemented in browsers.

Possible Spec edits:

It's important to note include normative requirements (even "may"s) inside non-normative notes. Instead, we need to work through the normative algorithms.

Let's figure out instead how innerHTML normatively prevents script execution. It turns out it's done in the HTML parser itself. See e.g. https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inhead, where "A start tag whose tag name is "script"" step 4 says

If the parser was originally created for the HTML fragment parsing algorithm, then mark the script element as "already started". (fragment case)

(Note that "in body" delegates to "in head" for script, so this is the place to look.)

To fix this, your PR should probably just add an extra step that's very similar: something like

If the parser was invoked via the document.write() method, then optionally mark the script element as "already started". (For example, the user agent may wish to disallow third-party scripts inserted via document.write() under slow network conditions, or when page loading time is already high.)

I'm happy to write this PR if you'd prefer, although we're always happy to have more contributors to HTML. Instructions at https://github.com/whatwg/html#pull-requests

domenic commented May 31, 2016

Per above, I've opened the linked issue on W3C HTML5 spec.

Wrong repo :). We were talking about a pull request to https://github.com/whatwg/html, which is what is implemented in browsers.

Possible Spec edits:

It's important to note include normative requirements (even "may"s) inside non-normative notes. Instead, we need to work through the normative algorithms.

Let's figure out instead how innerHTML normatively prevents script execution. It turns out it's done in the HTML parser itself. See e.g. https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inhead, where "A start tag whose tag name is "script"" step 4 says

If the parser was originally created for the HTML fragment parsing algorithm, then mark the script element as "already started". (fragment case)

(Note that "in body" delegates to "in head" for script, so this is the place to look.)

To fix this, your PR should probably just add an extra step that's very similar: something like

If the parser was invoked via the document.write() method, then optionally mark the script element as "already started". (For example, the user agent may wish to disallow third-party scripts inserted via document.write() under slow network conditions, or when page loading time is already high.)

I'm happy to write this PR if you'd prefer, although we're always happy to have more contributors to HTML. Instructions at https://github.com/whatwg/html#pull-requests

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic May 31, 2016

Oh, but of course we should also update the note you found, too! My suggestion for how to do that would be to give an id to the new <li> with that step, and then insert the word "usually" before "execute" and have the "usually" link to that <li>.

domenic commented May 31, 2016

Oh, but of course we should also update the note you found, too! My suggestion for how to do that would be to give an id to the new <li> with that step, and then insert the word "usually" before "execute" and have the "usually" link to that <li>.

@shivanigithub

This comment has been minimized.

Show comment
Hide comment
@shivanigithub

shivanigithub Jun 7, 2016

Thanks for the feedback , Domenic.
It would be great if you write this PR. Thanks for offering.

Thanks for the feedback , Domenic.
It would be great if you write this PR. Thanks for offering.

domenic added a commit to whatwg/html that referenced this issue Jun 7, 2016

Allow not executing scripts inserted by document.write()
This allows user agents to experiment with better heuristics for not executing such scripts, as per WICG/interventions#17.
@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jun 7, 2016

OK! I wrote up the pull request at whatwg/html#1400.

domenic commented Jun 7, 2016

OK! I wrote up the pull request at whatwg/html#1400.

@shivanigithub

This comment has been minimized.

Show comment
Hide comment
@shivanigithub

shivanigithub Jun 7, 2016

Great, thanks!

Great, thanks!

@KenjiBaheux

This comment has been minimized.

Show comment
Hide comment
@KenjiBaheux

KenjiBaheux Aug 9, 2016

Collaborator

Let me document the current behavior of the intervention and its associated feedback loops in Chrome.

Intervention

Chrome will block the load of document.written scripts when the following conditions are met:

Script related criteria

  • Top level document. The blocking of scripts is restricted to the top level document (in other words, the intervention does not apply to document.written scripts within iframes)
  • Parser-blocking. Scripts that are parser-blocking are prohibitively expensive. Note: since asynchronous scripts are not parser blocking, the intervention does not apply to these scripts.
  • Cross site (i.e. hosts with different eTLD+1). To mitigate breakage of key functionality, the intervention only targets cross site scripts (i.e. scripts hosted on js.example.com will continue to work when inserted via document.write on www.example.com).
  • Browser HTTP cache miss. The blocking of scripts only applies in the case of a browser HTTP cache miss. If the document.written script is already available in the browser HTTP cache, it is allowed to execute, since there is no network delay incurred in this case.

Circumstances

  • Slow connections. Since the performance penalty of these scripts leads to a worst case page load experience in slow connections, we intend to block scripts only if all the above conditions are true and if the connection is slow. Initially, the change will be restricted to 2G. In the future, the change might be extended to other users on slow connections, such as slow 3G or slow WiFi.
  • Not a reload. To further mitigate the possibility of breaking user functionality, Chrome will not intervene if the user triggered a reload.

Browser HTTP cache hit case

When the script needed by the document.write statement is found in the browser HTTP cache, Chrome will use it even if stale, up to a lifetime of 1 year. To mitigate version skew issues, Chrome might queue a low priority asynchronous request in order to update stale assets.

Feedback loops

In order to make the intervention actionable for developers, we will offer the following feedback loops.

Warning in devtools

Since Chrome M53, Devtools is issuing warnings for potentially problematic document.write statements. The warning is issued regardless of the connectivity.

Example:
(index):34 A Parser-blocking, cross-origin script, http://www.example.org/a.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity.

Intervention HTTP header (strawman)

When a script inserted via document.write has been blocked, Chrome will send:

Intervention: <https://shorturl/relevant/spec>

When a script inserted via document.write is found and could be blocked in different circumstances, Chrome might send:

Intervention: <https://shorturl/relevant/spec>; level="warning"

The intervention header will be sent as part of the GET request for the script (asynchronously in case of an actual intervention).

Updates

10/25/2016: fix incorrect usage of the term "cross origin" when we meant "cross site (i.e. hosts with different eTLD+1)".

Collaborator

KenjiBaheux commented Aug 9, 2016

Let me document the current behavior of the intervention and its associated feedback loops in Chrome.

Intervention

Chrome will block the load of document.written scripts when the following conditions are met:

Script related criteria

  • Top level document. The blocking of scripts is restricted to the top level document (in other words, the intervention does not apply to document.written scripts within iframes)
  • Parser-blocking. Scripts that are parser-blocking are prohibitively expensive. Note: since asynchronous scripts are not parser blocking, the intervention does not apply to these scripts.
  • Cross site (i.e. hosts with different eTLD+1). To mitigate breakage of key functionality, the intervention only targets cross site scripts (i.e. scripts hosted on js.example.com will continue to work when inserted via document.write on www.example.com).
  • Browser HTTP cache miss. The blocking of scripts only applies in the case of a browser HTTP cache miss. If the document.written script is already available in the browser HTTP cache, it is allowed to execute, since there is no network delay incurred in this case.

Circumstances

  • Slow connections. Since the performance penalty of these scripts leads to a worst case page load experience in slow connections, we intend to block scripts only if all the above conditions are true and if the connection is slow. Initially, the change will be restricted to 2G. In the future, the change might be extended to other users on slow connections, such as slow 3G or slow WiFi.
  • Not a reload. To further mitigate the possibility of breaking user functionality, Chrome will not intervene if the user triggered a reload.

Browser HTTP cache hit case

When the script needed by the document.write statement is found in the browser HTTP cache, Chrome will use it even if stale, up to a lifetime of 1 year. To mitigate version skew issues, Chrome might queue a low priority asynchronous request in order to update stale assets.

Feedback loops

In order to make the intervention actionable for developers, we will offer the following feedback loops.

Warning in devtools

Since Chrome M53, Devtools is issuing warnings for potentially problematic document.write statements. The warning is issued regardless of the connectivity.

Example:
(index):34 A Parser-blocking, cross-origin script, http://www.example.org/a.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity.

Intervention HTTP header (strawman)

When a script inserted via document.write has been blocked, Chrome will send:

Intervention: <https://shorturl/relevant/spec>

When a script inserted via document.write is found and could be blocked in different circumstances, Chrome might send:

Intervention: <https://shorturl/relevant/spec>; level="warning"

The intervention header will be sent as part of the GET request for the script (asynchronously in case of an actual intervention).

Updates

10/25/2016: fix incorrect usage of the term "cross origin" when we meant "cross site (i.e. hosts with different eTLD+1)".

zcorpan added a commit to whatwg/html that referenced this issue Sep 1, 2016

Allow not executing scripts inserted by document.write()
This allows user agents to experiment with better heuristics for not executing such scripts, as per WICG/interventions#17.
@matthewp

This comment has been minimized.

Show comment
Hide comment
@matthewp

matthewp Sep 7, 2016

I think this is assuming that document.write() is only used for additive third party scripts like ad networks but one common use case of document.write is to fallback to a local script when a CDN fails. You can see an example of this from a very popular starter kit. This pattern has existed as far back as CDNs have been around and is probably encoded in a large number of websites.

matthewp commented Sep 7, 2016

I think this is assuming that document.write() is only used for additive third party scripts like ad networks but one common use case of document.write is to fallback to a local script when a CDN fails. You can see an example of this from a very popular starter kit. This pattern has existed as far back as CDNs have been around and is probably encoded in a large number of websites.

@PaulKinlan

This comment has been minimized.

Show comment
Hide comment
@PaulKinlan

PaulKinlan Sep 7, 2016

In your specific scenario this intervention not trigger because your fallback script is not cross-origin.

In your specific scenario this intervention not trigger because your fallback script is not cross-origin.

@matthewp

This comment has been minimized.

Show comment
Hide comment
@matthewp

matthewp Sep 7, 2016

That's only true in Chrome. My concern is that giving UAs permission to do this will cause sites to behave differently in some browsers and break in some browsers.

matthewp commented Sep 7, 2016

That's only true in Chrome. My concern is that giving UAs permission to do this will cause sites to behave differently in some browsers and break in some browsers.

@hexalys

This comment has been minimized.

Show comment
Hide comment
@hexalys

hexalys Sep 8, 2016

I object to blindly targeting cross-origin. It's too restrictive with potential to break some sites' core functionality. Including half a dozen of my own sites.

As I mentioned in a Tweet to @PaulKinlan I have been using cross-browser patterns such as:

document.write('<script src="/cdn/jquery/'+(!Object.defineProperty?'1.8.3' : ie<11|this.opera ? '1.11.1' : '2.2.4')+'min.js"><\/script>');

or with conditionals to load browser shims such as:

!Object.create && document.write('<script src="/cdn/lib/es5-shim.min.js"><\/script>');

As described, prohibiting cross-origin scripts from CDNs break the above use cases. In addition, given the above jQuery version method, I use jQuery fallbacks from CDNJS to Google's API. Both of them via document.write().

Some additional points:

  1. This is the only way to conditionally load synchronous scripts from a CDN, for good reasons.
  2. The described aim of this intervention is "reducing the impact of document.written scripts on user perceived page load latency". AFAICT that script usage early in the <head> makes no visible impact on performance.
  3. Browser aren't likely able to properly evaluate such document.write(s) in the preload scanner. One of the initial motives for the crbug. And in this case, attempts in preloading those would defeat the very purpose of using them conditionally for polyfills with feature detection conditions.

I am all for preventing poorly implemented document.write "for third party content such as ads and trackers" that inject late content in the page. But we need a reasonable compromise here.

As mitigation, here an option to consider, which i'd be fine with:

Allow cross-origin scripts only when loaded in the <head>.
(easy and clear spec with no significant impact on performance).

hexalys commented Sep 8, 2016

I object to blindly targeting cross-origin. It's too restrictive with potential to break some sites' core functionality. Including half a dozen of my own sites.

As I mentioned in a Tweet to @PaulKinlan I have been using cross-browser patterns such as:

document.write('<script src="/cdn/jquery/'+(!Object.defineProperty?'1.8.3' : ie<11|this.opera ? '1.11.1' : '2.2.4')+'min.js"><\/script>');

or with conditionals to load browser shims such as:

!Object.create && document.write('<script src="/cdn/lib/es5-shim.min.js"><\/script>');

As described, prohibiting cross-origin scripts from CDNs break the above use cases. In addition, given the above jQuery version method, I use jQuery fallbacks from CDNJS to Google's API. Both of them via document.write().

Some additional points:

  1. This is the only way to conditionally load synchronous scripts from a CDN, for good reasons.
  2. The described aim of this intervention is "reducing the impact of document.written scripts on user perceived page load latency". AFAICT that script usage early in the <head> makes no visible impact on performance.
  3. Browser aren't likely able to properly evaluate such document.write(s) in the preload scanner. One of the initial motives for the crbug. And in this case, attempts in preloading those would defeat the very purpose of using them conditionally for polyfills with feature detection conditions.

I am all for preventing poorly implemented document.write "for third party content such as ads and trackers" that inject late content in the page. But we need a reasonable compromise here.

As mitigation, here an option to consider, which i'd be fine with:

Allow cross-origin scripts only when loaded in the <head>.
(easy and clear spec with no significant impact on performance).

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Sep 8, 2016

Why do you believe that script usage (actually, it's document.write usage) early in the head makes no visible impact on performance? It janks the page just as bad as document.write anywhere else (it stops further parsing of the page, much less any rendering and layout, until the script is downloaded!). <head> is not a magical no-jank container.

domenic commented Sep 8, 2016

Why do you believe that script usage (actually, it's document.write usage) early in the head makes no visible impact on performance? It janks the page just as bad as document.write anywhere else (it stops further parsing of the page, much less any rendering and layout, until the script is downloaded!). <head> is not a magical no-jank container.

@bzbarsky

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Sep 8, 2016

it stops further parsing of the page

For what it's worth, this may not be true in all UAs. It needs to stop observable DOM construction, and it needs to act as if parsing had been stopped, but you can in fact parse ahead speculatively if you want, and some UAs do that.

bzbarsky commented Sep 8, 2016

it stops further parsing of the page

For what it's worth, this may not be true in all UAs. It needs to stop observable DOM construction, and it needs to act as if parsing had been stopped, but you can in fact parse ahead speculatively if you want, and some UAs do that.

@ojanvafai

This comment has been minimized.

Show comment
Hide comment
@ojanvafai

ojanvafai Sep 8, 2016

Member

The combination of DOM construction blocking and speculative parsing is actually the problem here. The speculative parsing will load resources that are needed later in the page, delaying the load of the doc.written script. On a 2G connection, by the time you doc.write the script, the network connection is already flooded loading other resources, even if it's in the head.

You can't just reprioritize the resource loads at that point because it's the upstream network bandwidth that's flooded.

We were consistently seeing page load improvements of 10-30 seconds on many pages on 2G.

@hexalys do you have a page you could point us to that doesn't see a significant improvement on a 2G connection? I'd like to understand it better. Maybe we should be doing something more nuanced.

Member

ojanvafai commented Sep 8, 2016

The combination of DOM construction blocking and speculative parsing is actually the problem here. The speculative parsing will load resources that are needed later in the page, delaying the load of the doc.written script. On a 2G connection, by the time you doc.write the script, the network connection is already flooded loading other resources, even if it's in the head.

You can't just reprioritize the resource loads at that point because it's the upstream network bandwidth that's flooded.

We were consistently seeing page load improvements of 10-30 seconds on many pages on 2G.

@hexalys do you have a page you could point us to that doesn't see a significant improvement on a 2G connection? I'd like to understand it better. Maybe we should be doing something more nuanced.

@matthewp

This comment has been minimized.

Show comment
Hide comment
@matthewp

matthewp Sep 8, 2016

@ojanvafai A page might load quick, but load incorrectly if a needed script is ignored. If I write the entire page using jQuery and jQuery doesn't load because of this algorithm, the page is broken on such a connection.

matthewp commented Sep 8, 2016

@ojanvafai A page might load quick, but load incorrectly if a needed script is ignored. If I write the entire page using jQuery and jQuery doesn't load because of this algorithm, the page is broken on such a connection.

@hexalys

This comment has been minimized.

Show comment
Hide comment
@hexalys

hexalys Sep 9, 2016

Why do you believe that script usage (actually, it's document.write usage) early in the head makes no visible impact on performance?
@domenic

By tests and observation of network waterfalls in fairly all browsers. There is little to no timing penalty for the overall document in loading jQuery via document.write(). Compare those 2 tests as examples:

Test A : Nexus 7 - Chrome - 2G speed (using document.write jQuery).
Test B : Nexus 7 - Chrome - 2G speed (using normal sync jQuery).

The only difference is a very small negligible priority penalty of 10-20ms only for the script itself.

It janks the page just as bad as document.write anywhere else (it stops further parsing of the page, much less any rendering and layout, until the script is downloaded!). is not a magical no-jank container.
@domenic

It doesn't stop rendering any more than any other synchronous script. It's not that's it's a magical no-jank container. As an aside, I just assume that having it at the top where the body is not yet parsed has a more minimal impact with the effect document.write can have on the document. The main point here is that, it obviously loads those scripts much faster and it is the only proper way to use document.write() without penalty. In contrast, see how bad document.write is at the bottom on Exhibit C below.

Test C : Nexus 7 - Chrome - 2G speed (adding an ES6 shim using document.write at the bottom).

The impact on page load or 'Document Complete' there is minimal, as it is a small script that doesn't do anything else other than being parsed. It however clearly delays 'Render' by 1-2s and 'Interactive' by 4-5 seconds already. That is the kind of harmful practice everyone should be told not to use at all.

For what it's worth, this may not be true in all UAs. It needs to stop observable DOM construction, and it needs to act as if parsing had been stopped, but you can in fact parse ahead speculatively if you want, and some UAs do that.
@bzbarsky

Correct. That's true of Chrome since Chrome PLT Improvements Q1 2013. According to that document, even if a script blocks it may speculatively download images if the network is idle (i.e. a light head). The important thing here, is that document.write() does not block assets in the head from being preloaded. Images are low priority anyway and won't start if you are busy with quite a few script + css downloads.

The combination of DOM construction blocking and speculative parsing is actually the problem here. The speculative parsing will load resources that are needed later in the page, delaying the load of the doc.written script.
@ojanvafai

Indeed as shown on C. But it's only a performance problem past the <body>, depending on how many script resources or images you have in between, but definitely not when prioritized in the <head> as demonstrated.

You can't just reprioritize the resource loads at that point because it's the upstream network bandwidth that's flooded.

Agreed past </head>. That's the proper recommendation to extract from this and promote.
Ultimately I would have no issue with preventing document.write() in the <body> entirely, even for same origin scripts. But again, in the <head>. I don't see any harm at all.

We were consistently seeing page load improvements of 10-30 seconds on many pages on 2G.

I can see that with any bottom document.write(s), especially if those also modify the DOM themselves, or would do worse by loading additional assets. Those are really obvious performance killer and an anti-pattern.

I totally get document.write() isn't ideal. But that's the only way that job gets done, at little to no cost, without a recourse to a more modular approach which in itself usually require an additional script and a performance cost in itself. (which mostly makes sense for a web app centric page as opposed to the average web site).

Clearly document.write() is not an enemy of performance when carefully used, and for the right reason.

hexalys commented Sep 9, 2016

Why do you believe that script usage (actually, it's document.write usage) early in the head makes no visible impact on performance?
@domenic

By tests and observation of network waterfalls in fairly all browsers. There is little to no timing penalty for the overall document in loading jQuery via document.write(). Compare those 2 tests as examples:

Test A : Nexus 7 - Chrome - 2G speed (using document.write jQuery).
Test B : Nexus 7 - Chrome - 2G speed (using normal sync jQuery).

The only difference is a very small negligible priority penalty of 10-20ms only for the script itself.

It janks the page just as bad as document.write anywhere else (it stops further parsing of the page, much less any rendering and layout, until the script is downloaded!). is not a magical no-jank container.
@domenic

It doesn't stop rendering any more than any other synchronous script. It's not that's it's a magical no-jank container. As an aside, I just assume that having it at the top where the body is not yet parsed has a more minimal impact with the effect document.write can have on the document. The main point here is that, it obviously loads those scripts much faster and it is the only proper way to use document.write() without penalty. In contrast, see how bad document.write is at the bottom on Exhibit C below.

Test C : Nexus 7 - Chrome - 2G speed (adding an ES6 shim using document.write at the bottom).

The impact on page load or 'Document Complete' there is minimal, as it is a small script that doesn't do anything else other than being parsed. It however clearly delays 'Render' by 1-2s and 'Interactive' by 4-5 seconds already. That is the kind of harmful practice everyone should be told not to use at all.

For what it's worth, this may not be true in all UAs. It needs to stop observable DOM construction, and it needs to act as if parsing had been stopped, but you can in fact parse ahead speculatively if you want, and some UAs do that.
@bzbarsky

Correct. That's true of Chrome since Chrome PLT Improvements Q1 2013. According to that document, even if a script blocks it may speculatively download images if the network is idle (i.e. a light head). The important thing here, is that document.write() does not block assets in the head from being preloaded. Images are low priority anyway and won't start if you are busy with quite a few script + css downloads.

The combination of DOM construction blocking and speculative parsing is actually the problem here. The speculative parsing will load resources that are needed later in the page, delaying the load of the doc.written script.
@ojanvafai

Indeed as shown on C. But it's only a performance problem past the <body>, depending on how many script resources or images you have in between, but definitely not when prioritized in the <head> as demonstrated.

You can't just reprioritize the resource loads at that point because it's the upstream network bandwidth that's flooded.

Agreed past </head>. That's the proper recommendation to extract from this and promote.
Ultimately I would have no issue with preventing document.write() in the <body> entirely, even for same origin scripts. But again, in the <head>. I don't see any harm at all.

We were consistently seeing page load improvements of 10-30 seconds on many pages on 2G.

I can see that with any bottom document.write(s), especially if those also modify the DOM themselves, or would do worse by loading additional assets. Those are really obvious performance killer and an anti-pattern.

I totally get document.write() isn't ideal. But that's the only way that job gets done, at little to no cost, without a recourse to a more modular approach which in itself usually require an additional script and a performance cost in itself. (which mostly makes sense for a web app centric page as opposed to the average web site).

Clearly document.write() is not an enemy of performance when carefully used, and for the right reason.

@hexalys hexalys referenced this issue in Pomax/pomax.github.io Sep 9, 2016

Open

Using document.write #3

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Sep 10, 2016

Member

As anyone who follows blink intent threads knows, I'm very concerned about web compat (often arguing that risking breaking even 0.01% of page views is unacceptable). There's no doubt that this is going to break some content. But when evaluating the compat cost (even in isolation before considering the benefits) we have to consider that this fixes 10% of pages loads on 2G that are otherwise so slow the user gives up waiting before anything paints. So to even be at neutral compat impact this would have to break at least 10% of 2G page loads. The initial evidence suggests it's well below that threshold. So this may be a rare intervention where we get to BOTH improve the user experience on many pages AND increase the number of pages that load correctly!

Of course there's still a risk of some class of pages being harmed more then they're helped. I suggest we focus on collecting examples of real pages that are broken with little benefit to see if there are any patterns that can be used to tweak the discrimination of this heuristic.

Also, interventions are premised on the idea that developers who follow best practices will not be impacted by them. @hexalys describes some use cases that seem pretty reasonable to me. Perhaps there's some way we can allow those to work without loosing most of the benefit?

Member

RByers commented Sep 10, 2016

As anyone who follows blink intent threads knows, I'm very concerned about web compat (often arguing that risking breaking even 0.01% of page views is unacceptable). There's no doubt that this is going to break some content. But when evaluating the compat cost (even in isolation before considering the benefits) we have to consider that this fixes 10% of pages loads on 2G that are otherwise so slow the user gives up waiting before anything paints. So to even be at neutral compat impact this would have to break at least 10% of 2G page loads. The initial evidence suggests it's well below that threshold. So this may be a rare intervention where we get to BOTH improve the user experience on many pages AND increase the number of pages that load correctly!

Of course there's still a risk of some class of pages being harmed more then they're helped. I suggest we focus on collecting examples of real pages that are broken with little benefit to see if there are any patterns that can be used to tweak the discrimination of this heuristic.

Also, interventions are premised on the idea that developers who follow best practices will not be impacted by them. @hexalys describes some use cases that seem pretty reasonable to me. Perhaps there's some way we can allow those to work without loosing most of the benefit?

@FremyCompany

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Sep 10, 2016

I think it is ok for an inline script to use document.write; technically an inline script is nearly identical to having the script tag in the html source.

I think it is ok for an inline script to use document.write; technically an inline script is nearly identical to having the script tag in the html source.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Sep 10, 2016

Member

Interventions generally have an opt-out. If there are some legit use cases, should this get an opt-out too - at least for now? Eg. What if the script loaded was previously listed as a <link rel=preload> target? @hexalys would that be enough to address your use cases? That would address the issue @ojanvafai describes with the load order getting hurt, but could obviously make things worse if the resource is large and usually not needed.

Member

RByers commented Sep 10, 2016

Interventions generally have an opt-out. If there are some legit use cases, should this get an opt-out too - at least for now? Eg. What if the script loaded was previously listed as a <link rel=preload> target? @hexalys would that be enough to address your use cases? That would address the issue @ojanvafai describes with the load order getting hurt, but could obviously make things worse if the resource is large and usually not needed.

@michaelhood

This comment has been minimized.

Show comment
Hide comment
@michaelhood

michaelhood Sep 10, 2016

@RByers If we could expand that to a <link rel=preconnect>, it would cover my use cases: where the URI for the script tag is assembled dynamically at runtime (usually based on the host page's URL), but one of them is loaded on 100% of requests. Always from the same CDN domain, cross-origin.

@RByers If we could expand that to a <link rel=preconnect>, it would cover my use cases: where the URI for the script tag is assembled dynamically at runtime (usually based on the host page's URL), but one of them is loaded on 100% of requests. Always from the same CDN domain, cross-origin.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Sep 10, 2016

Member

I think it is ok for an inline script to use document.write; technically an inline script is nearly identical to having the script tag in the html source.

I'm not an expert here, but Ojan's argument above is that it's not - at least in Chrome. The script tag is exposed to the preload scanner (so can trigger loads early) while the doc.written script is not and so may block loading longer (especially due to all the later speculative resources that are now hogging the network).

Also the biggest problems come when one render-blocking script doc.writes another which doc.writes another and so on. As I understand it this can't happen with script tags, even when added via DOM APIs.

Member

RByers commented Sep 10, 2016

I think it is ok for an inline script to use document.write; technically an inline script is nearly identical to having the script tag in the html source.

I'm not an expert here, but Ojan's argument above is that it's not - at least in Chrome. The script tag is exposed to the preload scanner (so can trigger loads early) while the doc.written script is not and so may block loading longer (especially due to all the later speculative resources that are now hogging the network).

Also the biggest problems come when one render-blocking script doc.writes another which doc.writes another and so on. As I understand it this can't happen with script tags, even when added via DOM APIs.

@hexalys

This comment has been minimized.

Show comment
Hide comment
@hexalys

hexalys Sep 10, 2016

Eg. What if the script loaded was previously listed as a target? @hexalys would that be enough to address your use cases?
@RByers

You mean to opt out of the restriction? It would for the multi version jQuery load, yes. Or the link rel=preconnect like @michaelhood said. Which would cover the 2nd case and CDN domains broadly. That's a good opt-out idea, I could get along with.

Also, should you decide to preload document.write(s). It's no too hard to get around it for case 2. Which I already do. If you look at my source on this site. I have two custom methods for document.write(s) and async loads for both contexts.

So I technically load this:
!Object.create && document.write('<script src="/cdn/lib/es5-shim.min.js"><\/script>');
as:
!Object.create&&cd.ws('es5-shim/4.5.9/es5-shim.',_);
which the preloader would not interfere with. Which seems a reasonable workaround.

Also the biggest problems come when one render-blocking script doc.writes another which doc.writes another and so on. As I understand it this can't happen with script tags, even when added via DOM APIs.

Well you can load synchronous ajax with similar effects. Though Chrome already get a "Synchronous XMLHttpRequest on the main thread" deprecation console warning to deter the practice.

hexalys commented Sep 10, 2016

Eg. What if the script loaded was previously listed as a target? @hexalys would that be enough to address your use cases?
@RByers

You mean to opt out of the restriction? It would for the multi version jQuery load, yes. Or the link rel=preconnect like @michaelhood said. Which would cover the 2nd case and CDN domains broadly. That's a good opt-out idea, I could get along with.

Also, should you decide to preload document.write(s). It's no too hard to get around it for case 2. Which I already do. If you look at my source on this site. I have two custom methods for document.write(s) and async loads for both contexts.

So I technically load this:
!Object.create && document.write('<script src="/cdn/lib/es5-shim.min.js"><\/script>');
as:
!Object.create&&cd.ws('es5-shim/4.5.9/es5-shim.',_);
which the preloader would not interfere with. Which seems a reasonable workaround.

Also the biggest problems come when one render-blocking script doc.writes another which doc.writes another and so on. As I understand it this can't happen with script tags, even when added via DOM APIs.

Well you can load synchronous ajax with similar effects. Though Chrome already get a "Synchronous XMLHttpRequest on the main thread" deprecation console warning to deter the practice.

@hexalys

This comment has been minimized.

Show comment
Hide comment
@hexalys

hexalys Sep 10, 2016

Temporary opt-out aside, and in consideration for a long term gradual deprecation of document.write(). I think I'd be only fair and useful to offer "some kind" of synchronous behavior alternative for polyfills.

A possible idea would be re-utilizing the existing 'defer' attribute and behavior. Right now, for parser-inserted scripts; async takes precedence over defer. However since there is no specified behavior for parser-inserted scripts with a defer flag yet. We could fill this gap with the following approach:

if (!document.write && !window.es7function){
  var script = document.createElement('script');
  script.src = 'es7-shim.js';
  script.defer = true; //parser-inserted true defer take precedence over async behavior
  document.head.appendChild(script);
}

The example would load a shim in an async fashion, but with a 'defer' priority, and in order. That removes the document.write() method from the equation while allowing newly non-blocking conditional scripts. The sync part comes at interactive, after which they are required to execute before DOMContentLoaded.

hexalys commented Sep 10, 2016

Temporary opt-out aside, and in consideration for a long term gradual deprecation of document.write(). I think I'd be only fair and useful to offer "some kind" of synchronous behavior alternative for polyfills.

A possible idea would be re-utilizing the existing 'defer' attribute and behavior. Right now, for parser-inserted scripts; async takes precedence over defer. However since there is no specified behavior for parser-inserted scripts with a defer flag yet. We could fill this gap with the following approach:

if (!document.write && !window.es7function){
  var script = document.createElement('script');
  script.src = 'es7-shim.js';
  script.defer = true; //parser-inserted true defer take precedence over async behavior
  document.head.appendChild(script);
}

The example would load a shim in an async fashion, but with a 'defer' priority, and in order. That removes the document.write() method from the equation while allowing newly non-blocking conditional scripts. The sync part comes at interactive, after which they are required to execute before DOMContentLoaded.

@roblarsen

This comment has been minimized.

Show comment
Hide comment
@roblarsen

roblarsen Sep 13, 2016

I think this is assuming that document.write() is only used for additive third party scripts like ad networks but one common use case of document.write is to fallback to a local script when a CDN fails. You can see an example of this from a very popular starter kit. This pattern has existed as far back as CDNs have been around and is probably encoded in a large number of websites.

Thanks for the pointer @matthewp. We actually opened an issue to figure out what to do about this proposed change.

FWIW, based on how long that pattern has been in H5BP and how popular H5BP has been I imagine the number of sites that have inherited the pattern from us directly is probably pretty big.

That said...

In your specific scenario this intervention not trigger because your fallback script is not cross-origin.

@PaulKinlan that's good to hear.

One thing, as you can see in the linked H5BP issue, there was some confusion on my (and others who brought it to our attention) part about the scope of this change as the list of conditions in your blog post doesn't mention cross-origin as being one of the conditions. Adding that in (as it's mentioned in this very issue) would better serve the time-deprived bulleted list scanners in your audience.

Thanks!

I think this is assuming that document.write() is only used for additive third party scripts like ad networks but one common use case of document.write is to fallback to a local script when a CDN fails. You can see an example of this from a very popular starter kit. This pattern has existed as far back as CDNs have been around and is probably encoded in a large number of websites.

Thanks for the pointer @matthewp. We actually opened an issue to figure out what to do about this proposed change.

FWIW, based on how long that pattern has been in H5BP and how popular H5BP has been I imagine the number of sites that have inherited the pattern from us directly is probably pretty big.

That said...

In your specific scenario this intervention not trigger because your fallback script is not cross-origin.

@PaulKinlan that's good to hear.

One thing, as you can see in the linked H5BP issue, there was some confusion on my (and others who brought it to our attention) part about the scope of this change as the list of conditions in your blog post doesn't mention cross-origin as being one of the conditions. Adding that in (as it's mentioned in this very issue) would better serve the time-deprived bulleted list scanners in your audience.

Thanks!

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Oct 18, 2016

@KenjiBaheux can you give us a quick update on this intervention? Is it shipping in Chrome stable now? If so we should re-open discussions of merging whatwg/html#1400

domenic commented Oct 18, 2016

@KenjiBaheux can you give us a quick update on this intervention? Is it shipping in Chrome stable now? If so we should re-open discussions of merging whatwg/html#1400

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Oct 22, 2016

Member

This is in Chrome 55, so just recently Beta, stable early December.

Member

RByers commented Oct 22, 2016

This is in Chrome 55, so just recently Beta, stable early December.

@KenjiBaheux

This comment has been minimized.

Show comment
Hide comment
@KenjiBaheux

KenjiBaheux Oct 25, 2016

Collaborator

We are aiming at sending an intent to ship for Chrome 55.

I personally see our intent to ship process as a dialogue similar to a "letter of intent": it's a proposal for a course of action with a genuine interest in hearing all parties (e.g. share information about the benefits and risks, allow for additional information to be brought up, make an informed decision). Also, this intervention is definitely not trivial: we expect that we will learn a lot by trying and that we will have to refine what we have.

Regarding the Polyfills and CDN failures patterns, I would like to summarize the mitigations we currently have in place:

  • To minimize breaking user functionality, the intervention does not block same site (i.e. hosts with matching eTLD+1) scripts.
  • If the polyfills / CDN backups are hosted on a cross site host (i.e. different eTLD+1), the intervention slated for Chrome 55 will then trigger for users on 2G. We expect that these users will use the reload gesture to fix any significant breakage, in which case the intervention will not trigger. In addition, we are issuing async requests for the blocked resources which should mitigate breakage on subsequent navigations.
  • Finally, with regards to the use of a script blocking document.write statement for these use cases, we believe that there are better alternatives to consider. However, we understand that there might be hurdles in practice and would like to learn more about these pain points. This issue is probably a better place to discuss this specific topic.

Regarding the idea of "blessing" resources that have been requested earlier via link rel=preload: we've been hoping that this would be enough to avoid the intervention altogether but we are definitely open to hear how often this works in practice (e.g. one should be able to track the impact via the Intervention header).

I understand that for the CDN backup and polyfill use cases, rel=preload is not ideal (risk of superfluous requests) nor always practical (e.g. the sample with the dynamically determined version number). The question of allowing sub resources that have been warmed up via rel=preconnect is interesting. One factor would be the relative impact of preconnect on the overall fetch cost.

Updates

  • 10/25/2016: fixed incorrect usage of the term "cross origin / same origin" when we meant "cross site / same site (i.e. host with different/matching eTLD+1)".
Collaborator

KenjiBaheux commented Oct 25, 2016

We are aiming at sending an intent to ship for Chrome 55.

I personally see our intent to ship process as a dialogue similar to a "letter of intent": it's a proposal for a course of action with a genuine interest in hearing all parties (e.g. share information about the benefits and risks, allow for additional information to be brought up, make an informed decision). Also, this intervention is definitely not trivial: we expect that we will learn a lot by trying and that we will have to refine what we have.

Regarding the Polyfills and CDN failures patterns, I would like to summarize the mitigations we currently have in place:

  • To minimize breaking user functionality, the intervention does not block same site (i.e. hosts with matching eTLD+1) scripts.
  • If the polyfills / CDN backups are hosted on a cross site host (i.e. different eTLD+1), the intervention slated for Chrome 55 will then trigger for users on 2G. We expect that these users will use the reload gesture to fix any significant breakage, in which case the intervention will not trigger. In addition, we are issuing async requests for the blocked resources which should mitigate breakage on subsequent navigations.
  • Finally, with regards to the use of a script blocking document.write statement for these use cases, we believe that there are better alternatives to consider. However, we understand that there might be hurdles in practice and would like to learn more about these pain points. This issue is probably a better place to discuss this specific topic.

Regarding the idea of "blessing" resources that have been requested earlier via link rel=preload: we've been hoping that this would be enough to avoid the intervention altogether but we are definitely open to hear how often this works in practice (e.g. one should be able to track the impact via the Intervention header).

I understand that for the CDN backup and polyfill use cases, rel=preload is not ideal (risk of superfluous requests) nor always practical (e.g. the sample with the dynamically determined version number). The question of allowing sub resources that have been warmed up via rel=preconnect is interesting. One factor would be the relative impact of preconnect on the overall fetch cost.

Updates

  • 10/25/2016: fixed incorrect usage of the term "cross origin / same origin" when we meant "cross site / same site (i.e. host with different/matching eTLD+1)".
@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Oct 25, 2016

Thanks for the info @KenjiBaheux! Although...

same origin (in the eTLD+1 meaning)

This is pretty confusing; probably you mean "same site". "Same origin" has a specific definition that is definitely not eTLD+1.

domenic commented Oct 25, 2016

Thanks for the info @KenjiBaheux! Although...

same origin (in the eTLD+1 meaning)

This is pretty confusing; probably you mean "same site". "Same origin" has a specific definition that is definitely not eTLD+1.

@KenjiBaheux

This comment has been minimized.

Show comment
Hide comment
@KenjiBaheux

KenjiBaheux Oct 25, 2016

Collaborator

@domenic Apologies for using the wrong term.
I will try to fix all the existing documentation and upcoming communication.

I'm assuming that same site == same eTLD+1 is not necessarily a widely understood definition.
So, I'll probably write it as "same site (i.e. host with matching eTLD+1)", Let me know if this is better.

Collaborator

KenjiBaheux commented Oct 25, 2016

@domenic Apologies for using the wrong term.
I will try to fix all the existing documentation and upcoming communication.

I'm assuming that same site == same eTLD+1 is not necessarily a widely understood definition.
So, I'll probably write it as "same site (i.e. host with matching eTLD+1)", Let me know if this is better.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Oct 25, 2016

Sounds great to me :)

domenic commented Oct 25, 2016

Sounds great to me :)

@cramforce

This comment has been minimized.

Show comment
Hide comment
@cramforce

cramforce Oct 25, 2016

The IntersectionObserver spec calls it similar origin, which might be the
same thing.
https://html.spec.whatwg.org/multipage/browsers.html#unit-of-related-similar-origin-browsing-contexts

On Oct 24, 2016 7:40 PM, "Domenic Denicola" notifications@github.com
wrote:

Sounds great to me :)


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#17 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeTz0gIvVOIZUbiXJ7Ufqkc3pxVevKks5q3WwNgaJpZM4IN2lZ
.

The IntersectionObserver spec calls it similar origin, which might be the
same thing.
https://html.spec.whatwg.org/multipage/browsers.html#unit-of-related-similar-origin-browsing-contexts

On Oct 24, 2016 7:40 PM, "Domenic Denicola" notifications@github.com
wrote:

Sounds great to me :)


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#17 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeTz0gIvVOIZUbiXJ7Ufqkc3pxVevKks5q3WwNgaJpZM4IN2lZ
.

@KenjiBaheux

This comment has been minimized.

Show comment
Hide comment
@KenjiBaheux

KenjiBaheux Oct 25, 2016

Collaborator

Yes, we are aiming at a launch in Chrome 55 (for connections advertised as
2G, as opposed to effectively 2G connections such as weak 3G).

On Wed, Oct 19, 2016 at 2:05 AM Domenic Denicola notifications@github.com
wrote:

@KenjiBaheux https://github.com/KenjiBaheux can you give us a quick
update on this intervention? Is it shipping in Chrome stable now? If so we
should re-open discussions of merging whatwg/html#1400
whatwg/html#1400


You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#17 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGD3CvzN-jb2unRbjg7KPR1C-lRfk6dEks5q1PxNgaJpZM4IN2lZ
.

Collaborator

KenjiBaheux commented Oct 25, 2016

Yes, we are aiming at a launch in Chrome 55 (for connections advertised as
2G, as opposed to effectively 2G connections such as weak 3G).

On Wed, Oct 19, 2016 at 2:05 AM Domenic Denicola notifications@github.com
wrote:

@KenjiBaheux https://github.com/KenjiBaheux can you give us a quick
update on this intervention? Is it shipping in Chrome stable now? If so we
should re-open discussions of merging whatwg/html#1400
whatwg/html#1400


You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#17 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGD3CvzN-jb2unRbjg7KPR1C-lRfk6dEks5q1PxNgaJpZM4IN2lZ
.

@minias minias referenced this issue in daumPostcode/QnA Oct 26, 2016

Open

크롬 CORS 보안이슈. #25

@KenjiBaheux

This comment has been minimized.

Show comment
Hide comment
@KenjiBaheux

KenjiBaheux Nov 2, 2016

Collaborator

As an FYI, we've just sent our intent to ship and started an FAQ as well as a form to collect feedback / suggestions for the FAQ.

Collaborator

KenjiBaheux commented Nov 2, 2016

As an FYI, we've just sent our intent to ship and started an FAQ as well as a form to collect feedback / suggestions for the FAQ.

@zeg

This comment has been minimized.

Show comment
Hide comment
@zeg

zeg Nov 8, 2016

My site's javascript script is hosted in a different domain (cdn)

And must be loaded synchronously to properly render the content

And that is a huge project I can not change all of them to asynchronous load

Please you developers to tell me how I should do???

zeg commented Nov 8, 2016

My site's javascript script is hosted in a different domain (cdn)

And must be loaded synchronously to properly render the content

And that is a huge project I can not change all of them to asynchronous load

Please you developers to tell me how I should do???

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Dec 6, 2016

I wrote about how you can use an iframe + document.write to stream HTML https://jakearchibald.com/2016/fun-hacks-faster-content/#using-iframes-and-documentwrite-to-improve-performance

The HTML spec currently says that scripts shouldn't execute in this case (issue), but Edge, Chrome & Safari all do, so it's possible the spec will change.

Since these document.writes happen after the document has loaded (there's no network stream feeding into the parser), it feels like it should be exempt from this intervention.

I wrote about how you can use an iframe + document.write to stream HTML https://jakearchibald.com/2016/fun-hacks-faster-content/#using-iframes-and-documentwrite-to-improve-performance

The HTML spec currently says that scripts shouldn't execute in this case (issue), but Edge, Chrome & Safari all do, so it's possible the spec will change.

Since these document.writes happen after the document has loaded (there's no network stream feeding into the parser), it feels like it should be exempt from this intervention.

@shivanigithub

This comment has been minimized.

Show comment
Hide comment
@shivanigithub

shivanigithub Dec 12, 2016

@jakearchibald : The intervention only works for scripts that are in the main frame, so any document.written script in an iframe will be exempt from the intervention.

@jakearchibald : The intervention only works for scripts that are in the main frame, so any document.written script in an iframe will be exempt from the intervention.

@pfwd

This comment has been minimized.

Show comment
Hide comment
@pfwd

pfwd Dec 27, 2016

It might be worth having some more definition around what is a 'Slow Connection'.
A weak 3G connection can be just as bad if not worse than a strong 2G connection.
Ideally we need to detect the signal strength within each band but I'm not sure if that's possible

pfwd commented Dec 27, 2016

It might be worth having some more definition around what is a 'Slow Connection'.
A weak 3G connection can be just as bad if not worse than a strong 2G connection.
Ideally we need to detect the signal strength within each band but I'm not sure if that's possible

@acsteitz

This comment has been minimized.

Show comment
Hide comment
@acsteitz

acsteitz Dec 29, 2016

There is a lot of uproar in public forums about this intervention. Not because people on 2G are ending up with broken pages, but because people on FAST connections are ending up with them.

Whatever mechanism has been installed for this intervention, it doesn't work properly. I get the warning in DevTools that scripts have been blocked even though I am on a solid WiFi connection.
Ookla speed test: Ping: 37 ms; Download: 13.29 Mbps; Upload: 14.47 Mbps.
Chrome Version 55.0.2883.87 m (64-bit)
Windows 10 Pro (10.0.14393)

Bootstrap.js:214 A Parser-blocking, cross-origin script, https://cdn.tt.omtrdc.net/cdn/target.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity. See https://www.chromestatus.com/feature/5718547946799104 for more details.
sf @ Bootstrap.js:214
Bootstrap.js:172 A Parser-blocking, cross-origin script, https://humana.tt.omtrdc.net/m2/humana/mbox/ajax?mboxHost=myhumana.humana.c…oxReferrer=https%3A%2F%2Fwww.humana.com%2Fservice-agreement&mboxVersion=60, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity. See https://www.chromestatus.com/feature/5718547946799104 for more details.

There is a lot of uproar in public forums about this intervention. Not because people on 2G are ending up with broken pages, but because people on FAST connections are ending up with them.

Whatever mechanism has been installed for this intervention, it doesn't work properly. I get the warning in DevTools that scripts have been blocked even though I am on a solid WiFi connection.
Ookla speed test: Ping: 37 ms; Download: 13.29 Mbps; Upload: 14.47 Mbps.
Chrome Version 55.0.2883.87 m (64-bit)
Windows 10 Pro (10.0.14393)

Bootstrap.js:214 A Parser-blocking, cross-origin script, https://cdn.tt.omtrdc.net/cdn/target.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity. See https://www.chromestatus.com/feature/5718547946799104 for more details.
sf @ Bootstrap.js:214
Bootstrap.js:172 A Parser-blocking, cross-origin script, https://humana.tt.omtrdc.net/m2/humana/mbox/ajax?mboxHost=myhumana.humana.c…oxReferrer=https%3A%2F%2Fwww.humana.com%2Fservice-agreement&mboxVersion=60, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity. See https://www.chromestatus.com/feature/5718547946799104 for more details.

@acsteitz

This comment has been minimized.

Show comment
Hide comment
@acsteitz

acsteitz Dec 29, 2016

BTW, I do not work for Humana. I am a customer and this broken intervention prevents me from being able to LOGOUT. I have to wait for my session to TIMEOUT instead which is OK if I am on my own computer but if I happen to be on someone else's computer or, even worse, at a public computer (library, kiosk, etc) I have to either sit at the computer until I know the session has timed-out or risk someone else getting into my medical claims. Thanks a lot! I wonder if there are any banking sites or other "high risk/value" sites that are affected.

I realize you did not create the Humana web site but this broken intervention has CAUSED this potential invasion of privacy. Since I know about it now, I can avoid it but what about the millions of people who don't know about this problem who could end up exposing their personal information because of this change that was pushed through without enough REAL WORLD research?

acsteitz commented Dec 29, 2016

BTW, I do not work for Humana. I am a customer and this broken intervention prevents me from being able to LOGOUT. I have to wait for my session to TIMEOUT instead which is OK if I am on my own computer but if I happen to be on someone else's computer or, even worse, at a public computer (library, kiosk, etc) I have to either sit at the computer until I know the session has timed-out or risk someone else getting into my medical claims. Thanks a lot! I wonder if there are any banking sites or other "high risk/value" sites that are affected.

I realize you did not create the Humana web site but this broken intervention has CAUSED this potential invasion of privacy. Since I know about it now, I can avoid it but what about the millions of people who don't know about this problem who could end up exposing their personal information because of this change that was pushed through without enough REAL WORLD research?

@acsteitz

This comment has been minimized.

Show comment
Hide comment
@acsteitz

acsteitz Dec 29, 2016

I had not thought about the potential exposure for other people until I wrote the above. Sorry to do this, but given what I just realized, I am going to have to publish my concerns to a much broader audience. This MUST get fixed post haste.

I had not thought about the potential exposure for other people until I wrote the above. Sorry to do this, but given what I just realized, I am going to have to publish my concerns to a much broader audience. This MUST get fixed post haste.

@TechRsch

This comment has been minimized.

Show comment
Hide comment
@TechRsch

TechRsch Dec 29, 2016

My hardwired 100Mb LAN connection is throwing this error.

My hardwired 100Mb LAN connection is throwing this error.

@bryanmcquade

This comment has been minimized.

Show comment
Hide comment
@bryanmcquade

bryanmcquade Dec 30, 2016

Replying to acsteitz:

The console warning shows up in cases where the intervention would have triggered on slow connections, even if you are on a fast connection, to help developers to identify cases where users on slow connections would encounter blocking. So the warning is just that: a warning - it doesn't indicate that the intervention actually triggered in your case.

If you see "A Parser-blocking, cross-origin script, ..., is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity. See https://www.chromestatus.com/feature/5718547946799104 for more details." in the console it indicates that the script may be blocked for users on slow connections, but not necessarily that the script was blocked for your connection. We currently only block on 2G so this should not be triggering if you are on a fast connection.

If the Humana site is failing to support logout on a fast connection, that's likely due to a bug on their site (or possibly a different Chrome bug) rather than this intervention, as the intervention should be having no effect while on a fast connection.

To force disable the intervention, just to be certain, you can go to chrome://flags/ and choose 'Disabled' for 'Block scripts loaded via document.write'. If you are already on a fast connection this should be a no-op, but it can't hurt to try. If you see different behavior with the intervention disabled (i.e. the 'logout' option starts to work) then please let us know.

Replying to acsteitz:

The console warning shows up in cases where the intervention would have triggered on slow connections, even if you are on a fast connection, to help developers to identify cases where users on slow connections would encounter blocking. So the warning is just that: a warning - it doesn't indicate that the intervention actually triggered in your case.

If you see "A Parser-blocking, cross-origin script, ..., is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity. See https://www.chromestatus.com/feature/5718547946799104 for more details." in the console it indicates that the script may be blocked for users on slow connections, but not necessarily that the script was blocked for your connection. We currently only block on 2G so this should not be triggering if you are on a fast connection.

If the Humana site is failing to support logout on a fast connection, that's likely due to a bug on their site (or possibly a different Chrome bug) rather than this intervention, as the intervention should be having no effect while on a fast connection.

To force disable the intervention, just to be certain, you can go to chrome://flags/ and choose 'Disabled' for 'Block scripts loaded via document.write'. If you are already on a fast connection this should be a no-op, but it can't hurt to try. If you see different behavior with the intervention disabled (i.e. the 'logout' option starts to work) then please let us know.

@TechRsch

This comment has been minimized.

Show comment
Hide comment
@TechRsch

TechRsch Dec 30, 2016

Reply to bryanmcquade:

As I have mentioned, I am on a 100Mb hardwired LAN connection. I have had problems running videos on Chrome. I disabled the flag as you suggested. And, now they work. The conclusion is that the intervention WAS triggered and DID interfere with Chrome's operation on a high-speed connection.

Reply to bryanmcquade:

As I have mentioned, I am on a 100Mb hardwired LAN connection. I have had problems running videos on Chrome. I disabled the flag as you suggested. And, now they work. The conclusion is that the intervention WAS triggered and DID interfere with Chrome's operation on a high-speed connection.

@acsteitz

This comment has been minimized.

Show comment
Hide comment
@acsteitz

acsteitz Dec 30, 2016

Reply to bryanmcquade:

I am ashamed! I have taken down my FB and Google+ posts. Some people claim I don't admit when I am wrong. That is not true. I have done it both times. LOL!

I did not know about the flag. I promise I searched for a way to disable it but the first xx pages of results only had people discussing fixes for web devs to get their sites fixed. I set the flag to "disabled" and the logout function is still not available in Chrome 55. However, it worked in Chrome 54 and still works in other browsers.

I have a degree in Physics so I am totally aware of the concept that correlation does not equal causation but without knowing about the flag, all the other indicators pointed at this intervention. Mea culpa.

Also, although I do not work at Humana, I worked at a wholly owned subsidiary until Jan 2010. I still know some people at Humana and will alert them to this problem today so they can research and fix it from their end.

Reply to bryanmcquade:

I am ashamed! I have taken down my FB and Google+ posts. Some people claim I don't admit when I am wrong. That is not true. I have done it both times. LOL!

I did not know about the flag. I promise I searched for a way to disable it but the first xx pages of results only had people discussing fixes for web devs to get their sites fixed. I set the flag to "disabled" and the logout function is still not available in Chrome 55. However, it worked in Chrome 54 and still works in other browsers.

I have a degree in Physics so I am totally aware of the concept that correlation does not equal causation but without knowing about the flag, all the other indicators pointed at this intervention. Mea culpa.

Also, although I do not work at Humana, I worked at a wholly owned subsidiary until Jan 2010. I still know some people at Humana and will alert them to this problem today so they can research and fix it from their end.

@acsteitz

This comment has been minimized.

Show comment
Hide comment
@acsteitz

acsteitz Dec 30, 2016

Reply to bryanmcquade:

Even though setting the flag did not solve my problem, TechRsch seems to have proven (well, at least gathered more evidence) that this intervention does still have issues and could actually cause the type of problem I experience at Humana.com. Seems that this intervention still needs some real world testing/data gathering.

Reply to bryanmcquade:

Even though setting the flag did not solve my problem, TechRsch seems to have proven (well, at least gathered more evidence) that this intervention does still have issues and could actually cause the type of problem I experience at Humana.com. Seems that this intervention still needs some real world testing/data gathering.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jan 2, 2017

Member

However, it worked in Chrome 54 and still works in other browsers.

Sorry about this regression! Please file a bug at crbug.com/wizard providing precise reproduction steps for what worked in Chrome 54 but is now failing in Chrome 55. Our QA team will repeat your steps on a variety of Chrome builds to "bisect" down to the single commit responsible for the change in behavior, and we can take the issue from there.

Member

RByers commented Jan 2, 2017

However, it worked in Chrome 54 and still works in other browsers.

Sorry about this regression! Please file a bug at crbug.com/wizard providing precise reproduction steps for what worked in Chrome 54 but is now failing in Chrome 55. Our QA team will repeat your steps on a variety of Chrome builds to "bisect" down to the single commit responsible for the change in behavior, and we can take the issue from there.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jan 2, 2017

Member

As I have mentioned, I am on a 100Mb hardwired LAN connection. I have had problems running videos on Chrome. I disabled the flag as you suggested. And, now they work. The conclusion is that the intervention WAS triggered and DID interfere with Chrome's operation on a high-speed connection.

If this is true there must be a bug somewhere. Please file a bug at crbug.com/wizard with precise reproduction steps so that we can investigate.

Member

RByers commented Jan 2, 2017

As I have mentioned, I am on a 100Mb hardwired LAN connection. I have had problems running videos on Chrome. I disabled the flag as you suggested. And, now they work. The conclusion is that the intervention WAS triggered and DID interfere with Chrome's operation on a high-speed connection.

If this is true there must be a bug somewhere. Please file a bug at crbug.com/wizard with precise reproduction steps so that we can investigate.

@ddimitrop

This comment has been minimized.

Show comment
Hide comment
@ddimitrop

ddimitrop Feb 15, 2017

Hi,
I have been wondering about how could I test my site for the effects of the intervention.
Would the effects be triggered when I use the devtools network throttling (down to 2G)?
I can see warnings but it looks that the scripts are still run on Chrome 56.

Hi,
I have been wondering about how could I test my site for the effects of the intervention.
Would the effects be triggered when I use the devtools network throttling (down to 2G)?
I can see warnings but it looks that the scripts are still run on Chrome 56.

@shivanisharma2

This comment has been minimized.

Show comment
Hide comment
@shivanisharma2

shivanisharma2 Feb 15, 2017

Go to about:flags and enable the flag "Block scripts loaded via document.write". This will enable the intervention irrespective of the connection type.

Go to about:flags and enable the flag "Block scripts loaded via document.write". This will enable the intervention irrespective of the connection type.

@RByers RByers added this to the Chrome-55 milestone Feb 21, 2017

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Feb 21, 2017

Member

First shipped in Chrome 55

Member

RByers commented Feb 21, 2017

First shipped in Chrome 55

@RByers RByers removed this from the Chrome-55 milestone Feb 21, 2017

@CaptainCodeman CaptainCodeman referenced this issue in webcomponents/webcomponentsjs Mar 21, 2017

Closed

Can't use ES5 with v1.0.0-rc.6 #737

@mrquincle

This comment has been minimized.

Show comment
Hide comment
@mrquincle

mrquincle May 31, 2017

This ends up in my /var/log/syslog.

May 31 17:50:45 V compiz[2597]: A Parser-blocking, cross site (i.e. different eTLD+1) script, https://ssl.google-analytics.com/ga.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.

And many similar ones that are fed into my syslog through compiz.

chrome://version/

Google Chrome	58.0.3029.110 (Official Build) (64-bit)
Revision	691bdb490962d4e6ae7f25c6ab1fdd0faaf19cd0-refs/branch-heads/3029@{#830}
OS		Linux
JavaScript	V8 5.8.283.38
Flash		25.0.0.171 $HOME/.config/google-chrome/PepperFlash/25.0.0.171/libpepflashplayer.so
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Command Line	/usr/bin/google-chrome-stable --flag-switches-begin --enable-experimental-web-platform-features --flag-switches-end
Executable Path	/opt/google/chrome/google-chrome

It looks like this is a place where issues like these are considered, if I'm wrong, I apologize and please correct me in that case!

This ends up in my /var/log/syslog.

May 31 17:50:45 V compiz[2597]: A Parser-blocking, cross site (i.e. different eTLD+1) script, https://ssl.google-analytics.com/ga.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.

And many similar ones that are fed into my syslog through compiz.

chrome://version/

Google Chrome	58.0.3029.110 (Official Build) (64-bit)
Revision	691bdb490962d4e6ae7f25c6ab1fdd0faaf19cd0-refs/branch-heads/3029@{#830}
OS		Linux
JavaScript	V8 5.8.283.38
Flash		25.0.0.171 $HOME/.config/google-chrome/PepperFlash/25.0.0.171/libpepflashplayer.so
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Command Line	/usr/bin/google-chrome-stable --flag-switches-begin --enable-experimental-web-platform-features --flag-switches-end
Executable Path	/opt/google/chrome/google-chrome

It looks like this is a place where issues like these are considered, if I'm wrong, I apologize and please correct me in that case!

@bryanmcquade

This comment has been minimized.

Show comment
Hide comment
@bryanmcquade

bryanmcquade May 31, 2017

Hmm, I'm not sure why messages Chrome writes to the console are ending up in your syslog. I'd recommend disabling that (not sure how, will depend on how your system is set up) if you don't want these to show up there.

Hmm, I'm not sure why messages Chrome writes to the console are ending up in your syslog. I'd recommend disabling that (not sure how, will depend on how your system is set up) if you don't want these to show up there.

domenic added a commit to whatwg/html that referenced this issue Jul 13, 2017

Allow not executing scripts inserted by document.write()
This allows user agents to experiment with better heuristics for not executing such scripts, as per WICG/interventions#17.
@verdy-p

This comment has been minimized.

Show comment
Hide comment
@verdy-p

verdy-p Aug 11, 2017

I see this symptom in Chrome over a fast FTTH connection (>100Mbps symetric), which is definitely not a slow 2G connection.

It occurs with various websites using scripts to load maps or satellite views from Google Map (and i doubt it is slow; not all sites are affected and not Google Map itself.

Those that are affected are using document.write() to insert a script, that will then load the map asynchronously (this works) then will load additional data or markers on it: a part of those markers are visible, then the map and markers disappear (the canvas turns to gray) and then fails.

Apparently Chrome does not correctly track the session, between successive requests, and then fail with the XSS issue when GoogleTagService trackers are loaded, and then we are returned an obscure error about daily quota exceeded for using the map...

Example of what is logged in the console when visiting http://www.maplandia.com/belarus/mahilyow/podgoritsa/


2www.maplandia.com/:39 A Parser-blocking, cross site (i.e. different eTLD+1) script, http://www.googletagservices.com/tag/js/gpt.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.
(anonymous) @ (index):39
www.maplandia.com/:43 Uncaught TypeError: googletag.sizeMapping is not a function
at www.maplandia.com/:43
2www.maplandia.com/:769 A Parser-blocking, cross site (i.e. different eTLD+1) script, http://www.google-analytics.com/ga.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.

verdy-p commented Aug 11, 2017

I see this symptom in Chrome over a fast FTTH connection (>100Mbps symetric), which is definitely not a slow 2G connection.

It occurs with various websites using scripts to load maps or satellite views from Google Map (and i doubt it is slow; not all sites are affected and not Google Map itself.

Those that are affected are using document.write() to insert a script, that will then load the map asynchronously (this works) then will load additional data or markers on it: a part of those markers are visible, then the map and markers disappear (the canvas turns to gray) and then fails.

Apparently Chrome does not correctly track the session, between successive requests, and then fail with the XSS issue when GoogleTagService trackers are loaded, and then we are returned an obscure error about daily quota exceeded for using the map...

Example of what is logged in the console when visiting http://www.maplandia.com/belarus/mahilyow/podgoritsa/


2www.maplandia.com/:39 A Parser-blocking, cross site (i.e. different eTLD+1) script, http://www.googletagservices.com/tag/js/gpt.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.
(anonymous) @ (index):39
www.maplandia.com/:43 Uncaught TypeError: googletag.sizeMapping is not a function
at www.maplandia.com/:43
2www.maplandia.com/:769 A Parser-blocking, cross site (i.e. different eTLD+1) script, http://www.google-analytics.com/ga.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.

@verdy-p

This comment has been minimized.

Show comment
Hide comment
@verdy-p

verdy-p Aug 11, 2017

Apparently this is caused by GoogleAnalytics when a page inserts its tiny script with document.write() near the top of page, that will post an asynchronous request once the page is loaded.
Visibly the Google Analytics tools have bugs.

verdy-p commented Aug 11, 2017

Apparently this is caused by GoogleAnalytics when a page inserts its tiny script with document.write() near the top of page, that will post an asynchronous request once the page is loaded.
Visibly the Google Analytics tools have bugs.

@verdy-p

This comment has been minimized.

Show comment
Hide comment
@verdy-p

verdy-p Aug 11, 2017

So Google Chgrome blocks Google Tag Services (which uses such bad practices of user tracking with cross site scripting). It is prevalent anyway on so many sites to track visitors and monetize websites via profiling of visitors in order to post "relevant" ads. These services won't work, it may be a good thing, but websites will no longer get monetized using the Tag Servies they subscribed Google for, so Google won't pay them.

Is Google Tag Services top be dead? if it cannot postpone some scripts that will run at end of page load (even when they are scheduiled to be executed like here after 10 seconds and the page is compeltely loaded since long and the bandwidth is fully available to posting trackers andd loading porfiled ads?) Apparently there's a conlfict between the own's site profiling needs and the tracking made by Google itself when using its map services, where google will also profile users to send ads or customize the rendered map.

Note: it may as well be bugs in using GPT and Google Map together on the same page, beause I can see several objets ion the console that should have been already initialized but that have been cleared when Google Map was loaded first

Note: I'm not the author of the "maplandia.com" website, it's just no longer usable in Chrome 60, but it still works in IE, Edge, Firefox, or Opera, on Windows 10 x64. I did not test on MacOS, iOS or Android.

verdy-p commented Aug 11, 2017

So Google Chgrome blocks Google Tag Services (which uses such bad practices of user tracking with cross site scripting). It is prevalent anyway on so many sites to track visitors and monetize websites via profiling of visitors in order to post "relevant" ads. These services won't work, it may be a good thing, but websites will no longer get monetized using the Tag Servies they subscribed Google for, so Google won't pay them.

Is Google Tag Services top be dead? if it cannot postpone some scripts that will run at end of page load (even when they are scheduiled to be executed like here after 10 seconds and the page is compeltely loaded since long and the bandwidth is fully available to posting trackers andd loading porfiled ads?) Apparently there's a conlfict between the own's site profiling needs and the tracking made by Google itself when using its map services, where google will also profile users to send ads or customize the rendered map.

Note: it may as well be bugs in using GPT and Google Map together on the same page, beause I can see several objets ion the console that should have been already initialized but that have been cleared when Google Map was loaded first

Note: I'm not the author of the "maplandia.com" website, it's just no longer usable in Chrome 60, but it still works in IE, Edge, Firefox, or Opera, on Windows 10 x64. I did not test on MacOS, iOS or Android.

@normanzb

This comment has been minimized.

Show comment
Hide comment
@normanzb

normanzb Aug 11, 2017

The issue lies in how fast is fast and how slow is slow, 2G network may seems slow to someone who is inpatient to visit a large web page, but it is perfectly fine for a small web page which is viewed by somebody who occasionally visit it with a casual mind.

Google seems decided that it wants to be the authority that defines the word "fast" and "slow" for us, make them a universal value that all chrome users and developers should compliant.

The issue lies in how fast is fast and how slow is slow, 2G network may seems slow to someone who is inpatient to visit a large web page, but it is perfectly fine for a small web page which is viewed by somebody who occasionally visit it with a casual mind.

Google seems decided that it wants to be the authority that defines the word "fast" and "slow" for us, make them a universal value that all chrome users and developers should compliant.

@shivanigithub

This comment has been minimized.

Show comment
Hide comment
@shivanigithub

shivanigithub Aug 11, 2017

Note that the logs mention this as a warning for developers so they know that their site may behave differently in slower networks. But from the logs given above (Copying them here for reference), it does not seem that the network is considered slow and scripts are blocked since there is no subsequent error message.


2www.maplandia.com/:39 A Parser-blocking, cross site (i.e. different eTLD+1) script, http://www.googletagservices.com/tag/js/gpt.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.
(anonymous) @ (index):39
www.maplandia.com/:43 Uncaught TypeError: googletag.sizeMapping is not a function
at www.maplandia.com/:43
2www.maplandia.com/:769 A Parser-blocking, cross site (i.e. different eTLD+1) script, http://www.google-analytics.com/ga.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.

Note that the logs mention this as a warning for developers so they know that their site may behave differently in slower networks. But from the logs given above (Copying them here for reference), it does not seem that the network is considered slow and scripts are blocked since there is no subsequent error message.


2www.maplandia.com/:39 A Parser-blocking, cross site (i.e. different eTLD+1) script, http://www.googletagservices.com/tag/js/gpt.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.
(anonymous) @ (index):39
www.maplandia.com/:43 Uncaught TypeError: googletag.sizeMapping is not a function
at www.maplandia.com/:43
2www.maplandia.com/:769 A Parser-blocking, cross site (i.e. different eTLD+1) script, http://www.google-analytics.com/ga.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.

@fwebdev

This comment has been minimized.

Show comment
Hide comment
@fwebdev

fwebdev Aug 14, 2017

Google stopped the implementation of that Browser Interventention, because the performance improvement on real Users was too small.
In current Chrome Version there is also no logging in dev Console for me anymore.

https://bugs.chromium.org/p/chromium/issues/detail?id=575850

fwebdev commented Aug 14, 2017

Google stopped the implementation of that Browser Interventention, because the performance improvement on real Users was too small.
In current Chrome Version there is also no logging in dev Console for me anymore.

https://bugs.chromium.org/p/chromium/issues/detail?id=575850

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Aug 14, 2017

@fwebdev that bug you link to is not related to the intervention discussed here. It has to do with document.write() and script tags, but with executing them more aggressively, not with blocking them.

domenic commented Aug 14, 2017

@fwebdev that bug you link to is not related to the intervention discussed here. It has to do with document.write() and script tags, but with executing them more aggressively, not with blocking them.

@EddieOne

This comment has been minimized.

Show comment
Hide comment
@EddieOne

EddieOne Aug 27, 2017

I get this error on a fast connection.

cap.js:153 A Parser-blocking, cross site (i.e. different eTLD+1) script, https://back20.keycaptcha.com/swfs/caps.js?uid=79849&u=http%3A%2F%2Fstatic.y8.com%2Fupload&r=0.10667958468013206, is invoked via document.write.

I thought it was for 2g only?

I get this error on a fast connection.

cap.js:153 A Parser-blocking, cross site (i.e. different eTLD+1) script, https://back20.keycaptcha.com/swfs/caps.js?uid=79849&u=http%3A%2F%2Fstatic.y8.com%2Fupload&r=0.10667958468013206, is invoked via document.write.

I thought it was for 2g only?

@bryanmcquade

This comment has been minimized.

Show comment
Hide comment
@bryanmcquade

bryanmcquade Aug 29, 2017

That's right, this is a warning to let site developers know that their scripts may be blocked for users on slow connections, even if they aren't currently on a slow connection.

The full message is:
A Parser-blocking, cross site (i.e. different eTLD+1) script, , is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.

That's right, this is a warning to let site developers know that their scripts may be blocked for users on slow connections, even if they aren't currently on a slow connection.

The full message is:
A Parser-blocking, cross site (i.e. different eTLD+1) script, , is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message.See https://www.chromestatus.com/feature/5718547946799104 for more details.

soundasleep added a commit to soundasleep/statgit2 that referenced this issue Sep 22, 2017

Resolve Chrome intervention which may cause broken Google Charts
This intervention was being triggered because we were using old Google Charts
loader code, and Chrome was warning that on slower connections the charts
may not be loaded (to help the user experience). Using the latest loader code
listed at https://developers.google.com/chart/interactive/docs/basic_load_libs
resolves this issue.

See WICG/interventions#17

@clelland clelland referenced this issue in WICG/feature-policy Jun 5, 2018

Closed

Introduce Feature policy : `document-write` #172

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment