無線頁面的開發在我們的日常工作中越來越重要，無線的效能也是我們需要重點關注的，而載入的效能又是無線效能中的一個重要問題。那麼，今天我們一起來看下如何去評估、測試無線頁面的載入效能。
為了方便分析頁面的載入過程，這裡將網路設定成最慢的 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 為淘寶內部前端開發套件。