2015年雙11手機淘寶前端技術之H5性能最佳實踐

HTML5-500.jpg

文/Tancycss

前言html

2015年是全面『無線化』的一年,在BAT(財報)幾家公司都已經超過50%的流量來自移動端,此次 雙11 更是佔到了68.67%無線交易(天貓微博)。前端

手淘中大量的業務採用H5的方式開發,H5體驗好壞全面影響着手淘的使用體驗。git

今年手機淘寶在技術上重點解決「頓」,「卡」,「慢」的問題,並提出了「521法則」 ,具體指:github

  • App內存節省50%web

  • 繪製幀率,滑動體驗提高20%chrome

  • App全鏈路實現 1S 法則後端

  • 強網(4G/Wifi)實現1S首屏(包括圖片)加載瀏覽器

  • 3G 1S首包返回緩存

  • 2G 1S建連,而且實現高複用 從底層到前端

其中1S加載完成是H5頁面須要解決的重點問題,也是難點。

下面給你們介紹咱們1年多來解決了些什麼樣的問題,以及帶來多少性能的提高。如下每一條都是手淘在無線領域得到的寶貴經驗。

系統&網絡環境(手淘2015)

首先給你們介紹一下目前手淘的環境狀況(供你們在設備兼容方面參考)。

操做系統

操做系統方面iOS佔比42.23%,Android 佔比52.38%,阿里雲OS 佔比5.29%,Windows Phone 佔比 0.1%。

687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f383738666264353537343762346333643230626139343833303065613331393163366130663832632e6a706567.jpg

iOS版本 & Android版本

iOS 系統版本佔比狀況:

  • iOS 9 49%

  • iOS 8 38%

  • iOS 7 11%

Android 系統版本對比iOS 碎片化較爲嚴重,所幸4.0如下版本佔比小於10%。

佔好比下:

  • 4.4.4版本30%

  • 4.4.2版本16%

  • 4.3版本11%

  • 4.2.2版本10%

  • 5.0版本以上10%

687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f366330313465396538353837643234303163313139343433363131333864633431613062633638352e6a706567.jpg

網絡狀況

網絡狀況方面,得力於近年的3G/4G推廣已經佔35%,2G網絡佔比15%左右。

687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f656266393437363439376261656537386161663962363332323261373362393962366261306363372e6a706567.jpg

運營商

運營商方面 中國移動佔據70%的用戶,中國聯通18.12%,中國電信11.69%。其中須要注意的是移動3G技術(TD-SCDMA)性能差設備支持少,移動4G容易在信號不理想的地段降級成2G。

687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f636539326561313630333336613939326236323939323234343933326130643331633964326132332e6a706567.jpg

收集性能數據&創建衡量標準

淘系H5頁面主要在手淘客戶端中展示,爲了瞭解H5頁面在客戶端中的性能表現,咱們在WebView容器中作了大量性能數據的採集,以頁面,數據接口,單個靜態資源爲維度採集。

H5頁面:咱們以WebView的DidFinishLoad事件觸發做爲完成加載(Fully Loaded)的時間。

同時對支持performance.timing的設備收集Timing數據,用於詳細分析網絡請求各階段的性能消耗狀況。

WebViewDidFinishLoad 官方解釋:Sent after a web view finishes loading a frame. Android iOS

1年前H5性能情況

針對幾個主要的業務,咱們將收集到的用戶性能數據整理後獲得如下的結果(部分業務按傳統的網頁性能優化方法優化過)。

687474703a2f2f696d67322e746263646e2e636e2f4c312f3436312f312f616434376338626136343963636233326466333466633437343838643865633731633636633639652e6a706567.jpg

性能狀況很是不理想,不達標嚴重。2G下大於10s的佔比在50%, 3G:6s內的低於70%近一半。

傳統優化

看到上面的性能狀況,咱們最早想到的優化方法就是PC時代YAHOO 23條web性能優化軍規

首先看看咱們平常業務的請求瀑布圖是怎麼樣的,根據這些狀況看那些能夠用規則去優化。

