这类页面的特点是，一个外链脚本置于页面头部，三个外链脚本置于页面的底部，并且是故意跟随在一系列img之后，在Chrome中页面加载的网络请求瀑布图如下：

值得注意的是，虽然脚本放置在图片之后，但加载仍先于图片。为什么会出现这样的情况？为什么故意置后资源能够提前得到加载？

虽然浏览器引擎的实现不同，但原理都十分的近似。不同浏览器的制造厂商们(vendor)非常清楚浏览器的瓶颈在哪(比如network, javascript evaluate, reflow, repaint)。针对这些问题，浏览器也在不断的进化，所以我们才能看到更快的脚本引擎，调用GPU的渲染等一推陈出新的优化技术和方案。

同样在资源加载上，早在IE8开始，一种叫做lookahead pre-parser(在Chrome中称为preloader)的机制就已经开始在不同浏览器中兴起。IE8相对于之前IE版本的提升除了将每台host最高并行-的资源数从2提升至6，并且能够允许并行-脚本文件之外，最后就是这个lookahead pre-parser机制

但我还是没有详述这是一个什么样的机制，不着急，首先看看与IE7的对比：

以上面的页面为例，我们看看IE7下的瀑布图：

底部的脚本并没有提前被加载，并且因为由于单个域名最高并行-数2的限制，资源总是两个两个很整齐的错开并行-。

但在IE8下，很明显底部脚本又被提前：

并没有统一的标准规定这套机制应具备何种功能已经如何实现。但你可以大致这么理解：浏览器通常会准备两个页面解析器parser，一个(main parser)用于正常的页面解析，而另一个(preloader)则试图去文档中搜寻更多需要加载的资源，但这里的资源通常仅限于外链的js、stylesheet、image；不包括audio、video等。并且动态插入页面的资源无效。

但细节方面却值得注意：

比如关于preloader的触发时机，并非与解析页面同时开始，而通常是在加载某个head中的外链脚本阻塞了main parser的情况下才启动；

也不是所有浏览器的preloader会把图片列为预加载的资源，可能它认为图片加载过于耗费带宽而不把它列为预加载资源之列；

preloader也并非最优，在某些浏览器中它会阻塞body的解析。因为有的浏览器将页面文档拆分为head和body两部分进行解析，在head没有解析完之前，body不会被解析。一旦在解析head的过程中触发了preloader，这无疑会导致head的解析时间过长。

Preloader在响应式设计中的问题

preloader的诞生本是出于一番好意，但好心也有可能办坏事。

filamentgroup有一种著名的响应式设计的图片解决方案Responsive Design Images：