[原生js] 页面白屏与瀑布流分析方法

jack

[size=0.83em]1.jpg (171.71 KB, 下载次数: 0)
下载附件  [url=]保存到相册[/url]

[color=rgb(153, 153, 153) !important]前天 11:09 上传

　　无线页面的开发在我们的日常工作中越来越重要，无线的性能也是我们需要重点关注的，而加载的性能又是无线性能中的一个重要问题。那么，今天我们一起来看下如何去评估、测试无线页面的加载性能。

　　为了方便分析页面的加载过程，这里将网络设置成最慢的 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、离线包内置资源等的影响下，它的瀑布流还是这样的吗?