687474703a2f2f696d67322e746263646e2e636e2f4c312f3436312f312f303066633730656463306235363565323039643737353163386339386465653762626638313939322e6a706567.jpg

請求數優化

  • 在請求數控制方面,將js,css各用combo的方式合併成單個資源。

  • 頁面圖片等等,只加載首屏資源,提高首屏展現速度。

  • 使用CSS ,SVG,ICONFONT 替換UI圖片

合理使用IconFont

iconfont對於前端來講有不少優勢:自由變化大小 矢量不失真、自由修改顏色、能夠添加一些視覺效果如 陰影、旋轉、透明度、兼容IE6。

使用現狀

目前你們都基本上從平臺上生成,生成後的文件以下:

1

2

3

4

5

6

7

@font-face {

font-family: "iconfont";

src: url('iconfont.eot'); /* IE9*/

src: url('iconfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */

url('iconfont.woff') format('woff'), /* chrome、firefox */

url('iconfont.ttf') format('truetype'), /* chrome、firefox、opera、Safari, Android, iOS 4.2+*/

url('iconfont.svg#iconfont') format('svg'); /* iOS 4.1- */ }

這樣直接引用在項目中,真實在手機上的網絡請求以下(在桌面版Chrome瀏覽器網絡中沒法看到這些請求):

687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f336466313261383037316231653165613239643265383335366366373265313731633163313662342e6a706567.jpg

這樣形成了極大的網絡帶寬的消耗,這些icon資源每每在界面渲染中佔據重要位置。

目前咱們移動端只加載ttf一個字體文件,對於較小的文件也能夠考慮base64在css文件中。

首屏多個動態接口合併請求

平常的業務中,一個頁面每每拆分出多個異步數據接口(後端開發說:解耦),甚至首屏也須要3-5個接口(如動態banner區塊,推薦內容,商品列表等),有些還有嵌套關係。

可是這些對頁面性能形成不小的影響。

687474703a2f2f696d67332e746263646e2e636e2f4c312f3436312f312f633462643964613037303337306535386164623266333761613239333033613733383732613833642e706e67.jpg

手淘中某個接口在各網絡下的請求性能,2G,3G下平均的消耗時間在2-6s完成下載。其中幾個請求性能稍差點對整個頁面影響也深遠。

687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f356265613036613730373662646165316664623438613837613361636338363264313436613430632e6a706567.jpg

禁止重定向

在咱們CaseByCase的分析中發現,頁面&靜態資源的重定向會形成巨大的性能損耗。

特別使用前端JS腳原本實現頁面跳轉的。

687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f613761353564393863343834646230313064336536323363353061373465643131393164656230312e6a706567.jpg

圖片優化

手淘的特色就是圖片多,圖片的性能好壞可不只僅影響用戶體驗哦,還直接影響着交易,錢 錢 錢…

咱們在圖片方面作了大量的優化。

使用WebP格式。

手淘2年前已經開始使用WebP格式了(主要native使用),1年前H5全面使用,其中iOS 的webview中由手淘以插件的方式支持。咱們以手淘線上真實案例來看使用webp格式的先後效果。

案例爲:線上的一個活動頁面,打開一看其中的banner 就320多KB,整個頁面加載457KB,若是就單單banner圖片換成webp格式,整個頁面的大小就只有181KB。

使用WebP前

687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f393035396161616533313263336335346336323666666632653164333632636338656238306566622e6a706567.jpg

使用WebP後

687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f646336346430396137643339353631383434376562313630623539316262356238623432306239342e6a706567.jpg

Banner部分對比

687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f336436663834313432346539336237653662333665323162363936366433363936386163393931362e6a706567.jpg

這種業務類型的案例,咱們改進一下就能夠爲用戶,爲公司省70%的流量費用。

商品圖片優化

商品圖片在手淘的各個產品中都是必不可少的,爲了適應不一樣業務需求的須要,咱們在CDN服務上生成各個尺寸和質量的圖片(近100個規格)。

  • q值:根據手淘網絡狀況,加載不一樣質量的商品圖片(q30,q50,q75,q90)

  • 銳化:根據須要調整圖片銳化值

  • DPI:根據設備DPI取適當尺寸商品圖片

  • 合理的使用CDN圖片尺寸能夠帶來下載圖片的性能提高,還能夠減小沒必要要的內存消耗。 咱們平常中會用到的尺寸,每浪費10像素的寬高均可以形成很大的內存資源浪費。

計算方式以下:

687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f303130623765383534333062613130633264386538363836633562653330626338633664653861612e706e67.jpg

圖片DPI 優化

根據設備DPI值和圖片質量Q值作優化,達到最優視覺體驗和加載性能(DPI高,寬高增長後可適當下降質量)。

687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f636162633238373035323461323138383536383331336236393866386336333538396466363866652e6a706567.jpg

Sprite圖片

Sprite圖片(又稱:雪碧圖)被運用在衆多使用了不少小圖標的網站上。相對於把每張小圖標以單個文件的形式引用到頁面上,Sprite圖片會只要請求一張圖片就夠了,減小了請求數提高了加載性能,還有就是方便圖標管理。但在移動互聯網時代在使用Sprite圖片須要合理利用,否則反對性能形成影響。

解碼內存消耗

Decoded in memory的計算公式: w x h x 4(寬 x 高 x 每一個像素4個字節)

若是設備DPI大於1,還須要 X DPI係數。如Retina設備X 4,RetinaHD設備X 9.

687474703a2f2f696d67322e746263646e2e636e2f4c312f3436312f312f383034303933653563636561333633356464373265313934393433633837623630373734333764322e706e67.jpg

禁止生成大圖且利用率少

因爲圖片在瀏覽器中的解碼方式,合理的生成緊湊的Sprite圖片,便可以帶來更少的請求數,又高性能低消耗。

687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f626532646133616539633161396436626264323734373065366233303238663634386561333436382e706e67.jpg

建議合併成以下:

687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f636565653536393234393934373563316139326433333639323336383761663961663066383133342e6a706567.jpg

不建議合併成以下:

687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f343036363831316166323439376632623264313333353635623065646331336232353731356633352e6a706567.jpg

結合Native優化

通過幾輪的常規前端性能優化後,頁面性能有進步,可是離目標還遠遠不夠。咱們也不斷的問本身到到底那裏慢,那裏瓶頸最大。咱們開始試着CaseByCase的分析頁以及梳理H5在手淘中的全鏈路性能消耗。

最終作了一些和native結合的優化思路。

HTTPDNS

DNS解析想必你們都知道,在傳統PC時代DNS Lookup基本在幾十ms內。而咱們經過大量的數據採集和真實網絡抓包分析(存在DNS解析的請求),DNS的消耗至關可觀,2G網絡大量5-10s,3G網絡平均也要3-5s。

案例:iPhone5s 聯通3G

687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f343234303366623363363362333334396438343564643035633065363331653538656364626538662e6a706567.jpg

687474703a2f2f696d67322e746263646e2e636e2f4c312f3436312f312f353066366630666337356331653335333763383736656364356138333534316465626632373636372e6a706567.jpg

針對這種狀況,手淘開發了一套httpdns,httpdns是面向無線端的域名解析服務,與傳統走UDP協議的DNS不一樣,httpdns基於HTTP協議。 基於HTTP的域名解析,減小域名解析部分的時間並解決DNS劫持的問題。

手淘httpdns服務在啓動的時候就會對白名單的域名進行域名解析,返回對應服務的最近ip(各運營商),端口號,協議類型,心跳 等信息。

優勢

  • 防止域名劫持

傳統DNS由Local DNS解析域名,不一樣運營商的Local DNS有不一樣的策略,某些Local DNS可能會劫持特定的域名。採用httpdns可以繞過Local DNS,避免被劫持;另外,httpdns的解析結果包含HMAC校驗,也可以防止解析結果被中間網絡設備竄改。

  • 更精準的調度

對域名解析而言,尤爲是CDN域名,解析獲得的IP應該更靠近客戶端的地區和運營商,這樣纔能有更快的網絡訪問速度。然而,因爲運營商策略的多樣性,其推送的Local DNS可能和客戶端不在同一個地區,這時獲得的解析結果可能不是最優的。httpdns可以獲得客戶端的出口網關IP,從而可以更準確地判斷客戶端的地區和運營商,獲得更精準的解析結果。

  • 更小的解析延遲和波動

在2G/3G這種移動網絡下,DNS解析的延遲和波動都比較大。就單次解析請求而言,httpdns不會比傳統的DNS更快,但經過httpdns客戶端SDK的配合,整體而言,可以顯著下降解析延遲和波動。httpdns客戶端SDK有幾個特性:預解析、多域名解析、TTL緩存和異步請求。

  • 額外的域名相關信息

傳統DNS的解析結果只有ip,httpdns的解析結果採用JSON格式,除了ip外,還支持其它域名相關的信息,好比端口、spdy協議等。利用這些額外的信息,APP能夠啓用或中止某個功能,甚至利用httpdns來作灰度發佈,經過httpdns控制灰度的比例。

SSL+SPDY協議

在通過以上的優化方案後,H5頁面的性能始終離目標還遠。在移動端建連的消耗很是大,在業界也只有SPDY 這個玩意兒比較新穎。

理論上SPDY協議能夠完成多路複用的加密全雙工通道,顯著提高非wifi環境下的網絡體驗。

687474703a2f2f696d67332e746263646e2e636e2f4c312f3436312f312f336132323433323437663262656333373764326432326135633730346537356666623438646263362e6a706567.jpg

  • 多路複用請求優化

  • 服務器推送技術

  • SPDY壓縮http頭

看着很牛逼的技術,可是等咱們第一期上線後發現,從數據上幾乎察覺不了變化。

域名收斂

域名收斂是指儘可能控制一個頁面中使用的域名數量。爲何要這麼作呢?咱們前面提到DNS解析,減小域名數量能夠下降DNS解析的成本。上文還提到SPDY協議,其中一個特性就是複用請求,使用同一個域名能夠更多的複用請求。這個PC時代正好相反,咱們原先用多個域名提高併發請求量已提高性能。

PC時代的域名數量相似這樣的

687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f346364316232346563623561396132346562363633313633663161643661316165633136646464372e6a706567.jpg

域名最終形態(建議)

  • 頁面請求 域名一個

  • 靜態資源(css,js) 一個

  • 圖片資源 一個

  • 動態數據一個

  • 數據統計一個

最終結合SSL+SPDY+域名收斂 才發揮出真正的做用。下圖是各網絡下SSL 和 非SSL 的性能狀況。

68747470733a2f2f67772e616c6963646e2e636f6d2f7470732f544231423433414b465858585862495870585858585858585858582d323332362d313134362e6a7067.jpg

68747470733a2f2f67772e616c6963646e2e636f6d2f7470732f5442314e6849774b4658585858616a5846585858585858585858582d323332362d313436322e6a7067.jpg

動態數據複用狀態

動態數據部分,相信各個公司都差很少,動態數據會有專門的API提供出來。手淘(mtop平臺)也同樣,接口總會有各類狀態,登陸失效,令牌過時,簽名失效等。手淘使用了重發請求的方式來獲取新的簽名令牌等。致使以下的狀況(始料未及):

在手淘真實環境中發現一次令牌過時,能夠形成10多秒的延遲。

687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f363937323634306163343934353934623963633762316431306333663636326265383263323939322e6a706567.jpg

手淘在啓動的時候Native已經作了不少的數據請求,這些也是mtop請求,只是由native程序發出。 咱們判斷到頁面是在手淘客戶端中就會使用native發出mtop數據請求,這樣就規避了令牌失效,簽名失效的問題。

直本次優化後,咱們第一次看到了很是激動人心的數據:第一次里程碑式的提高

優化前

687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f666134636139636434343164353166623537353439646263663135666262316361383036343831312e6a706567.jpg

優化後

687474703a2f2f696d67322e746263646e2e636e2f4c312f3436312f312f643334616437336464663661613037666237306562643162353466616530353834333736356137652e6a706567.jpg

預加載和離線化方案

手淘中加載H5頁面的首屏白屏時間較長,基於此,集團各BU都內部產生了離線包的方案(手淘,航旅,錢包),將靜態資源經過Hybrid的方式提早加載到本地。大量了資源預加載給H5頁面帶來了極大的提高,資源加載時間降到30ms內。

今年雙11前,針對預加載方案,在技術上解決了3個痛點:

  • 開發成本(開發方式侵入性強)

  • 靜態資源解Combo

  • 更新到達率

關於 預加載&離線化方案詳細技術細節不少,這裏先簡單闡述這個功能帶來的性能提高價值。

下圖案例:

  • 第一個HTML沒有預加載,阻塞頁面時間較長

  • 靜態資源部分幾ms 級別加載,加載性能很是好

687474703a2f2f696d67332e746263646e2e636e2f4c312f3436312f312f643335336137653630383635636438643466393636346331326462353365393936303737326263332e6a706567.jpg

這是第二次里程碑式的提高,3G,4G,WIFI網絡性能全面提高。

截至到這個時間點爲止,咱們個別業務的性能有了顯著的提高。如下是其中一個業務的3個性能優化節點的性能優化對比。其中10s以上加載完成的佔比大大的縮小,1s之內的佔比上升較高。

687474703a2f2f696d67332e746263646e2e636e2f4c312f3436312f312f613233323062303931323462393832666531353865666531613938326436386430613365666131352e6a706567.jpg

統計方案優化

業務數據統計在平常工做中是必不可少的部分,因統計部份量級不大,每每會忽視掉。其中咱們對一個業務CaseByCase的分析後發現。一箇中國移動 2G/3G.Edge的用戶在請求H5頁面的時候 log.mmstat.com 的日誌埋點花了近6s才加載完成。

687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f643461353364323536383662316139313264373136653361383166666636383337343362316238652e6a706567.jpg

687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f626231336364396362363438383363336431376533376134373239633139343633366139303162302e6a706567.jpg

後面咱們對數據統計部分作了Native的異步上傳。效果是這樣滴:

iOS:

687474703a2f2f696d67332e746263646e2e636e2f4c312f3436312f312f636162663861616666373539663862373033363264616132376636643061343661623434316561632e6a706567.jpg

Android:

687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f366461636632643337656433636630373437363435383865616235333033663630386165373435352e6a706567.jpg

第三次里程碑式的提高,2G網絡性能全面提高

渲染優化

  • 禁止使用iframe (阻塞父文檔onload事件)

  • 禁止使用GIF圖片實現Loading 效果 (下降CPU消耗,提高渲染性能)視頻

業務效果

前面說了這麼多性能優化,確定會有問,花了這麼多力氣,前端到客戶端到後端搞了這麼多,價值在那裏呢。業界google,amazon,microsoft都給過速度性能對業務對GMV的影響。

下面是兩個手淘中的業務在持續幾個月的性能優化後UV,跳失率,停留時間的變化。

687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f636165653230663264336434643432303832643937363839613439663739353861646534613431362e6a706567.jpg

687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f356437386636616537346663323365633439346436353666376638666538633932663135303936642e6a706567.jpg

2015 雙11 戰績

好了,說了這麼多此次雙11搞的怎麼樣呢?

687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f633562323233376166636433363732646466666238663563353431626533396464343335666430332e6a706567.jpg

687474703a2f2f696d67322e746263646e2e636e2f4c312f3436312f312f306563313435356663356463303935633963366165316136636261343333663765636531656530362e6a706567.jpg

在無線時代,H5頁面中的任意一個微小的點都會應網絡問題被放大N倍。持續分析用戶真實數據和CaseByCase的分析不一樣業務場景,才能真正找到性能瓶頸。

H5要達到極致的體驗,須要你們跳出前端的圈子,從客戶端,後端 一塊兒的角度來共同協助發揮各自的優點才能真正作到極致的體驗。後面有更多精彩等這你們。

相關文章
相關標籤/搜索