无线页面的开发在我们的日常工作中越来越重要，无线的性能也是我们需要重点关注的，而加载的性能又是无线性能中的一个重要问题。那么，今天我们一起来看下如何去评估、测试无线页面的加载性能。
为了方便分析页面的加载过程，这里将网络设置成最慢的 GPRS，并将加载过程录制下来，通常你可以通过 Chrome 自带的 timeline， 勾选 screenhot，可以得到详尽的过程，如下图：
这里为了和请求一一清晰对照，用额外录屏工具（ licecap ）录制下来。下文以淘宝双 11 男装分会场的预发页面作为测试，录制 结果 gif 如下，录制的 FPS 为 8。
帧分析如下：
第一帧：重新刷新页面，发起 HTML 请求，中间完整页面是刷新前的，请无视之。
终于等到第 7 帧，HTML 加载并解析完成，发出页面中的请求，同时 CSS/JS 的地址都收敛在 //g.alicdn.com 同一个域名下， Chrome 下 HTTP 1.1 协议下一个域名下支持 6 个并发。
1 年前，PC 上以前还有多个域名分区（img01－04.tbcdn.cn），PC 上首屏图片多，这样可并发更多，但更多的域名引入，也加大了域名解析的成本，权衡之下淘宝之前图片域名选择了 4 个；后来集团经过轰轰烈烈的 HTTPS 改造，图片推荐收敛到 gw.alicdn.com ；手淘下现在使用 SPDY + HTTPS，相比 HTTP 1.1 ，更安全且可以多路复用。
到第 20 帧， CSS 下载完，DOM 和 CSSOM 都准备 OK 了，页面则开始渲染了；这是在 Chrome 下面看到的情况，但在 iOS 上并非如此，它需要 JS 加载并执行完才渲染页面。
第 21 帧，紧接着，CSS 中的背景图开始相继渲染，可见 CSS 中渲染图片也是有点耗时的。
第 23 帧，前面并行下载的 JS 都下载完，也开始执行了，看“疯狂 top 榜”是 JS 抽取出来的。同时 aplus 请求也开始请求，这是个 getScript 的异步请求，可见异步请求真没有阻塞页面的渲染。
第 25 帧，JS 还在继续执行，第一张图片是 JS 根据当前 dpr、强弱网络、设备宽度等算出最适合的图片开始加载这张大 banner 了，并且开始发送数据请求了。
到 27 帧，终于数据请求回来了，并且把文字和图片渲染到页面上了。
然后下一帧 28，开始请求商品图片了。
到 45 帧，6 个图片都在并发请求，同上 gw.alicdn.com 同一个域下并发 6 个请求。但首屏除了大图外只有 4 张图（2 张商家 logo 被底部 bar 挡住了），这里发出了 6 个图片请求，可见这个页面的懒加载的 buffer 值可以设置得更小。
从 28 帧到 50 帧，经历了很长的时间，第一张图片终于显示出来了。另外看到 aplus_v2 执行完后，又发起了 spm 等请求，后面 3 个请求（ aplus-proxy.html/isproxy.js/m.gif ）还是串行的。
最后到第 61 帧，终于所有的图片都加载完了，最后看下，最后下载完的是大 banner 图，因为有 46.9k ，这张图的大小可能成为此页面的 load 时间的关键；如果这张图没有这么大，最后下载完的可能是用于埋点的 m.gif。
从上面整个请求的瀑布流分析下来，我们来回顾下页面的关键时间点：
页面可见时间
在第 20 帧页面可见，CSS 完成之后，当然前提是这里没有外链 JS 在页面中间因为网络请求严重阻塞页面。这里分析的仅仅是 Chrome 浏览器，不是真机，在 iOS 上，就算 JS 在底部，直接 <script src="xx"> 也是会阻塞页面。可以通过加 async 属性，通知渲染引擎这是不影响页面渲染的 JS，可以异步加载，iOS 下添加此属性可实现和 Android 或 PC Chrome 一样的效果。
重要内容可见时间
重要内容可见，这里可以认为是商品数据，商品数据可见要等 JS 执行完并且异步请求发送出去回来后才可见。
TMS[1] 的异步请求大多走招商数据平台（TCE[2]）的接口，测试其单个请求在真机的耗时约为 110ms（样本较少，未大量测试）。
白屏时间和补救方法
在 Wi-Fi 下，这 60 多帧的过程一眨眼就过去了，但在弱网络下，如这里最极端的网络 GPRS 下，整个首屏含图片全部加载完成需要 41.25s。当然这 40 多秒过程能尽早出现内容，并渐进和谐地呈现出来是比较好的。
男装频道是修改过后的，对比之前的未处理的猜你喜欢页面，出现长时间的白屏，如下：
以下为本地生活修复后的效果：
白屏处理只要稍微注意下就可以，修复的方便也简单，尽量同步输出，异步输出请尽量 mock 出现在首屏的模板。如果是基于 Cake[3] 工具开发的，也可以直接用首屏填充伪标签。
结束语
以上在 Chrome 上的测试，但实际在手淘里面，在 spdy、https、离线包内置资源等的影响下，它的瀑布流还是这样的吗？
注：
- [1]: TMS 为淘宝内部运营活动系统。
- [2]: TCE 为淘宝内部数据接口系统。
- [3]: Cake 为淘宝内部前端开发套件。
