導讀：H5體驗好壞全面影響著手淘的使用體驗，今年手淘H5提出"521法則"，從技術上重點解決“頓”，“卡”，“慢”的問題，那么“521法則”是什么。手淘性能總工 @天雪Tancy 給大家詳細講解這個法則。 前言 2015年是全面『無線化』的一年，在BAT幾家公司都已經超過50%的流量來自移動端，這次 雙11更是占到了68.67%無線交易 。 手淘中大量的業務采用H5的方式開發，H5體驗好壞全面影響著手淘的使用體驗。 今年手機淘寶在技術上重點解決“頓”，“卡”，“慢”的問題，并提出了“521法則” ,具體指： App內存節省50% 繪制幀率，滑動體驗提升20% 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%。  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%  網絡情況 網絡情況方面，得力于近年的3G/4G推廣已經占35%，2G網絡占比15%左右。 運營商 運營商方面 中國移動占據70%的用戶，中國聯通18.12%，中國電信11.69%。其中需要注意的是移動3G技術（TD-SCDMA）性能差設備支持少，移動4G容易在信號不理想的地段降級成2G。 收集性能數據&建立衡量標準 淘系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性能狀況 針對幾個主要的業務，我們將收集到的用戶性能數據整理后得到以下的結果（部分業務按傳統的網頁性能優化方法優化過）。  性能情況非常不理想，不達標嚴重。2G下大于10s的占比在50%， 3G：6s內的低于70%近一半。 傳統優化 看到上面的性能情況，我們最先想到的優化方法就是PC時代YAHOO 23條web性能優化軍規。 首先看看我們日常業務的請求瀑布圖是怎么樣的，根據這些情況看那些可以用規則去優化。  請求數優化 在請求數控制方面，將js，css各用combo的方式合并成單個資源。 頁面圖片等只加載首屏資源，提升首屏展示速度。 使用CSS ,SVG,ICONFONT 替換UI圖片 合理使用IconFont iconfont對于前端來說有很多優點：自由變化大小 矢量不失真、自由修改顏色、可以添加一些視覺效果如 陰影、旋轉、透明度、兼容IE6。 使用現狀 目前大家都基本上從平臺上生成，生成后的文件如下： ~~~ @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瀏覽器網絡中無法看到這些請求）：  這樣造成了極大的網絡帶寬的消耗，這些icon資源往往在界面渲染中占據重要位置。 目前我們移動端只加載ttf一個字體文件，對于較小的文件也可以考慮base64在css文件中。 首屏多個動態接口合并請求 日常的業務中，一個頁面往往拆分出多個異步數據接口（后端開發說：解耦），甚至首屏也需要3-5個接口（如動態banner區塊，推薦內容，商品列表等），有些還有嵌套關系。 但是這些對頁面性能造成不小的影響。  手淘中某個接口在各網絡下的請求性能，2G，3G下平均的消耗時間在2-6s完成下載。其中幾個請求性能稍差點對整個頁面影響也深遠。  禁止重定向 在我們CaseByCase的分析中發現，頁面&靜態資源的重定向會造成巨大的性能損耗。 特別使用前端JS腳本來實現頁面跳轉的。  圖片優化 手淘的特點就是圖片多，圖片的性能好壞可不僅僅影響用戶體驗哦，還直接影響著交易，錢 錢 錢… 我們在圖片方面做了大量的優化。 使用WebP格式。 手淘2年前已經開始使用WebP格式了（主要native使用），1年前H5全面使用，其中iOS 的webview中由手淘以插件的方式支持。我們以手淘線上真實案例來看使用webp格式的前后效果。 案例為：線上的一個活動頁面,打開一看其中的banner 就320多KB，整個頁面加載457KB，如果就單單banner圖片換成webp格式，整個頁面的大小就只有181KB。 使用WebP前  **使用WebP后**  Banner部分對比 這種業務類型的案例，我們改進一下就可以為用戶，為公司省70%的流量費用。 商品圖片優化 商品圖片在手淘的各個產品中都是必不可少的，為了適應不同業務需求的需要，我們在CDN服務上生成各個尺寸和質量的圖片（近100個規格）。 q值：根據手淘網絡情況，加載不同質量的商品圖片（q30,q50,q75,q90） 銳化：根據需要調整圖片銳化值 DPI：根據設備DPI取適當尺寸商品圖片 合理的使用CDN圖片尺寸可以帶來下載圖片的性能提升，還可以減少不必要的內存消耗。 我們日常中會用到的尺寸，每浪費10像素的寬高都可以造成很大的內存資源浪費。 計算方式如下：  圖片DPI 優化 根據設備DPI值和圖片質量Q值做優化，達到最優視覺體驗和加載性能（DPI高，寬高增加后可適當降低質量）。  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.  禁止生成大圖且利用率少 由于圖片在瀏覽器中的解碼方式，合理的生成緊湊的Sprite圖片，即可以帶來更少的請求數，又高性能低消耗。  建議合并成如下：  不建議合并成如下：  結合Native優化 經過幾輪的常規前端性能優化后，頁面性能有進步，但是離目標還遠遠不夠。我們也不斷的問自己到到底那里慢，那里瓶頸最大。我們開始試著CaseByCase的分析頁以及梳理H5在手淘中的全鏈路性能消耗。 最終做了一些和native結合的優化思路。 HTTPDNS DNS解析想必大家都知道，在傳統PC時代DNS Lookup基本在幾十ms內。而我們通過大量的數據采集和真實網絡抓包分析（存在DNS解析的請求），DNS的消耗相當可觀，2G網絡大量5-10s，3G網絡平均也要3-5s。 案例：iPhone5s 聯通3G   針對這種情況，手淘開發了一套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環境下的網絡體驗  多路復用請求優化 服務器推送技術 SPDY壓縮http頭 看著很牛逼的技術，但是等我們第一期上線后發現，從數據上幾乎察覺不了變化。 域名收斂 域名收斂是指盡量控制一個頁面中使用的域名數量。為什么要這么做呢？我們前面提到DNS解析，減少域名數量可以降低DNS解析的成本。上文還提到SPDY協議，其中一個特性就是復用請求，使用同一個域名可以更多的復用請求。這個PC時代正好相反，我們原先用多個域名提升并發請求量已提升性能。 PC時代的域名數量類似這樣的  域名最終形態（建議） 頁面請求 域名一個 靜態資源（css，js） 一個 圖片資源 一個 動態數據一個 數據統計一個 最終結合SSL+SPDY+域名收斂 才發揮出真正的作用。下圖是各網絡下SSL 和 非SSL 的性能情況。  動態數據復用狀態 動態數據部分，相信各個公司都差不多，動態數據會有專門的API提供出來。手淘（mtop平臺）也一樣，接口總會有各種狀態，登錄失效，令牌過期，簽名失效等。手淘使用了重發請求的方式來獲取新的簽名令牌等。導致如下的情況（始料未及）： 在手淘真實環境中發現一次令牌過期，可以造成10多秒的延遲。  手淘在啟動的時候Native已經做了很多的數據請求，這些也是mtop請求，只是由native程序發出。 我們判斷到頁面是在手淘客戶端中就會使用native發出mtop數據請求，這樣就規避了令牌失效，簽名失效的問題。 直本次優化后，我們第一次看到了非常激動人心的數據:第一次里程碑式的提升 優化前  優化后  預加載和離線化方案 手淘中加載H5頁面的首屏白屏時間較長，基于此，集團各BU都內部產生了離線包的方案（手淘，航旅，錢包），將靜態資源通過Hybrid的方式提前加載到本地。大量了資源預加載給H5頁面帶來了極大的提升，資源加載時間降到30ms內。 今年雙11前，針對預加載方案，在技術上解決了3個痛點 開發成本（開發方式侵入性強） 靜態資源解Combo 更新到達率 關于 預加載&離線化方案詳細技術細節很多，這里先簡單闡述這個功能帶來的性能提升價值。 下圖案例： 第一個HTML沒有預加載，阻塞頁面時間較長 靜態資源部分幾ms 級別加載，加載性能非常好  這是第二次里程碑式的提升，3G，4G，WIFI網絡性能全面提升。 截至到這個時間點為止，我們個別業務的性能有了顯著的提升。以下是其中一個業務的3個性能優化節點的性能優化對比。其中10s以上加載完成的占比大大的縮小，1s以內的占比上升較高。 統計方案優化 業務數據統計在日常工作中是必不可少的部分，因統計部分量級不大，往往會忽視掉。其中我們對一個業務CaseByCase的分析后發現。一個中國移動 2G/3G.Edge的用戶在請求H5頁面的時候 log.mmstat.com 的日志埋點花了近6s才加載完成。 后面我們對數據統計部分做了Native的異步上傳。效果是這樣滴： iOS： Android：  第三次里程碑式的提升，2G網絡性能全面提升 渲染優化 禁止使用iframe （阻塞父文檔onload事件） 禁止使用GIF圖片實現Loading 效果 （降低CPU消耗，提升渲染性能）視頻。 業務效果 前面說了這么多性能優化，肯定會有問，花了這么多力氣，前端到客戶端到后端搞了這么多，價值在那里呢。業界google，amazon，microsoft都給過速度性能對業務對GMV的影響。 下面是兩個手淘中的業務在持續幾個月的性能優化后UV，跳失率，停留時間的變化。  2015 雙11 戰績 好了，說了這么多這次雙11搞的怎么樣呢？