无线性能优化:页面可见时间与异步加载

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

2015/12/03 · HTML5,
JavaScript · 1
评论
·
瀑布流,
白屏

原文出处: 淘宝前端团队(FED)-
妙净
   

奥门永利误乐域 1

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

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

奥门永利误乐域 2

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

如下,录制的 FPS 为 8。

帧分析如下:

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

奥门永利误乐域 3

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

奥门永利误乐域 4

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

奥门永利误乐域 5

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

奥门永利误乐域 6

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

奥门永利误乐域 7

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

奥门永利误乐域 8

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

奥门永利误乐域 9

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

奥门永利误乐域 10

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

奥门永利误乐域 11

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

奥门永利误乐域 12

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

奥门永利误乐域 13

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

原文出处: 淘宝前端团队(FED)-
妙净
   

页面可见时间

在第 20 帧页面可见,CSS 完成之后,当然前提是这里没有外链 JS
在页面中间因为网络请求严重阻塞页面。这里分析的仅仅是 Chrome
浏览器,不是真机,在 iOS 上,就算 JS 在底部,直接 <script src=”xx”> 也是会阻塞页面。可以通过加
async 属性,通知渲染引擎这是不影响页面渲染的 JS,可以异步加载,iOS
下添加此属性可实现和 Android 或 PC Chrome 一样的效果。

奥门永利误乐域 14

重要内容可见时间

重要内容可见,这里可以认为是商品数据,商品数据可见要等 JS
执行完并且异步请求发送出去回来后才可见。

TMS\[1\]
的异步请求大多走招商数据平台(TCE\[2\])的接口,测试其单个请求在真机的耗时约为
110ms(样本较少,未大量测试)。

如何让页面尽可能早地渲染页面,页面更早可见,让白屏时间更短,尤其是无线环境下,一直是性能优化的话题。

白屏时间和补救方法

在 Wi-Fi 下,这 60
多帧的过程一眨眼就过去了,但在弱网络下,如这里最极端的网络 GPRS
下,整个首屏含图片全部加载完成需要 41.25s。当然这 40
多秒过程能尽早出现内容,并渐进和谐地呈现出来是比较好的。

男装频道是修改过后的,对比之前的未处理的猜你喜欢页面,出现长时间的白屏,如下:

奥门永利误乐域 15

以下为本地生活修复后的效果:

奥门永利误乐域 16

白屏处理只要稍微注意下就可以,修复的方便也简单,尽量同步输出,异步输出请尽量
mock 出现在首屏的模板。如果是基于 Cake\[3\]
工具开发的,也可以直接用首屏填充伪标签。

页面可见时间

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

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

奥门永利误乐域 17

layout

奥门永利误乐域 18

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

结束语

以上在 Chrome 上的测试,但实际在手淘里面,在
spdy、https、离线包内置资源等的影响下,它的瀑布流还是这样的吗?

几种异步加载方式测试

  • A. head script: 即普通的将 JS 放在 head 中或放在 body
    中间:DEMO 地址
  • B. bottom script: 即常规的优化策略,JS 放body的底部:DEMO
    地址
  • C. document.write: 以前 PC 优化少用的一种异步加载 JS 的策略:DEMO
    地址
JavaScript

function injectWrite(src){ document.write('&lt;script src="' + src +
'"&gt;&lt;/sc' + 'ript&gt;'); }

<table>
<colgroup>
<col style="width: 50%" />
<col style="width: 50%" />
</colgroup>
<tbody>
<tr class="odd">
<td><div class="crayon-nums-content" style="font-size: 13px !important; line-height: 15px !important;">
<div class="crayon-num" data-line="crayon-5a721bbc827ff070447677-1">
1
</div>
<div class="crayon-num crayon-striped-num" data-line="crayon-5a721bbc827ff070447677-2">
2
</div>
<div class="crayon-num" data-line="crayon-5a721bbc827ff070447677-3">
3
</div>
</div></td>
<td><div class="crayon-pre" style="font-size: 13px !important; line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4; -webkit-tab-size:4; tab-size:4;">
<div id="crayon-5a721bbc827ff070447677-1" class="crayon-line">
function injectWrite(src){
</div>
<div id="crayon-5a721bbc827ff070447677-2" class="crayon-line crayon-striped-line">
  document.write('&lt;script src=&quot;' + src + '&quot;&gt;&lt;/sc' + 'ript&gt;');
</div>
<div id="crayon-5a721bbc827ff070447677-3" class="crayon-line">
}
</div>
</div></td>
</tr>
</tbody>
</table>
  • D. getScript: 形如以下,也是 KISSY
    内部的getScript函数的简易实现:DEMO
    地址
JavaScript

&lt;script&gt; var script = document.createElement('script');
script.src = "//g.tbcdn.com/xx.js";
document.getElementsByTagName('head')\[0\].appendChild(script);
&lt;/script&gt;

