前端圖片加載優化

圖片是界面顯示效果很重要的組成部分，圖片加載關係到用戶體驗、應用性能，優化圖片加載的經常使用策略爲：預加載和懶加載。

圖片太多致使向服務器請求的次數太多,圖片太大致使每次請求的時間過長.

 

一、預加載、懶加載

 

　　預加載：提早加載圖片，當用戶須要查看時可直接從本地緩存中渲染。

　　懶加載：懶加載的主要目的是做爲服務器前端的優化，減小請求數或延遲請求數。

　　兩種技術的本質：二者的行爲是相反的，一個是提早加載，一個是遲緩甚至不加載。

　　懶加載對服務器前端有必定的緩解壓力做用，預加載 則會增長服務器前端壓力。

 

 

二、將圖片服務和應用服務分離(從架構師的角度思考)

 

　　對於服務器來講,圖片始終是最消耗系統資源的,若是將圖片服務和應用服務放在同一服務器的話,應用服務器很容易會由於圖片的高I/O負載而崩潰,因此當網站存在大量的圖片讀寫操做時,建議使用圖片服務器.

　　(注:圖片服務器是專門爲圖片讀寫操做優化的獨立服務器,運行網站的服務器稱爲應用服務器)

　　另外瀏覽器在同一時間對同一域名下的資源的併發請求數目是有限制的,通常在2-6之間,超過限制數目的請求就會被阻塞.一些主流瀏覽器對 HTTP1.1 和 HTTP 1.0 的最大併發鏈接數目

 

 

三、簡單粗暴的壓縮方案

 

　　咱們能夠藉助一些第三方軟件來進行壓縮,好比https://tinypng.com/,壓縮後分辨率不變,肉眼看不失真

　　咱們也可使用阿里雲的壓縮，給定圖片的尺寸，在圖片後面加入壓縮規則名稱，示例以下：

　　　　https://static.iberhk.com/poster/2018/12/20181211192214157355.jpg!thumb-375

　　具體的圖片顯示規則參考以下示例圖：

　　　　

 

 

 

四、將圖片壓縮成base64格式來節約請求

 

　　將圖片壓縮成base64,隨html或者css一塊兒下載到瀏覽器,不須要額外的請求,這樣就節約了請求.

　　咱們知道圖片在傳輸過程當中是流傳輸,若是將圖片轉換成base64,其實是變大了,而且瀏覽器在decode  base64編碼的圖片時須要耗費不少時間的,因此若是咱們選擇此種方案的話,最好選擇一些小圖片,否則得不償失,在webpack中能夠設置最大多少byte的圖片壓縮成base64