阿里技术文章分享：无线性能优化：页面可见时间与异步加载_html/css_WEB-ITnose

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了阿里技术文章分享：无线性能优化：页面可见时间与异步加载_html/css_WEB-ITnose，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含10132字，纯文字阅读大概需要15分钟。

内容图文

页面可见时间

页面可见要经历以下过程：

• 解析 HTML 为 DOM，解析 CSS 为 CSSOM（CSS Object Model）
• 将 DOM 和 CSSOM 合成一棵渲染树（ render tree ）
• 完成渲染树的布局（layout）
• 将渲染树绘制到屏幕

layout

由于 JS 可能随时会改变 DOM 和 CSSOM ，当页面中有大量的 JS 想立刻执行时，浏览器下载并执行，直到完成 CSSOM 下载与构建，而在我们等待时，DOM 构建同样被阻塞。为了 JS 不阻塞 DOM 和 CSSDOM 的构建，不影响首屏可见的时间，测试几种 JS 加载策略对页面可见的影响：

几种异步加载方式测试

• A. head script: 即普通的将 JS 放在 head 中或放在 body 中间： DEMO 地址
• B. bottom script: 即常规的优化策略，JS 放 body 的底部： DEMO 地址

• C. document.write: 以前 PC 优化少用的一种异步加载 JS 的策略： DEMO 地址

  function injectWrite(src){ document.write('

• D. getScript: 形如以下，也是 KISSY 内部的 getScript 函数的简易实现： DEMO 地址

• E. 加 async 属性： DEMO 地址

• F. 加 defer 属性： DEMO 地址
• G. 同时加 async defer 属性： DEMO 地址

测试结果

以下提到的 domReady 同 DOMContentLoaded 事件。

从以上测试结果可以看出以下结论：

• 横向看， iOS Safari 和 Android browser 的在页面可见、domReady、onLoad 的时间表现一致。
• 纵向看，bottom script、document.write 和 defer 三列，可知 document.write 和 defer 无任何异步效果，可见时间、domReady、onLoad 的触发时间和 bottom script 的情况一致。
• 纵向看，async + defer 联合用和 async 的表现一致，故合并为 async。
• 纵向看，script 放页头（head script）和 script 放 body 底部（bottom script）。iOS Safari 、Android browser 和 iOS WebView 表现一致，即使 script 放在 body 的底部也无济于事，页面白屏时间长，要等到 domReady 5s 多后结束才显示页面；唯独 Android WebView 的表现和 PC 的 Chrome 一致。
• 单纯看手淘 WebView 容器中 loading 消失的时间，这个时间点 iOS 和 Android 的表现一致，即都是在 UIWebView 的 didFinishLoad 事件触发时消失。这个事件的触发可能在 domReady 之前（如：A3、B3），也可能在 domReady 之后（如：D3、E3）；这个事件触发和 JS 中的 onLoad 触发时机也没有必然的联系，可能在 onLoad 之前（如：D3、E3）也可能在 onLoad 几乎同时（如：A5）。 didiFinishLoad 到底是什么时机触发的呢，详见下章。
• 页面可见时间，getScript 方式和 async 方式页面可见都非常快，domReady 的时间触发得也非常快，客户端的 loading 在 domReady 稍后即消失。原因是因为 最后耗时的 JS 请求异步化了 ，没有阻塞浏览器的 DOM + CSSOM 构建，页面渲染完成就立刻可见了。整体看，如果 domReady 的时间快，则页面可见快；反之如果页面可见快，domReady 的时间不一定快，如 B5、B1、C1、C5、F1、F5。如果异步化耗时长的 JS，domReady 和 onLoad 的时间差距是很大的，不做任何处理 onLoad 的时间 domReady 的时间差 30ms 左右。所以在异步化的前提下，可以用 domReady 的时间作为页面可见的时间。

didFinishLoad 到底什么时候触发

didFinishLoad 是 native 定义的事件，该事件触发时手淘 loading 菊花消失，并且 windvane 中的发出请求不再收集，也就是 native 统计出的 pageLoad 时间。在用户数据平台看到的瀑布流请求，就是在 didFinishLoad 触发前收集到的所有请求。

经过上方测试，客户端的 didFinisheLoad 事件的触发和 JS 中的 domReady（DOMContentLoaded）和 onLoad 触发没有任何关联。可能在 domReady 之前或之后，也可能在 onLoad 之前或之后。

那它到底是什么时候触发呢？ iOS 官方文档 是 Sent after a web view finishes loading a frame。 结合收集的用户请求和测试，didFinishLoad 是在连续发起的请求结束之后触发，监听一段时间内无请求则触发。

所以经常会看到 data_sufei 这个 JS 文件，在有些用户的瀑布流里面有，在有些用户的又没有。原因是这个 JS 是 aplus_wap.js 故意 setTimeout 1s 后发出的，如果页面在 1s 前所有的请求都发完了则触发 didFinishLoad，后面的 data_sufei.js 的时间就不算到 pageLoad 的时间；反之如果接近 1s 页面还有图片等请求还在发，则 data_sufei.js 的时间也会被算到里面。

因此在 JS 中用 setTimeout 来延迟发送请求也有可能会影响 didFinishLoad 的时间，建议 setTimeout 的时间设置得更长一点，如 3s。

async 和 defer

script 标签上可以添加 defer 和 async 属性来优化此 script 的下载和执行。

defer ：延迟

HTML 4.0 规范，其作用是，告诉浏览器，等到 DOM+CSSOM 渲染完成，再执行指定脚本。

• 浏览器开始解析 HTML 网页
• 解析过程中，发现带有 defer 属性的 script 标签
• 浏览器继续往下解析 HTML 网页，解析完就渲染到页面上，同时并行下载 script 标签中的外部脚本
• 浏览器完成解析 HTML 网页，此时再执行下载的脚本，完成后触发 DOMContentLoaded

下载的脚本文件在 DOMContentLoaded 事件触发前执行（即刚刚读取完\<\/html>标签），而且可以保证执行顺序就是它们在页面上出现的顺序。所以 添加 defer 属性后，domReady 的时间并没有提前，但它可以让页面更快显示出来。

将放在页面上方的 script 加 defer，在 PC Chrome 下其效果相当于 把这个 script 放在底部，页面会先显示。 但对 iOS Safari 和 iOS WebView 加 defer 和 script 放底部一样都是长时间白屏。

async: 异步

HTML 5 规范，其作用是，使用另一个进程下载脚本，下载时不会阻塞渲染，并且下载完成后立刻执行。

• 浏览器开始解析 HTML 网页
• 解析过程中，发现带有 async 属性的 script 标签
• 浏览器继续往下解析 HTML 网页，解析完先显示页面并触发 DOMContentLoaded，同时并行下载 script 标签中的外部脚本
• 脚本下载完成，浏览器暂停解析 HTML 网页，开始执行下载的脚本
• 脚本执行完毕，浏览器恢复解析 HTML 网页

async 属性可以保证脚本下载的同时，浏览器继续渲染。但是 async 无法保证脚本的执行顺序。哪个脚本先下载结束，就先执行那个脚本。

如何选择 async 和 defer

• defer 可以保证执行顺序， async 不行【注：<=IE 9 defer 执行顺序有 bug，但可以 hack 】
• async 可以提前触发 domReady ， defer 不行【注：Firefox 的 defer 也可以提前触发 domready 】
• defer 在 iOS 和部分 Android 下依然阻塞渲染，白屏时间长。
• 当 script 同时加 async 和 defer 属性时，后者不起作用，浏览器行为由 async 属性决定。
• async 和 defer 的兼容性不一致，好在 async 和 defer 无线端基本都支持， async 不支持 IE 9-。 附 async 兼容性 defer 兼容性

script inject 和 async

我们通常用这种 inject script 的方式来异步加载文件，特别是以前 Sea.js 、 KISSY 的盛行时，出现大量使用 $.use 来加载页面入口文件。这种方式和 async 的一样都能异步化 JS，不阻塞页面渲染。但真的是最快的吗？

一个常见的页面如下：一个 CSS，两个异步的 JS

JS 使用 script inject 的方式测试结果如下， DEMO ：

JS 使用 async 的方式测试结果如下， DEMO ：

对比结果发现，通过

其实现在无线站点 aplus.js 可以完全用这种方式引入，既不会阻塞 DOM 和 CSSOM ，也不会延长整个页面 onLoad 时间，而不是原来的 PC 上的 script inject 方式。

如果 aplus.js 在 PC 上这么用，IE 8/IE 9 应用的是 defer 属性，不会阻塞页面渲染，但是这个 JS 需要执行完后才触发 domReady（DOMContentLoaded）事件，故在 IE 8/IE 9 下可能会影响 domReady 的时间。

最后建议

• 业务 JS 尽量异步，放 body 底部的 JS 在 iOS 上和部分 Android 是无效的，依然会阻塞首屏渲染。
• 异步的方式尽可能原生用 async ，容器（浏览器、webview 等）级别自带优化，不要通过 JS 去模拟实现，如 getScript/ajax/KISSY.use/$.use 等。
• 有顺序依赖关系的 JS 可以加 defer，不改变执行顺序，相当于放到页面底部，如 TMS head 中一时无法挪动位置的类库等。

内容总结

以上是互联网集市为您收集整理的阿里技术文章分享：无线性能优化：页面可见时间与异步加载_html/css_WEB-ITnose全部内容，希望文章能够帮你解决阿里技术文章分享：无线性能优化：页面可见时间与异步加载_html/css_WEB-ITnose所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端