主页面和iframe中加载资源的测试.docVIP

主页面和iframe中加载资源的测试 对于iframe，我是比较少做测试的，今晚由于我的一个问题“有没有办法让页面HTML内容和其他资源并行加载”引发了我和瓶子之间的一番关于iframe的测试。 首先是由于我的一个误解“iframe会阻塞后面资源的下载”以及上面的问题引发的“浏览器解析页面和下载资源的顺序问题”开始。在Webkit的官方博客中发表了这么篇文章：《How WebKit Loads a Web Page》， 讲述页面解析HTML和下载资源的机制。文中就说明了Webkit在加载一个页面的时候存在两个下载通道，一个用于加载html document，另一个用于加载子资源（图片、CSS、JS等等），并且这两个通道存在时间顺序问题（查看原文或者下面的图示即可了解），这就说明了 “让页面HTML内容和其他资源并行加载”就目前来说是不可能实现的，因为这是由浏览器内部的加载页面的机制决定了。 在这篇文章里，跟瓶子就“Frames”这个字眼见解有些不同，他认为这就是跟普通页面的iframe一样的意思（这也是接下来一堆测试iframe的导 火线），而我曾经在某篇En文里看过Firefox中解析HTML页面的时候，也提到了Frame这个字眼，而它所说的Frame并不是普通html中的 iframe，而是相当于一个“暗箱”，或者说是一个“容器”，来解析HTML页面内容。这个问题未得到证实，就不多说了。 之后我就凭记忆说了一句“加载iframe会阻碍后面的元素的加载”，我的本意是说，当iframe中有js、图片、css等资源需要加载时，会阻塞主页 面中iframe后面资源的加载。可是经过他的测试，发现说“主页面的html和iframe的html是并行加载的”。刚开始我就纳闷了，就拿出《高性 能网站建设进阶指南》来查看关于iframe的内容，发现书中并没有关于“加载iframe会阻碍后面的元素的加载”的论述，而是叙述了当iframe前 面有CSS或者JS资源的时候，会阻塞iframe的加载（测试页面），如果放到iframe其后的话，则会iframe和主页面会并行加载（测试页面）。同时书中也指明了一点“iframe会阻碍主页面onload事件的触发”。 经过这一番测试，不得不承认是我的失误，记错了~ 但是我在测试过程中，通过观察firebug和HTTPWatch生成的HTTP瀑布图发现了一个比较有趣的事情：当iframe在js、图片、css等 主页面资源的前面的时候，在HTTP瀑布图中显示iframe内的资源都是后于主页面的资源加载的。我就纳闷了，这么奇怪的问题。接下来我就写了一个测试 页面，页面中iframe内的js文件中定义了一个函数，而且文件有100多K大小；在主页面的fulljsmin.js文件中调用该函数，文件很小（测试页面）。通过测试更有意思的是，成功调用了该函数，没有出现未定义的错误，这不是跟HTTP瀑布图中显示的不符合吗？下面是在firebug和HTTPWatch下的HTTP瀑布图：  同时，在Chrome下用Inspect插件来测试，也都发现了这样的情况。虽然在IE8下HTTPWatch中显示iframe并没有和主页面并行加 载，但是出现的问题都基本跟上面所述一致。这难道是firebug、HTTPWatch、Inspect的一个bug？不可能同时都出现这个问题吧？我想 问题还应该是出在页面加载iframe的机制上。 对于这个问题，我最初的想法是主页面在加载iframe的时候会开启另外一个进程来加载iframe里面的资源，但是浏览器普遍都只能是两个资源并行下 载，iframe内也同样难逃这条规则。所以这个想法就错误了，而瓶子对于这个页面同时加载主页面的资源和iframe内的资源的看法是： 父页面html加载-html解析 如果有iframe，就开一个iframe线程下载html，重复步骤1 把页面其他要请求的元素放入一个加载队列，这个队列是全局的，如果是iframe的html解析的时候，也会被加入到这个队列里。但是最终会出现 的顺序可能有所不同，有的浏览器应该会等html全部分析完再开始执行加载队列，有的则是一边解析一边对队列进行执行。对于第一种情况，出现的顺序应该 是：主页面的内容先加载，iframe里面的内容会最后连续加载对于第二种情况，出现的顺序可能是交叉的，不过iframe的加载应该大多集中在一处。 第一点看法是毋庸置疑的，但是第二点所说的“开一个iframe线程下载html，重复步骤1”，这点或许需要说明一下，这开一个iframe线程是受到 浏览器通常只能同时两个并发下载数的限制的，所以这里的新开线程可能会受到CSS、JS文件的影响，就像开头说的，CSS、JS在iframe前面的时 候，会阻塞ifr