隨著移動網際網路的發展，我們越發要關注移動頁面的效能最佳化，今天跟大家談談這方面的事情。先，為什麼要移動頁面進行最佳化？
縱觀目前行動網路的現狀：
移動頁面佈局越來越複雜，效果越來越炫，直接導致了檔案越來越大，下載和執行速度越來越低，而速度低會造成不良影響，據統計：
71% 的多使用者期望移動頁面跟 PC 頁面一樣快，74% 的多使用者能容忍的響應時間為 5 秒，所以我們必須保證移動端頁面有足夠的速度。
移動頁面的速度跟三個因素有關，分別是：行動網路頻寬速度，裝置效能（CPU，GPU，瀏覽器），頁面本身。
目前主流的行動網路制式為 3G：
今年，我們還看到了 4g 網路制式在快速發展，這再一次提升了移動頁面的載入速度；
而移動裝置本身，截止到目前，以 iPhon6/三星 Note4 等裝置為，智慧裝置已經變得比以往螢幕更大，CPU 、 GPU 、記憶體更靠譜。
而與其同時，瀏覽器產商也為提升頁面的速度做出了不可磨滅的努力。
網路制式供應商，手機制造商，瀏覽器產商如此給力，我們呢？我們能做什麼。
我們能做得是對移動端頁面本身最佳化，這也是我們價值的體現，所以我們必須做移動端頁面效能最佳化。
該怎麼做移動端頁面最佳化呢？
在說這個前，要提一下 PC 常用的最佳化手段：
程式碼最佳化（css 、 html 、 js 最佳化）
減少 HTTP 請求（雪碧圖，檔案合併…）
減少 DOM 節點
無阻塞（內聯 CSS，JS 置後…）
快取
…
這些手段大部分適用於移動端，這都是一些耳熟能詳的手段，今天這裡就講了，有興趣可以參考 PDI 課程《網站效能最佳化》。
今天要講的主要是一些適用於移動端的最佳化手段，現在進入正題。
先我們得關注一下一個頁面從開始到呈現完畢需要經歷什麼階段，主要有四個階段：
每個階段的主要工作如上圖所示，而我們的最佳化目標是：
下面我們來針對上面的幾個階段細說一下都有哪些最佳化手段。
先，來看看載入中有哪些最佳化手段：
1. 預載入
預載入方式有兩種：
A. 顯性載入
類似這種多使用者能明顯感知的，我把它稱為顯性載入，互動頁面都建議加上這種載入方式，它一方面能增加頁面的趣味性，另一方面能讓後續頁面體驗更流暢。
B. 隱性載入
這種在載入張圖片的時候已經預先載入了第二張圖片，從而使得頁面體驗更流暢的方式，我把它稱為隱性載入，這種方式的好處是節省流量之餘又能使得體驗增強。
2. 按需載入
按需載入是不可或缺的最佳化手段，主要有以下兩種方式：
對於這種方式，在屏載入的時候把屏的內容載入儘量，而位於屏之外的元素都只在出現在屏時才載入，很大程度地節省了流量，提升了次載入時間。
這種叫響應式載入方式，意思是利用 JS 或者 CSS 判斷解析度，從而選擇不同尺寸的圖片進行引入，這種的好處顯而易見，同樣可以加快載入速度和節省流量。
3. 壓縮圖片
對於壓縮圖片，先要提的是 jpg 檔案：
對於移動端的 JPG 檔案，有這樣的結論：
使用大尺寸大有失真壓縮比的 jpg
使用 jpegtran 進行無失真壓縮
而對於 png 有以下結論：
多彩圖片使用 png24
低彩圖片使用 png8
推薦使用 pngquant
儘量避免重定向
為什麼要儘量避免重定向呢？因為如圖：
這是一個同一網速下的測試結果，重定向之所以會比較慢，是因為它重複了域名查詢，tcp 連結，傳送請求。
5. 使用其他方式代替圖片
有兩種方式，種是：依靠 CSS 3 繪製圖片：
第二種：使用 iconfont 代替圖片
但 iconfont 不一定比圖片好，這裡做了個實驗：
對於大圖片，iconfont 並不比雪碧圖好，建議單側小尺寸圖示才使用 iconfont.
然後，針對指令碼執行中有哪些最佳化手段，這裡只提兩點：
1. 儘量避免 DataURI
DataUri 在移動端並不如它在 pc 端吃香，因為：
經測試，DataURI 要比簡單的外鏈資源慢 6 倍，生成的程式碼檔案相對圖片檔案體積沒有減少反而增大，而且瀏覽器在對這種 base64 解碼過程中需要消耗記憶體和 cpu，這個在移動端壞處特別明顯。
2. 點選事件最佳化
在移動端請適當使用 touchstart，touchend，touch 等事件代替延遲比較大的 Click 事件。 Click 之所以慢是因為 mousedown 導致的：
然後，針對渲染階段中有哪些最佳化手段，這裡也只提兩點：
1. 動畫最佳化
a）儘量使用 css3 動畫
優點：
不佔用 js 主執行緒
可利用硬體加速
瀏覽器可對動畫做最佳化
缺點：
不支援中間狀態監聽
b）適當使用 canvas 動畫
優點：
可規避渲染樹的計算渲染更快
缺點：
開發成本高，維護較麻煩。
透過對 CSS 3 動畫和 Canvas 動畫對比：
得到結論：5 個元素以內使用 css3 動畫，5 個以上使用 canvas 動畫。
c）合理使用 RAF（requestAnimationFrame）
優點：
能解決指令碼問題引起的丟幀，卡頓問題
支援中間狀態監聽
缺點：
相容問題
透過 RAF 動畫與 settimeout 動畫對比：
得到結論：不需要相容 android 4.3 瀏覽器的情況下，請使用 RAF 製作指令碼動畫
2. 高頻事件最佳化
類似 touchmove，scroll 這類的事件可導致多次渲染，對於這種事件可以透過以下手段進行最佳化：
1. 使用 requestAnimationFrame 監聽幀變化，使得在正確的時間進行渲染
2. 增加響應變化的時間間隔，減少重繪次數。
後，針對合成/繪製只提一個最佳化手段：
GPU 加速
觸發 GPU 加速的方式有：
CSS3 transitions
CSS3 3D transforms
WebGL 3D 繪製
Video
…
使用 GPU 加速前有對比實驗：
GPU 加速實際上是大幅減少了合成/繪製時間，從而大大地提高了頁面速度，但 GPU 加速有自己的缺點：
過多的 GPU 層會帶來效能開銷，主要原因是使用 GPU 加速其實是利用了 GPU 層的快取，讓渲染資源可以重複使用，所以一旦層多了，快取增大，就會引起別的效能問題。
總結
本文針對頁面呈現的四個階段提出了比較典型的最佳化手段，到後，再提醒讀者一下：其實最佳化是雙刃劍。
按需載入提升速度，但可能導致大量重繪；
Touch 響應快，但很多場景不適合；
GPU 加速效率高，但記憶體開銷大等等
Loading 會讓整體體驗流暢，但容易造成多使用者流失
圖片壓縮讓頻寬成本降低，但可能會導致視覺效果變差
類似這樣的矛盾點還有很多，請結合業務按照實際情況進行最佳化。