With this data in mind, Chrome, starting with version 55, intervenes on behalf of all users when we detect this known-bad pattern by changing how document.write() is handled in Chrome (See Chrome Status). Specifically Chrome will not execute the elements injected via document.write()when all of the following conditions are met:
The user is on a slow connection, specifically when the user is on 2G. (In the future, the change might be extended to other users on slow connections, such as slow 3G or slow WiFi.)
The document.write() is in a top level document. The intervention does not apply to document.written scripts within iframes as they don’t block the rendering of the main page.
The script in the document.write() is parser-blocking. Scripts with the ‘async‘ or ‘defer‘ attributes will still execute.
The script is not hosted on the same site. In other words, Chrome will not intervene for scripts with a matching eTLD+1 (e.g. a script hosted on js.example.org inserted on www.example.org).
The script is not already in the browser HTTP cache. Scripts in the cache will not incur a network delay and will still execute.
The request for the page is not a reload. Chrome will not intervene if the user triggered a reload and will execute the page as normal.
Third party snippets sometimes use document.write() to load scripts. Fortunately, most third parties provide asynchronous loading alternatives, which allow third party scripts to load without blocking the display of the rest of the content on the page.