一旦example.css文件加载完成，渲染树也就被构建好了。
内联的脚本执行完之后，解析器就会立即被other.js阻塞住。一旦解析器被阻塞，浏览器就会收到绘制请求，"Hi there!"也就显示在了页面上。
当other.js加载完成之后，解析器继续向下解析。。。
解析器遇到last.js之后会被阻塞，然后浏览器收到了另一个绘制请求，"Hi again!"就显示在了页面上。最后last.js会被加载，并且会被执行。
但是，为了减缓渲染被阻塞的情况，现代的浏览器都使用了猜测预加载（speculative loading）。
在上面这种情况下，脚本和样式文件会严重阻塞页面的渲染。猜测预加载的目的就是减少这种阻塞时间。当渲染被阻塞的时候，它会做以下一些事：
•轻量级的HTML（或CSS）扫描器（scanner）继续在文档中扫描
•查找那些将来可能能够用到的资源文件的url
•在渲染器使用它们之前将其下载下来
但是，猜测预加载不能发现通过javascript脚本来加载的资源文件（如，document.write()）。
注：所有的“现代”浏览器都支持这种方式。
回过来再看上面的例子，通过猜测预加载这种方式是怎么工作的。
解析器返现了example.css，并从网络获取，解析器没有被阻塞，继续解析，当遇到了内联的script节点时，被阻塞住，由于样式文件没有加载完成，阻塞了脚本的执行。渲染树同样也被样式文件阻塞住，所以浏览器没有收到渲染请求，看不到任何东西。到目前为止，和刚才提到的那种方式是一样的。但是接下来就由变化了。
预加载器（Speculative loader）继续“阅读”文档，发现了last.js并视图加载它。接下来：
