内联脚本对页面性能地影响.pptxVIP

内联脚本对页面性能的影响 怿飞 / 圆心 Whos this guy? blankzheng@ 怿飞 / 圆心 Technology Evangelist Front-End Engineer in Taobao UED 案例分析 /cuzillion/?ex=10100title=Inline+Scripts+Block 案例分析 脚本执行结束，第二张图才开始下载。 页面加载之后，至少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 属性（不提倡） 。