Inline Script

内联脚本对页面性能的影响

怿飞 / 圆心

Who's this guy?

http://www.planabc.net

[email protected]

怿飞 / 圆心

• Technology Evangelist

• Front-End Engineer

in Taobao UED

http://www.planabc.net/

mailto:[email protected]

案例分析

http://stevesouders.com/cuzillion/?ex=10100&title=Inline+Scripts+Block





案例分析

1. 脚本执行结束，第二张图才开始下载。

2. 页面加载之后，至少5秒页面无任何内

容显示。

影响的主要方面

阻塞页面资源的并行下载

阻塞页面的逐步渲染

影响的主要原因

保持执行顺序

对 document.write 的依赖关系

问题的解决方案

将内联脚本移至底部。

使用异步回调。

使用 script 的 defer 属性。

将内联脚本移至底部

避免了下载阻塞，实现了并行下载。

此方法适用于：执行时间小于 300毫秒的

内联脚本。

无法解决阻塞页面的逐步渲染的问题。

使用异步回调

使用异步回调： setTimeout

最简单的异步调用就是使用

setTimeout：



在 Internet Explorer 中实现了逐步渲染。

Firefox中依旧阻塞页面的逐步渲染。


Firefox中将毫秒数增加到250毫秒，也可实

现页面的逐步渲染。

Note: 神奇数字 250源于 nglayout.initialpaint.delay（“显

示页面之前的等待毫秒数”）的默认值。如果 longCode 在250

毫秒之前就开始执行，所有渲染在它执行完毕之前都会被阻塞，

如果我们等待250毫秒之后再调用 longCode，Firefox 就能渲染

页面顶部的文本。


在这两种情况下（IE中0ms和FF中250ms）:

都只有文本被快速渲染。

图片虽然在1 秒之后返回，但直到

longCode 在 5 秒钟之后执行完毕时才在页

面中显示。

Note: 渲染事件在1秒之后进入队列，而浏览器在 longCode

执行的同时不能响应这个事件。浏览器是单线程的，JavaScript

执行的同时所有渲染事件都会被阻塞。我们可以通过增加

setTimeout 的毫秒数来解决它，该毫秒数比1秒的图片下载时间

稍大，比如1500毫秒。

使用异步回调： onload

如果想异步执行 longCode 而不阻塞浏览

器渲染，更好的做法是使用 onload 事件来

触发代码运行：

使用异步回调：总结

如果内联脚本很短，使用 setTimeout 的 0

毫秒延迟是一个兼顾快速渲染和JavaScript

快速执行的不错方案。

如果脚本很长，更好的选择是使用 onload。

使用 script 的 defer 属性

defer 属性对内联脚本也有效，它允许浏览

器继续解析页面，同时延迟内联脚本的执

行。


直到脚本执行完成后页面才开始渲染。

仅 Internet Explorer 和 Firefox3.1+ 支持。

解决方案的回顾

将内联脚本移至底部（最简单，执行时间

小于 300毫秒）。

使用异步回调（最优化）。

使用 script 的 defer 属性（不提倡）。