所以，我正在试图找到为什么会出现这个问题的答案;我已经解决了这个问题，但我想知道它为什么会发生。
Google提供的使用document.write注入iframe的转化跟踪代码突然导致该网页停止在所有版本的Internet Explorer中执行，但通过使用非{{1}注入相同的iframe进行了补救方法。
Doubleclick是一个广告网络，提供用于跟踪广告转化的JavaScript代码段。
他们提供的代码段如下：
document.write现在，我知道，由于各种原因，document.write是危险的，应该避免。但是，Google正在给我这个代码，所以，我认为我可以相信它。
它突然开始打破使用Internet Explorer的所有用户的所有页面。如同，在页面点击<SCRIPT language="JavaScript">
var axel = Math.random()+"";
var a = axel * 10000000000000;
document.write('<IFRAME SRC="https://fls.doubleclick.net/activityi;src=143;type=donat01;cat=indir4;ord=1;num='+ a + '?" WIDTH=10 HEIGHT=10 FRAMEBORDER=0></IFRAME>');
</SCRIPT>
<NOSCRIPT>
<IFRAME SRC="https://fls.doubleclick.net/activityi;src=143;type=donat01;cat=indir4;ord=1;num=1?"
WIDTH=1 HEIGHT=1 FRAMEBORDER=0></IFRAME>
</NOSCRIPT>
后，页面将完全停止渲染。这很疯狂：互联网上最大的第三方广告客户之一给了我一些JavaScript，这些JavaScript在我的流量中占据了25％的折扣！
作为分类，我使用Google Analytics中的注入技术快速替换了相同的代码：
document.write这解决了这个问题，但没有真正解释：
答案 0 :(得分：8)
我已经解决了这个问题;事实证明它与<iframe>的内容无关。
事实证明，页面由一个框架提供服务，该框架开始使用后端DOM解析器，原因可能与</ <script>内document.write标记内存在</iframe有关，完全删除document.write＆gt;从生成的页面关闭标记，即使它在后端保留它。 （它可能试图强制执行ETAGO规则）。
我能够重现它的原因是因为我正在复制生成的</iframe>代码，而不是原始代码，并且从未注意到丢失的</iframe>。 （而且我的“正常运行”document.write代码没有删除iframe标记，导致我认为问题是<iframe>的内容。）
因此，浏览器在页面上解析了一个未关闭的{{1}}标记，Internet Explorer不知道如何处理，并且在解析iframe时死了一部分（我还是不完全确定）为什么）。
答案 1 :(得分：0)
document.write()阻止进一步的页面呈现，直到完成。我假设远程脚本需要一段时间才能加载，因此阻止了页面的其余部分加载。
我还假设Math.Random（）函数无关紧要。
另外...... Google的跟踪代码吓到了我......他们往往是丑陋的javascript。
答案 2 :(得分：0)
第一种方法应该缓慢有两个原因。
您的解决方案有效，因为它创建的iframe在onload事件之后才会请求远程URL。在第一个代码上设置超时后，您还可以加载页面，然后将远程URL的请求激活。
至于为什么代码更改打破了网站，我似乎无法找到两者之间的任何速度差异。也许它似乎更快，因为它被缓存了。
答案 3 :(得分：0)
我不知道您网站的结构，但通常第一个脚本标记位于<head>。 <head>中的iframe无法呈现。如果你做document.body.getElementsByTagName('script')[0]，我会打赌你可能会遇到与上述问题类似的问题。
答案 4 :(得分：0)
似乎你遇到类似I had several months back的问题。 document.write触发，并覆盖页面。只需直接使用iframe，一切都应该是犹太洁食。
答案 5 :(得分：0)
我尝试复制你的问题，但无法在IE9上播放。
要么我没有正确的测试设置，要么IE 9之前的IE似乎有一些bug。 Firefox有一个类似的错误：https://bugzilla.mozilla.org/show_bug.cgi?id=293633
也许它是未关闭的iframe和正在呈现的页面内部的组合。