經過幾輪的常規前端性能優化后，頁面性能有進步，但是離目標還遠遠不夠。我們也不斷的問自己到到底那里慢，那里瓶頸最大。我們開始試著CaseByCase的分析頁以及梳理H5在手淘中的全鏈路性能消耗。 最終做了一些和native結合的優化思路。 ## HTTPDNS DNS解析想必大家都知道，在傳統PC時代DNS Lookup基本在幾十ms內。而我們通過大量的數據采集和真實網絡抓包分析（存在DNS解析的請求），DNS的消耗相當可觀，2G網絡大量5-10s，3G網絡平均也要3-5s。 案例：iPhone5s 聯通3G [](https://camo.githubusercontent.com/058a788d258b2608ff22ad452aa95dae4ebb31ff/687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f343234303366623363363362333334396438343564643035633065363331653538656364626538662e6a706567) [](https://camo.githubusercontent.com/48d8202405c1f4742edae175ae4195f46d55739b/687474703a2f2f696d67322e746263646e2e636e2f4c312f3436312f312f353066366630666337356331653335333763383736656364356138333534316465626632373636372e6a706567) 針對這種情況，手淘開發了一套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環境下的網絡體驗。 [](https://camo.githubusercontent.com/294d646852cab2d6cf010629290c7251d464ec37/687474703a2f2f696d67332e746263646e2e636e2f4c312f3436312f312f336132323433323437663262656333373764326432326135633730346537356666623438646263362e6a706567) * 多路復用請求優化 * 服務器推送技術 * SPDY壓縮http頭 看著很牛逼的技術，但是等我們第一期上線后發現，從數據上幾乎察覺不了變化。 ## 域名收斂 域名收斂是指盡量控制一個頁面中使用的域名數量。為什么要這么做呢？我們前面提到DNS解析，減少域名數量可以降低DNS解析的成本。上文還提到SPDY協議，其中一個特性就是復用請求，使用同一個域名可以更多的復用請求。這個PC時代正好相反，我們原先用多個域名提升并發請求量已提升性能。 PC時代的域名數量類似這樣的 [](https://camo.githubusercontent.com/1f73cb08243fc3e2482114714e790cbf79105f54/687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f346364316232346563623561396132346562363633313633663161643661316165633136646464372e6a706567) ### 域名最終形態（建議） * 頁面請求 域名一個 * 靜態資源（css，js） 一個 * 圖片資源 一個 * 動態數據一個 * 數據統計一個 最終結合SSL+SPDY+域名收斂 才發揮出真正的作用。下圖是各網絡下SSL 和 非SSL 的性能情況。 [](https://camo.githubusercontent.com/e487a70f01c1e84583381babaf555de0cb35556f/687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f396337333664373266343265653966636262333963316564303864366431643065643262373339612e6a706567) ## 動態數據復用狀態 動態數據部分，相信各個公司都差不多，動態數據會有專門的API提供出來。手淘（mtop平臺）也一樣，接口總會有各種狀態，登錄失效，令牌過期，簽名失效等。手淘使用了重發請求的方式來獲取新的簽名令牌等。導致如下的情況（始料未及）： 在手淘真實環境中發現一次令牌過期，可以造成10多秒的延遲。 [](https://camo.githubusercontent.com/758fdc95c52f86d89d4b9b853a009439a1e9d6f5/687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f363937323634306163343934353934623963633762316431306333663636326265383263323939322e6a706567) 手淘在啟動的時候Native已經做了很多的數據請求，這些也是mtop請求，只是由native程序發出。 我們判斷到頁面是在手淘客戶端中就會使用native發出mtop數據請求，這樣就規避了令牌失效，簽名失效的問題。 直本次優化后，我們第一次看到了非常激動人心的數據:`第一次里程碑式的提升` `優化前` [](https://camo.githubusercontent.com/2b6b5a9819aa37d14a9b1b90bf9e01b89cc8a24d/687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f666134636139636434343164353166623537353439646263663135666262316361383036343831312e6a706567) `優化后` [](https://camo.githubusercontent.com/a7c08004b528de6650823fc5a71d4ed12fa21e56/687474703a2f2f696d67322e746263646e2e636e2f4c312f3436312f312f643334616437336464663661613037666237306562643162353466616530353834333736356137652e6a706567) ## 預加載和離線化方案 手淘中加載H5頁面的首屏白屏時間較長，基于此，集團各BU都內部產生了離線包的方案（手淘，航旅，錢包），將靜態資源通過Hybrid的方式提前加載到本地。大量了資源預加載給H5頁面帶來了極大的提升，資源加載時間降到30ms內。 今年雙11前，針對預加載方案，在技術上解決了3個痛點 * 開發成本（開發方式侵入性強） * 靜態資源解Combo * 更新到達率 關于 預加載&離線化方案詳細技術細節很多，這里先簡單闡述這個功能帶來的性能提升價值。 下圖案例： * 第一個HTML沒有預加載，阻塞頁面時間較長 * 靜態資源部分幾ms 級別加載，加載性能非常好 [](https://camo.githubusercontent.com/86ac7a72849c7ff2313219a24c90c9aaaf005484/687474703a2f2f696d67332e746263646e2e636e2f4c312f3436312f312f643335336137653630383635636438643466393636346331326462353365393936303737326263332e6a706567) `這是第二次里程碑式的提升，3G，4G，WIFI網絡性能全面提升。` 截至到這個時間點為止，我們個別業務的性能有了顯著的提升。以下是其中一個業務的3個性能優化節點的性能優化對比。其中10s以上加載完成的占比大大的縮小，1s以內的占比上升較高。 [](https://camo.githubusercontent.com/8f5896ed527e002e1e136db49e5af2b0bdc685aa/687474703a2f2f696d67332e746263646e2e636e2f4c312f3436312f312f613233323062303931323462393832666531353865666531613938326436386430613365666131352e6a706567) ## 統計方案優化 業務數據統計在日常工作中是必不可少的部分，因統計部分量級不大，往往會忽視掉。其中我們對一個業務CaseByCase的分析后發現。一個中國移動?2G/3G.Edge的用戶在請求H5頁面的時候?log.mmstat.com?的日志埋點花了近`6s`才加載完成。 [](https://camo.githubusercontent.com/e6afbf6af8119b7fc9c69f4b15a4e20e6d4c5651/687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f643461353364323536383662316139313264373136653361383166666636383337343362316238652e6a706567) [](https://camo.githubusercontent.com/ca9a49b3b73905f6e845adfb16818532c3e9a996/687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f626231336364396362363438383363336431376533376134373239633139343633366139303162302e6a706567) 后面我們對數據統計部分做了Native的異步上傳。效果是這樣滴： iOS： [](https://camo.githubusercontent.com/507e83bcfcd5baff314e06777ee34d6961529fb5/687474703a2f2f696d67332e746263646e2e636e2f4c312f3436312f312f636162663861616666373539663862373033363264616132376636643061343661623434316561632e6a706567) Android： [](https://camo.githubusercontent.com/00b96e2ce63cd201b0782da46fc3dfb5bd73eda8/687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f366461636632643337656433636630373437363435383865616235333033663630386165373435352e6a706567) `第三次里程碑式的提升，2G網絡性能全面提升`