阿里無線前端性能優化指南 (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數據並在前端進行頁面渲染。這種方式帶來了頁面第一次加載速度的提高，但經常把原有的性能問題隱藏了起來。 須要花功夫優化的數據獲取並最終呈現時間每每被隱藏在空頁面快速呈現的表象之下。更嚴重的狀況發生在須要從多個不一樣接口獲取數據，而且這些接口調用還存在互相依賴的狀況下，一旦出現這樣的狀況，頁面性能每每是不升反降的.

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