移動前端系列——移動頁面性能優化（轉）

轉自站酷：http://www.zcool.com.cn/article/ZMzg0NDMy.html

首先，爲何要最移動頁面進行優化？

縱觀目前移動網絡的現狀，

 

 

移動頁面佈局愈來愈複雜，效果愈來愈炫，直接致使了文件愈來愈大，下載和運行速度愈來愈低，而速度低會形成不良影響，據統計：

 

 

 

71%的用戶指望移動頁面跟pc頁面同樣快，74%的用戶能容忍的響應時間爲5秒，因此咱們必須保證移動端頁面有足夠的速度。

 

移動頁面的速度跟三個因素有關，分別是：移動網絡帶寬速度，設備性能（CPU，GPU，瀏覽器），頁面自己。

 

目前主流的移動網絡制式爲3g

      

 

今年，咱們還看到了4g網絡制式在快速發展，這再一次提高了移動頁面的加載速度；

 

而移動設備自己，截止到目前，以iphong6三星Note4等設備爲首，智能設備已經變得比以往屏幕更大，CPU、GPU、內存更靠譜。

 

 

 

而與其同時，瀏覽器產商也爲提高頁面的速度作出了不可磨滅的努力，這裏你們能夠看一個視頻（http://www.iqiyi.com/w_19rsgfld99.html）

 

 

網絡制式供應商，手機制造商，瀏覽器產商如此給力，咱們呢？咱們能作什麼。

 

咱們能作得是對移動端頁面自己優化，這也是咱們專業價值的體現，因此咱們必須作移動端頁面性能優化。

 

 

該怎麼作移動端頁面優化呢？

 

在說這個前，要提一下pc經常使用的優化手段：

 

代碼優化（css、html、js優化）

 

減小HTTP請求（雪碧圖，文件合併…）

 

減小DOM節點

 

無阻塞（內聯CSS，JS置後…）

 

緩存

 

...

 

這些手段大部分適用於移動端，這都是一些耳熟能詳的手段，今天這裏就講了，有興趣能夠參考PDI課程《網站性能優化》。

 

今天要講的主要是一些適用於移動端的優化手段，如今進入正題。

 

首先咱們得關注一下一個頁面從開始到呈現完畢須要經歷什麼階段，主要有四個階段：

       

 

每一個階段的主要工做如上圖所示，而咱們的優化目標是：

 

 

下面咱們來針對上面的幾個階段細說一下都有哪些優化手段。

 

首先，來看看加載中有哪些優化手段：

 

1. 預加載

 

預加載方式有兩種：

 

A.顯性加載

 

 

相似這種用戶能明顯感知的，我把它稱爲“顯性加載”，互動頁面都建議加上這種加載方式，它一方面能增長頁面的趣味性，另外一方面能讓後續頁面體驗更流暢

 

B.隱性加載

 

 

 

這種在加載第一張圖片的時候已經預先加載了第二張圖片，從而使得頁面體驗更流暢的方式，我把它稱爲隱性加載，這種方式的好處是節省流量之餘又能使得體驗加強。

 

2.    按需加載

 

按需加載是不可或缺的優化手段，主要有如下兩種方式：

 

 

對於這種方式，在首屏加載的時候把首屏的內容加載儘可能，而位於首屏以外的元素都只在出如今首屏時才加載，很大程度地節省了流量，提高了首次加載時間。

 

      

 

這種叫響應式加載方式，意思是利用js或者css判斷分辨率，從而選擇不一樣尺寸的圖片進行引入，這種的好處顯而易見，一樣能夠加快加載速度和節省流量。

 

3.    壓縮圖片

 

對於壓縮圖片，首先要提的是jpg文件：

 

 

對於移動端的Jpg文件，有這樣的結論：

 

a.使用大尺寸大有損壓縮比的jpg

 

b.使用jpegtran進行無損壓縮

 

 

 

而對於png有如下結論：

 

a.多彩圖片使用png24

 

b.低彩圖片使用png8

 

c.推薦使用pngquant

 

 

4.儘可能避免重定向

 

爲何要儘可能避免重定向呢？由於如圖：

      

 

這是一個同一網速下的測試結果，重定向之因此會比較慢，是由於它重複了域名查找，tcp連接，發送請求。

 

5. 使用其餘方式代替圖片

 

有兩種方式，第一種是：依靠css3繪製圖片

      

 

第二種：使用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動畫

 

優勢：

 

可規避渲染樹的計算渲染更快

 

缺點：

 

開發成本高

 

維護較麻煩

 

經過對css3動畫和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會讓總體體驗流暢，但容易形成用戶流失

圖片壓縮讓帶寬成本下降，但可能會致使視覺效果變差

相似這樣的矛盾點還有不少，請結合業務按照實際狀況進行優化。

 

做者：桂花