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

[KenjiBaheux]

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

[shivanisharma2]

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]

First shipped in Chrome 55

[mrquincle]

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]

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.

[verdy-p]

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]

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]

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]

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]

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]

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]

@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]

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]

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.

[Astara]

Am I to understand that I should not get this error in my console log on a 30/10Mbps (u/d) cable-modem connection? Or...why might I get this error if I'm on a home connection?

[zcorpan]

@Astara read the comment above https://github.com/WICG/interventions/issues/17#issuecomment-325730771

[Astara]

I read that -- in fact I remember almost that exact wording in the message I saw in Opera's console window. Ok, "dev-level msg", about what could happen for any reason with cross-site content inserted by a doc.write. A bit arcane, but a useful feature to have to preserve interactivity.

Is there, or should there be a configurable somewhere to define 'slow'? Or is it done algorithmically based on performance of the static, cross-site content on the page (i.e. hypothetically, not in some browser-specific specific instance). I'm guessing 'unspecified' & possibly given that this is talking about allowed behavior.

Ok, thanks for the feedback!

[nucleare]

Is there any way to override this or prevent this from occurring automatically in the browser?

My apologies in advance if I am in the wrong place to report this issue (as I'm not sure if reporting it as a new issue was applicable, and) as I have tried resolving this matter for days to no avail and have been lead to this discussion from the this page as shown in the console message here:

I am hardwired on a desktop running Chrome Version 83.0.4103.116 on a connection of greater than 300Mbps as shown in the speedtest here:

Which seems to be contrary to the alleged remarks of only happening to users on 2G as confirmed by comment #17 and of all my efforts which include but is not limited to disabling my firewall, enabling pop-ups, enabling insecure content from all associated websites of this page, changing default programs, verifying group policies and what else I or any troubleshooting manual could suggest related to the matter that I could think of to determine why this page will not open the java application to open and these console messages are all I have left to go off of.

Please correct me if something else other than the browser that may be preventing me from loading this page or is it possibly something else going on not shown in the console preventing me from loading the application?

I am trying to load an application called MarketPro from merrilledge.com, it is a stock market trading application that is not loading as intended and continues to lead me to another page.

In case there is any question about my attempt to contact Merrill Edge directly they have confirmed that it should be working but even after going through the troubleshooting guide and taking what other steps I could think of unrelated to Chrome, this is all I have left. I realize this is not a support page or technical support page but it seems to be an error related to this particular parser in Chrome's console that I have yet to eliminate as a reason for my being unable to access the application. So any re-direction or help would be greatly appreciated.

[shivanigithub]

@nucleare : The console warnings do not imply that this resource was actually blocked since there was no error log that confirmed it. I suggest testing if this works in other browsers or not. If the issue is occurring only on Chrome, you might want to open an issue via https://bugs.chromium.org/p/chromium/issues/entry

[nucleare]

@nucleare : The console warnings do not imply that this resource was actually blocked since there was no error log that confirmed it. I suggest testing if this works in other browsers or not. If the issue is occurring only on Chrome, you might want to open an issue via https://bugs.chromium.org/p/chromium/issues/entry

Thank you for the reply and insight. I've only tested it on another computer with a fresh install of chrome and with Microsoft Edge on that same, other computer with no difference in results. Since it seems to produce an error on Microsoft Edge as well then it seems it's not exclusive to Chrome.

Once again, I appreciate the insight and pointing me in the right direction if it had been a chrome issue.

[shivanigithub]

@nucleare : I would also suggest to test on a non-Chromium browser like Firefox/Safari/some other (both Chrome and Edge use the chromium code) to make sure it is not a bug in chromium.

[CoderNie]

block network requests for document.written scripts

Does it means this intervention will block both download and execution of the script?

I set my chrome to 2G mode, but I still has not observed this intervention

[domenic]

As part of shutting down this repo (see #72), I'll close this issue. The behavior here is standardized in HTML so further spec-level discussions aren't necessary.

---

For those interested in the Chromium project's implementation, and not the standardization process, I encourage you to discuss on the Chromium issue tracker, at https://crbug.com/. Here are some parting notes on things I discovered while investigating the status of Chromium's implementation:

Chromium shipped (in version 55):

• Disabling such scripts on 2G connections
• A warning, on any connection, for such scripts (so that you know that for any 2G users, they might get a different experience than you are getting, on a good connection)

Chromium has a disabled-by-default feature to block such scripts on slow connections in general, not just connections that advertise as 2G.

I've updated the ChromeStatus for these two features: shipped 2G feature, not-shipped slow-connections feature. I've also inquired on the bug for the slow-connections feature about the future of that work.

Again, all discussion on these Chromium-specific things should happen on the Chromium issue tracker, and not here :).

[CoderNie]

您好，我已收到您的邮件，会尽快处理！