页面白屏与瀑布流分析方法

enter image description here

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

为了方便分析页面的加载过程,这里将网络设置成最慢的 GPRS,并将加载过程录制下来,通常你可以通过 Chrome 自带的 timeline, 勾选 screenhot,可以得到详尽的过程,如下图:

enter image description here

这里为了和请求一一清晰对照,用额外录屏工具( licecap )录制下来。下文以淘宝双 11 男装分会场的预发页面作为测试,录制 结果 gif 如下,录制的 FPS 为 8。

帧分析如下:

第一帧:重新刷新页面,发起 HTML 请求,中间完整页面是刷新前的,请无视之。

enter image description here

终于等到第 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 ,更安全且可以多路复用。

enter image description here

到第 20 帧, CSS 下载完,DOM 和 CSSOM 都准备 OK 了,页面则开始渲染了;这是在 Chrome 下面看到的情况,但在 iOS 上并非如此,它需要 JS 加载并执行完才渲染页面。

enter image description here

第 21 帧,紧接着,CSS 中的背景图开始相继渲染,可见 CSS 中渲染图片也是有点耗时的。

enter image description here

第 23 帧,前面并行下载的 JS 都下载完,也开始执行了,看“疯狂 top 榜”是 JS 抽取出来的。同时 aplus 请求也开始请求,这是个 getScript 的异步请求,可见异步请求真没有阻塞页面的渲染。

enter image description here

第 25 帧,JS 还在继续执行,第一张图片是 JS 根据当前 dpr、强弱网络、设备宽度等算出最适合的图片开始加载这张大 banner 了,并且开始发送数据请求了。

enter image description here

到 27 帧,终于数据请求回来了,并且把文字和图片渲染到页面上了。

enter image description here

然后下一帧 28,开始请求商品图片了。

enter image description here

到 45 帧,6 个图片都在并发请求,同上 gw.alicdn.com 同一个域下并发 6 个请求。但首屏除了大图外只有 4 张图(2 张商家 logo 被底部 bar 挡住了),这里发出了 6 个图片请求,可见这个页面的懒加载的 buffer 值可以设置得更小。

enter image description here

从 28 帧到 50 帧,经历了很长的时间,第一张图片终于显示出来了。另外看到 aplus_v2 执行完后,又发起了 spm 等请求,后面 3 个请求( aplus-proxy.html/isproxy.js/m.gif )还是串行的。

enter image description here

最后到第 61 帧,终于所有的图片都加载完了,最后看下,最后下载完的是大 banner 图,因为有 46.9k ,这张图的大小可能成为此页面的 load 时间的关键;如果这张图没有这么大,最后下载完的可能是用于埋点的 m.gif。

enter image description here

从上面整个请求的瀑布流分析下来,我们来回顾下页面的关键时间点:

页面可见时间

在第 20 帧页面可见,CSS 完成之后,当然前提是这里没有外链 JS 在页面中间因为网络请求严重阻塞页面。这里分析的仅仅是 Chrome 浏览器,不是真机,在 iOS 上,就算 JS 在底部,直接