内联脚本对面性能的影响.pptx

内联脚本对页面性能的影响怿飞 / 圆心Whos this guy?怿飞 / 圆心in Taobao UEDTechnology Evangelist Front-End Engineer/mailto:blankzheng@blankzheng@案例分析/cuzillion/?ex=10100title=Inline+Scripts+Block/cuzillion/?/cuzillion/?ex=10100title=Inline+Scripts+Blockex=10100title=Inline+Scripts+Block案例分析脚本执行结束，第二张图才开始下载。页面加载之后，至少5秒页面无任何内容显示。影响的主要方面阻塞页面资源的并行下载阻塞页面的逐步渲染影响的主要原因保持执行顺序对 document.write 的依赖关系问题的解决方案将内联脚本移至底部。使用异步回调。使用 script 的 defer 属性。将内联脚本移至底部避免了下载阻塞，实现了并行下载。此方法适用于：执行时间小于 300毫秒的内联脚本。无法解决阻塞页面的逐步渲染的问题。使用异步回调使用异步回调： setTimeout 最简单的异步调用就是使用 setTimeout：使用异步回调： setTimeout避免了下载阻塞，实现了并行下载。在 Internet Explorer 中实现了逐步渲染。Firefox中依旧阻塞页面的逐步渲染。使用异步回调： setTimeoutFirefox中将毫秒数增加到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 属性（不提倡） 。