阿里無線前端性能優化指南 (Pt.1 加載期優化)

前言

阿里無線前端團隊在過去一年對所負責業務進行了全面的性能優化。以下是我們根據實際經驗總結的優化指南，希望對大家有所幫助。

第一部分僅包括數據加載期優化。

圖片控制

對于網頁特別是電商類頁面來說，圖片通常會占據了大量的視覺空間,是頁面中最為重要的展現內容，并且占據網頁傳輸字節的大部分。因此，對圖片的優化是我們性能優化的重點.

啟用WebP

WebP是一種支持有損壓縮和無損壓縮的圖片文件格式，派生自視頻編碼格式 VP8。根據 Google 官方的數據，無損壓縮后的 WebP 比 PNG 文件少了 26％ 的文件大小，有損壓縮在具有同等SSIM索引的情況下WebP 比 JPEG 文件少25-34%的文件大小。WebP支持無損透明度（也叫做alpha通道），支持動畫格式Animated WebP 。

雖然目前僅Android系統原生支持WebP格式， 但由于其對頁面性能優化的巨大意義， 我們會在頁面加載時進行環境探測, 如頁面渲染環境支持WebP我們會替換頁面中的圖片鏈接為WebP格式的版本。 如果頁面專門用于可控的客戶端內(我們能在客戶端中放置專門的WebP decoder)，就算是iOS環境我們也會啟用WebP.

優化高分屏和弱網適配

從蘋果的Retina開始，手機廠商開始越來越多的使用高像素密度顯示屏。在瀏覽器里我們的一個CSS像素往往能對應兩個或更多個設備像素，在這種環境下為了追求最好的顯示效果,我們會采用數倍于瀏覽器CSS像素標識的圖片尺寸. 這里需要注意的是，如果你采用了2x (兩倍CSS像素分辨率) 的圖片,由于水平和垂直像素都進行了加倍，最終圖片體積會增加4倍(內存占用也會增加4倍). 同理,如果你采用了3x的圖片，最終增加的傳輸體積會增至9倍.

用戶喜歡清晰絢麗的圖片， 但用戶更加痛恨打不開的頁面. 在我們的實踐中,我們最多使用2x(兩倍CSS像素分辨率)的圖片。 如果頁面專門用于可控的客戶端內，我們會根據從客戶端獲取的網絡情況替換頁面所使用的圖片資源. 在最糟糕的網絡環境(2G移動網絡)，我們甚至會采用按30%質量進行壓縮的圖片以替換原始圖片鏈接。

單張圖片大小控制

有時，如果不設限無論你如何優化糟糕的情況總會出現。在我們的實踐中, 針對圖片我們設置了單張圖片大小不超過50Kb的限制。在每次發布時,我們會對頁面圖片進行檢查, 如果圖片超過這個限制仍需要發布，就得走特別的流程了.

合理使用CSS/SVG/ICON Font替代圖片

傳統桌面Web中，針對頁面內的圖標，我們往往采用Sprite（雪碧圖）技術把多個圖標合并到一張大圖片中，針對不同的圖標顯示大圖中不同的部分。但在移動互聯網環境下, 由于設備內存有限，每使用Sprite技術展示一個圖標，都需要瀏覽器把整個大圖解碼到內存中一次，考慮到前文提到的多倍CSS像素分辨率情況, 占用的內存和解碼時間往往是可觀的。不合理的使用Sprite技術會造成移動頁面性能不升反降。

更合適的選擇是CSS3,SVG和ICON Font技術。如果你的圖標能使用這些技術繪制，在任何分辨率和縮放設置都可以提供清晰的效果并減小傳輸和內存的開銷.

對圖片進行按需加載

電商類型網站多用多圖列表頁面展現商品內容, 我們會在非WIFI網絡環境時對圖片資源進行按需加載，僅僅當圖片資源出現在首屏或隨著用戶滑動屏幕進入可見區域時，我們才進行加載. 進行這項優化的關鍵在于對全局的圖片呈現進行一層抽象,以便統一控制.

網絡請求

今天我們談論的無線頁面，很多時候已不再是傳統的"頁面"，而是一個個"單頁應用"。隨著應用復雜度的逐漸增加，所需加載的除圖片等靜態數據外，動態數據也會越來越多。如果想追求高質量的單頁應用,對這些請求的優化勢在必行.

域名收斂

如果你頁面中引入的各種資源來自不同的域名，注意每增加一個域名,都會增加一次域名解析開銷。 在復雜的國內移動互聯網網絡環境下，不同域名的解析速度可能會相差數十倍。 所以你需要有意識的收斂頁面資源所需解析的域名數, 特別是會阻塞頁面渲染的CSS,JS,Font資源。 很多性能糟糕頁面究其原因或許會是引入的資源域名解析速度很慢或完全不能正確解析。在我們的實踐中, 一個頁面所產生的域名解析數不能超過5個。

減少請求數

在優化了需要解析的域名數后，你需要關注頁面資源請求數. 如果是長期維護的產品型頁面 ，頁面中引入的靜態資源除最通用的基礎庫外需要按依賴順序進行合并壓縮. 一般是JS和CSS請求各一。 針對電商廠商多見的營銷活動頁面，我們甚至開發了工具把全部的CSS和JS資源內聯入頁面，從而實現除圖片外的其余資源One Request就能獲得.

另外，資源請求重定向也應該盡量避免,少一次重定向，少一個請求數.

文本數據的優化與壓縮

文本數據(HTML,CSS,JavaScript)的優化與壓縮分為三個階段，分別是發布準備(去除注釋,合并CSS聲明,去除不會被執行的JS 代碼塊), 編譯期壓縮(合并文件，去除空格，混淆) 和 傳輸階段壓縮( GZip ) . 這項優化的關鍵在于梳理流程確保壓縮的自動化和服務器GZip指令被正確配置。

數據接口優化與監控

隨著近兩年Web前后端分離思潮的流行與前端模板技術的發展 , 我們越來越傾向在頁面加載完成后再通過接口獲取JSON數據并在前端進行頁面渲染。這種方式帶來了頁面第一次加載速度的提升，但常常把原有的性能問題隱藏了起來。 需要花功夫優化的數據獲取并最終呈現時間往往被隱藏在空頁面快速呈現的表象之下。更嚴重的情況發生在需要從多個不同接口獲取數據，并且這些接口調用還存在互相依賴的情況下，一旦出現這樣的情況，頁面性能往往是不升反降的.

在我們的實踐中, 我們要求數據在后端組裝完成后再交由前端渲染，一屏中完整渲染所需數據不能來自多過一個接口。 所有數據源統一收斂到單一的接口服務層，以便進行統計和監控。