前沿

頁面效能優化包括很多方面，而其中圖片優化是其中最為重要的一環，特別是對於以圖片為主頁面而言。此次主要分享我們在手機活動頁中對於圖片的優化分享心得。

正文

話說四海八荒之內優化手段非常多，但無疑都是圍繞著這3個方向來進行優化的：縮短請求響應時間、減少請求數、減少請求大小。

縮短請求響應時間

1 域名收斂

我們明白，頁面資源請求過程是這樣的：

DNS解析 –> 請求等待 –> 傳送http請求 –> 伺服器響應 –> 接收資料

我們明白，典型的DNS解析過程是這樣的：

瀏覽器快取 –> Hosts檔案/系統快取 –> 本地域名伺服器–> 向上迭代查詢

PC端老套優化經驗告訴我們，瀏覽器針對同一個域名有併發請求數量限制，而PC頁面展示區域寬，內容豐富，圖片需求量大。為了突破這個限制，靜態資源採用多個子域名，特別是針對圖片域名，比如目前京東商城PC頁面用到的商品圖片域名就是 img10.360buyimg.com~img14.360buyimg.com。

移動端情況和PC有兩方面比較明顯的差別，一個是展示區域小，另一個是網路情況差。展示區域小意味著同時間內需要併發請求的資源相對要少，對於突破瀏覽器單域名下併發請求限制需求並不強烈。網路情況差代表著，花銷在域名解析上的時間會凸顯，特別是當請求域名在沒有被快取的情況下（比如首次訪問）。所以手機端圖片域名我們統一到了一個域名 m.360buyimg.com 上。

2 使用CDN

這個老生常談了，但是真的必須有，每個請求都儘可能訪問離自己最近的伺服器上，那麼響應時間肯定是最短的

減少請求數

1 必須快取

這個沒有太多可說的。快取了下次就不會請求了，檢查圖片響應頭設定，圖片快取時間必須非常非常非常長

2 圖片Base64編碼

這個還是簡單說下，圖片經過Base64編碼後會導致kb增大，但是針對尺寸很小的圖示，並且又不能與其他圖片合成雪碧圖的，以Base64編碼的形式使用，是一個不錯的選擇，畢竟它可以減少一個請求的開銷

3 圖片懶載入

把有限的資源請求數用在使用者能感知到的區域內。我們目前的策略是，預設只加載當前可展示區域，以及預載入可視區域下方半個或者一個螢幕（依據網路情況而定）內的圖片。有個值得注意的點就是，針對以非常快的速度劃過的區域，這塊區域不視為可視區域。而只把使用者真正在停留或者以相對較慢的翻屏速度檢視的區域，才視為需要圖片載入的區域。以避免不要的網路資源消耗。

減少請求大小

1 圖片使用限制

由於移動端網路情況相對較差，在圖片使用上，我們限制了單張圖片的大小。如果使用者上傳了大於限制kb的圖片，我們會提供一個傻瓜式的線上圖片編輯器，提供給使用者進行一鍵切圖、裁剪、壓縮等功能。從而保證原圖不是一張巨大圖

2 圖片自動壓縮

藉助於圖片伺服器自帶的降質功能，對於請求的圖片，依據網路情況請求不同降質級別的圖片。Wifi情況下請求輕度降質的圖片，而非wifi情況下請求中度降質的圖片

3 使用webp格式

webp相對於jpg可以帶來30%-50%的kb下降。針對支援的瀏覽器一律請求webp格式的圖片。目前的做法是在圖片懶載入邏輯中，通過js來判斷是否支援webp，支援的話則請求webp格式的圖片。後期準備優化為由伺服器依據圖片請求頭來進行判斷是否支援webp，支援的話則自動返回webp格式圖片，好處就是這個變成了一個自帶的基礎服務，前端就可以不用考慮這個邏輯了

4 請求動態圖片尺寸

我們的手機活動頁面裡包含的圖片大致可以分為兩種。一種是自定義圖片，典型的就是海報圖。另一種是商品圖片。自定義圖片對於圖片品質並沒有很高的要求。但商品類圖片的清晰度，會直接影響到使用者的關注度。如何做到看到的商品圖最清晰，同時又能保證良好的載入效能，我們的做法是，動態請求最合適尺寸的商品圖。這個邏輯依然是放在圖片懶載入邏輯中。
第一步，獲取裝置畫素比，通過裝置畫素比確定應該使用幾倍圖；第二步，獲取圖片在文件流中的寬高，使用此寬高乘以裝置畫素比，生成需要請求的圖片尺寸；第三步，通過原圖地址以及圖片尺寸動態生成新圖片地址，然後釋放圖片。
這樣就可以使得使用者以最小的流量成本，訪問到最清晰的商品圖片，也能夠保證相對良好的載入效能。

小結

最後的最後：任何脫離場景談技術都是妄談，找到最適合自己場景的優化方案才是最好的方案。第一次發文章，肯定有不少描述不妥之處，歡迎大家幫忙斧正，感謝~