<table>
<colgroup>
<col style="width: 50%" />
<col style="width: 50%" />
</colgroup>
<tbody>
<tr class="odd">
<td><div class="crayon-nums-content" style="font-size: 13px !important; line-height: 15px !important;">
<div class="crayon-num" data-line="crayon-5a721bbc82807359027480-1">
1
</div>
<div class="crayon-num crayon-striped-num" data-line="crayon-5a721bbc82807359027480-2">
2
</div>
<div class="crayon-num" data-line="crayon-5a721bbc82807359027480-3">
3
</div>
<div class="crayon-num crayon-striped-num" data-line="crayon-5a721bbc82807359027480-4">
4
</div>
<div class="crayon-num" data-line="crayon-5a721bbc82807359027480-5">
5
</div>
</div></td>
<td><div class="crayon-pre" style="font-size: 13px !important; line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4; -webkit-tab-size:4; tab-size:4;">
<div id="crayon-5a721bbc82807359027480-1" class="crayon-line">
&lt;script&gt;
</div>
<div id="crayon-5a721bbc82807359027480-2" class="crayon-line crayon-striped-line">
  var script = document.createElement('script');
</div>
<div id="crayon-5a721bbc82807359027480-3" class="crayon-line">
  script.src = &quot;//g.tbcdn.com/xx.js&quot;;
</div>
<div id="crayon-5a721bbc82807359027480-4" class="crayon-line crayon-striped-line">
  document.getElementsByTagName('head')[0].appendChild(script);
</div>
<div id="crayon-5a721bbc82807359027480-5" class="crayon-line">
&lt;/script&gt;
</div>
</div></td>
</tr>
</tbody>
</table>

注:

  • [1]: TMS 为淘宝内部运营活动系统。
  • [2]: TCE 为淘宝内部数据接口系统。
  • [3]: Cake 为淘宝内部前端开发套件。

 

1 赞 收藏 1
评论

奥门永利误乐域 19

测试结果

以下提到的 domReadyDOMContentLoaded 事件。

A (head script) B (bottom script) C (document.write) D (getScript) E (async) F (defer) G (async + defer)
1 PC Chrome 页面白屏长、domReady:5902.545、onLoad:5931.48 页面先显示、domReady:5805.21、onLoad:5838.255 页面先显示、domReady:5917.95、onLoad:5949.30 页面先显示、domReady:244.41、onLoad:5857.645 页面先显示、domReady:567.01、onLoad:5709.33 页面先显示、domReady:5812.12、onLoad:5845.6 页面先显示、domReady:576.12、onLoad:5743.79
2 iOS Safari 页面白屏长、domReady:6130、onLoad:6268.41 页面白屏长、domReady:5175.80、onLoad:5182.75 页面白屏长、domReady:5617.645、onLoad:5622.115 502s 白屏然后页面显示最后变更 load finish 时间、domReady:502.71、onLoad:6032.95 508s 白屏然后页面显示最后变更 load finish time domReady:508.95、onLoad:5538.135 页面白屏长、domReady:5178.98、onLoad:5193.58 556s 白屏然后页面显示最后变更 load finish 时间、domReady:556、onLoad:5171.95
3 iOS 手淘 WebView 页面白屏长、页面出现 loading 消失、domReady: 5291.29、onLoad:5292.78 页面白屏长、页面未跳转 loading 消失、domReady: 5123.46、onLoad:5127.85 页面白屏长、页面未跳转 loading 消失、domReady: 5074.86、onLoad:5079.875 页面可见快、loading 消失快在 domReady 稍后、domReady:14.06、load finish:5141.735 页面可见快、loading 消失快在 domReady 稍后、domReady:13.89、load finish:5157.15 页面白屏长、loading 先消失再出现页面、domReady: 5132.395、onLoad:5137.52 页面可见快、然后 loading 消失、domReady:13.49、load finish:5124.08
4 Android browser 页面白屏长、domReady: 5097.29、onLoad:5100.37 页面白屏长、domReady: 5177.48、onLoad:5193.66 页面白屏长、domReady: 5125.96、onLoad:5165.06 页面可见快、等 5s 后更新 load finish 时间 domReady:463.33、load finish:5092.90 页面可见快、等 5s 后更新 load finish 时间 domReady:39.34、load finish:5136.55 页面白屏长、domReady: 5092.45、onLoad:5119.81 页面可见快、等 5s 后更新 load finish 时间 domReady:50.49、load finish:5507.668
5 Android 手淘 WebView 白屏时间长、一直 loading 直接页面可见、domReady:5058.91、onLoad:5073.81 页面立即可见、loading 消失快、等 5s 后更新 domReady 时间和 load 时间 domReady:4176.34、onLoad:4209.50 页面立即可见、loading 消失快、domReady:6011.18、onLoad:6031.93 页面可见快、loading 之后消失、等 5s 后更新 load finish 时间 domReady:36.31、load finish:5081.76 页面可见快、loading 随后消失、等 5s 后更新 load finish 时间 domReady:25.11、load finish:5113.81 页面可见快、loading 随后消失、等 5s 后更新 domReady 时间和 load 时间 domReady:5213.11、load finish:5312.19 页面可见快、loading 随后消失、等 5s 后更新 load finish 时间 domReady:89.67、load finish:5589.95

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

  • 横向看, 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
触发前收集到的所有请求。

奥门永利误乐域 20

经过上方测试,客户端的 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。

发表评论

电子邮件地址不会被公开。 必填项已用*标注