【前端】加載的圖片太多或者太大優化方案(上)

摘要

web性能的終極目標是減小資源到客戶端的延遲,可是咱們在HTTP1.0/HTTP1.1協議中常常會遇到加載的圖片太多或者太大致使頁面加載完成慢的問題:圖片太多致使向服務器請求的次數太多,圖片太大致使每次請求的時間過長.

本篇將針對圖片太多或者太大總結幾種優化方案.

一.當圖片太多時

方案一:將圖片服務和應用服務分離(從架構師的角度思考)

對於這個方案對於經驗尚淺的我來講是考慮很少的,經過跟leader溝通,瞭解到這一點,此方案是架構師在架構過程當中必需要考慮到的.

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

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

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

圖一(來源於網絡)

把圖片服務器與應用服務器分開,圖片服務器採用獨立域名 ,css、js和圖片就能夠併發請求了

方案二:簡單粗暴的壓縮方案

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

圖二

方案三:圖片懶加載

像淘寶或者京東這樣的APP頁面上有不少圖片,當咱們滑到下一屏時下一屏的圖片纔會加載,這就採用了圖片懶加載的方式.

圖片懶加載,簡單來講就是在頁面渲染過程當中,圖片不會一次性所有加載,會在須要的時候加載,好比當滾動條滾動到某一個位置時觸發事件加載圖片,以下代碼:

經過js將img標籤的data-src屬性賦值給src屬性

方案四:css Sprites

當網站或者APP有大量小icon,若是上傳到圖片服務器好比CDN, 要加載全部這些小icon將增長大量請求,而CDN是按流量收費的,這無疑將增長不少成本.

CSS Sprites 技術早已不新鮮,就是將這些小icon合併成一張圖片,只須要加載一次,每次經過background-position來控制顯示icon,這樣就能夠節約大量請求,節約成本.

此方案是將網站上的一些小logo拼合成一個大圖,如圖

圖三(圖片來源於網絡)

不過這也有必定的缺點:在長期開發多人合做的項目中,會很差維護這些sprites,每次對icon作修改,都得相應的改動css裏background-position的值,至關繁瑣.

方案五:將圖片壓縮成base64格式來節約請求

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

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

圖四

針對decode base64編碼的圖片比較慢的問題,咱們能夠選擇使用canvas來加速.當向canvas發出繪畫命令時,瀏覽器直接將指令發到圖形加速器而不須要開發者更多的干預,硬件圖形加速器則以難以執行的運算速度實時繪畫和渲染圖形.所以,咱們可使用canvas來渲染base64編碼後的圖片

具體代碼以下: (代碼出處: http://www.jianshu.com/p/ea7c0ee8aa64)