为什么大多数营销标签(Omniture、XE等)都是用document.write()编写的?[副本]

这绝对是丑陋的,但它是最坚固的战斗,沉默,防白痴的方法。“在这里把这些内容写在页面上”的范例几乎没有让人惊讶的地方,而且实现至少在返回v3浏览器的整个过程中都是可靠的,可能更早。

[编辑]“v3”浏览器,与Firefox 3不同,但与Netscape 3相同。如果Netscape今天仍然存在,我想它现在应该是11版了。

使用document.write插入页面的脚本不会阻止其他脚本执行,因此当广告的外部资源插入页面时,页面加载速度不会受到影响。更多信息: http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/

我看不出这个方法在浏览器缓存方面有任何保证…?例如,如果它请求一个图像,那么不管请求是来自原始源中的img标记还是来自 document.write -书写的img标签。

我的最佳猜测是,他们希望脚本是独立的,并且易于部署。很多时候(出于明显的原因)所引用的脚本(例如,图像指向的URL)是不同的,这取决于当前页面是否通过安全的HTTPS连接加载。如果当前页面是https页面,则加载 https://omniture.com/xxx ,否则,加载 http://omniture.com/yyy . 这在JavaScript中很容易实现,但不能用HTML硬编码。对于任何一种服务器端语言,实现起来都同样容易,这是更好的选择,但我认为他们不想说“以您喜欢的任何方式继续并实现此功能”,而是希望提供一个尽可能好用的解决方案,而不管环境如何并且依赖性尽可能少。

它与缓存无关。这与脚本提供者不知道脚本在文档中的位置有关。脚本提供程序不能 document.getElementsByTagName("script") 并在第一个带有匹配URI的脚本标记后插入HTML,因为它不知道该URI是否包含哈希( http://example.com/blah.js#foo )或者直接托管在第一方服务器上以减少DNS请求。有一种解决方法,但它涉及到使用在捕获的错误中暴露的脚本文件名的黑暗魔法。这种魔力的实现可以在 my implementation of document.write for asynchronous scripts . ( <script async> )