圖片懶加載徹底指導（下）

懶加載具備不少的性能優點，好比一個頁面中就要加載數百個產品圖片的電子商務公司，懶加載可使其初始頁面的加載時間獲得顯著的優化，同時還能下降傳輸帶寬。但即使如此，依然有許多公司不曾採用，這是由於他們以爲這不利於更好的用戶體驗——圖片未加載時的佔位很醜，感知等待時間久等。上一篇文章咱們詳細介紹了圖片懶加載的實現細節，因此這一篇咱們主要談談懶加載過程當中有關用戶體驗方面的一些問題。

1. 使用恰當的圖片進行佔位

佔位指的是在真實圖片加載出來以前，圖片顯示的位置上臨時應當有所填充。一般，咱們常常會看到開發者會使用純色塊來佔位，或者用一個圖片佔全部圖片的位。爲了追求使人更滿意的用戶體驗，建議能夠進行如下嘗試：

1.1 主色佔位

與千篇一概的使用一個固定顏色的色塊佔位，建議嘗試用原始圖片中的主色調進行佔位，這個策略其實已經在百度圖片和谷歌圖片的搜索結果中使用了很長一段時間了

取圖片主色看起來複雜，其實有一個簡單的實現方式：先將圖片壓縮至1x1像素，而後再擴展到圖片所需的佔位寬高。

1.2 低分辨率圖片佔位

依然延續上面主色佔位的思路，所不一樣的是，此處可嘗試使用原始圖片的一個很是低分辨率，甚至是模糊的版本做爲佔位。這樣不只看起來更爲友好，並且還能給用戶關於真實圖片一些猜想，和稍後真實圖片加載出來更爲平滑的過分。這樣的改進顯然有更好的用戶體驗。

2. 爲圖片加載增長緩衝時間

在上一篇文章中，咱們討論了觸發圖片加載的不一樣方式時，所採用的時間點都是圖片進入視窗的時間點，即在頁面滾動過程當中，圖片佔位區域的上邊緣到達視窗的下邊緣時。這樣的實現隱含了一個體驗上的瑕疵：一般用戶會快速地滾動頁面，但觸發圖片加載後到顯示在屏幕上還須要一段時間，並且採用事件綁定的實現方案出於節流的考慮，又爲事件觸發增長了一小段延遲。這些所形成的體驗效果即是：咱們滾動頁面當圖片的佔位區域出如今視窗中後，還須要再等一段時間（短則幾十毫秒）圖片纔會顯示出來，不能不說這是一個糟糕的體驗。

這裏來介紹另外一種優化的技巧：當圖片佔位距離出如今視窗中還有一段距離（好比500px）時，便開始觸發加載，這就爲了圖片爭取到了一小段預加載的時間。

對於事件綁定的觸發方式，直接進行計算就好。而使用intersection observer API的方式能夠經過配置root和rootMargin參數來設置觸發距離，詳情可參考MDN。

3. 避免內容異動

這篇文章咱們一直都默認，頁面中使用圖片的地方，即使它暫時未加載出真實的圖片，也爲他指定了佔位空間的寬和高。這麼作基於的考慮是這麼一個場景，假設咱們不爲圖片事先指定佔位空間的寬和高，那麼在它加載展現出來以前的尺寸即是0x0像素的。那麼當圖片被加載出來後，頁面原有的排版就會被圖片撐開，而致使頁面內容出現異動的體驗。

這樣突兀的感覺，對於體驗來講很不優雅。因此建議爲圖片設置肯定寬高的佔位，以免圖片忽然加載出來後產生的頁面異動。

4. 不要對全部圖片都懶加載

每當學會一個新的技術方法後，好像都會有種獲得了放之四海而皆準的靈丹妙藥，想要立馬推廣普及，而可能忽視了每種方法都有其限制條件。

假設咱們對頁面中全部圖片都施用懶加載，雖然會下降初始頁面的加載時間，但頁面頂部本應一上來就加載展現的圖片，如今須要等JavaScript執行後纔會加載。這顯然不妥，那麼到底哪些圖片應當被懶加載呢，咱們能夠依據以下一些原則：

1. 頁面首屏中涉及的圖片，不該看成懶加載。這些包括：logo，頁面營銷橫幅，頭部的一些圖片等，另外考慮到移動設備與PC桌面不一樣的顯示尺寸，那麼初始頁面首屏中包括的圖片數量也會有所不一樣，因此在判斷懶加載圖片時也要將設備類型考慮在內。
2. 任何稍微偏離頁面首屏視窗的圖片，也都不該該被懶加載。這個稍微偏離的程度，能夠根據頁面特色去進一步設置，好比上面"爲圖片加載增長緩衝時間"一節中談到的500px。
3. 對於整個頁面滿共也沒幾張圖，用懶加載也不能得到多少明顯收益的時候，也不建議使用。由於爲了懶加載那很少的幾張而增長的JavaScript代碼量，兩相抵消不划算。

5. 常見的實現庫

雖然咱們在上一篇文章中已經詳細介紹了懶加載的實現原理和過程，相信你也能依此在本身的項目中開發出懶加載功能。但使用社區成熟且通過驗證的庫來實現，或許是性價比最高的選擇，固然若是你有重複造輪子的訴求，也能夠本身動手豐衣足食。

下面羅列一些比較流行的懶加載庫做爲參考：

• yall.js
• lazysizes
• jQuery Lazy

6. 測試懶加載是否工做

當咱們實現完懶加載後，確定會想怎麼來驗證一下，頁面上的圖片是否如願以償。方法也很簡單，Chrome瀏覽器下打開開發者工具以下：

帶頁面加載完後，咱們滾動頁面，觀察請求欄中是否有新的圖片請求到來。

最後但願對你們有幫助。