内联脚本对页面性能的影响 怿飞 / 圆心
内联脚本对页面性能的影响
怿飞 / 圆心
Who's this guy?
http://www.planabc.net
怿飞 / 圆心
• Technology Evangelist
• Front-End Engineer
in Taobao UED
案例分析
http://stevesouders.com/cuzillion/?ex=10100&title=Inline+Scripts+Block
案例分析
1. 脚本执行结束,第二张图才开始下载。
2. 页面加载之后,至少5秒页面无任何内
容显示。
影响的主要方面
阻塞页面资源的并行下载
阻塞页面的逐步渲染
影响的主要原因
保持执行顺序
对 document.write 的依赖关系
问题的解决方案
将内联脚本移至底部。
使用异步回调。
使用 script 的 defer 属性。
将内联脚本移至底部
避免了下载阻塞,实现了并行下载。
此方法适用于:执行时间小于 300毫秒的
内联脚本。
无法解决阻塞页面的逐步渲染的问题。
使用异步回调
使用异步回调: setTimeout
最简单的异步调用就是使用
setTimeout:
使用异步回调: setTimeout
避免了下载阻塞,实现了并行下载。
在 Internet Explorer 中实现了逐步渲染。
Firefox中依旧阻塞页面的逐步渲染。
使用异步回调: setTimeout
Firefox中将毫秒数增加到250毫秒,也可实
现页面的逐步渲染。
Note: 神奇数字 250源于 nglayout.initialpaint.delay(“显
示页面之前的等待毫秒数”) 的默认值。如果 longCode 在250
毫秒之前就开始执行,所有渲染在它执行完毕之前都会被阻塞,
如果我们等待250毫秒之后再调用 longCode,Firefox 就能渲染
页面顶部的文本。
使用异步回调: setTimeout
在这两种情况下(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 属性(不提倡) 。