摘要
web性能的終極目標(biāo)是減少資源到客戶端的延遲,但是我們在HTTP1.0/HTTP1.1協(xié)議中經(jīng)常會遇到加載的圖片太多或者太大導(dǎo)致頁面加載完成慢的問題:圖片太多導(dǎo)致向服務(wù)器請求的次數(shù)太多,圖片太大導(dǎo)致每次請求的時間過長.
本篇將針對圖片太多或者太大總結(jié)幾種優(yōu)化方案.
一.當(dāng)圖片太多時
方案一:將圖片服務(wù)和應(yīng)用服務(wù)分離(從架構(gòu)師的角度思考)
對于這個方案對于經(jīng)驗(yàn)尚淺的我來說是考慮不多的,通過跟leader溝通,了解到這一點(diǎn),此方案是架構(gòu)師在架構(gòu)過程中必須要考慮到的.
對于服務(wù)器來說,圖片始終是最消耗系統(tǒng)資源的,如果將圖片服務(wù)和應(yīng)用服務(wù)放在同一服務(wù)器的話,應(yīng)用服務(wù)器很容易會因?yàn)閳D片的高I/O負(fù)載而崩潰,所以當(dāng)網(wǎng)站存在大量的圖片讀寫操作時,建議使用圖片服務(wù)器.
(注:圖片服務(wù)器是專門為圖片讀寫操作優(yōu)化的獨(dú)立服務(wù)器,運(yùn)行網(wǎng)站的服務(wù)器稱為應(yīng)用服務(wù)器)
另外瀏覽器在同一時間對同一域名下的資源的并發(fā)請求數(shù)目是有限制的,一般在2-6之間,超過限制數(shù)目的請求就會被阻塞.一些主流瀏覽器對 HTTP1.1 和 HTTP 1.0 的最大并發(fā)連接數(shù)目框仔，可以參考如下圖一：
圖一(來源于網(wǎng)絡(luò))
把圖片服務(wù)器與應(yīng)用服務(wù)器分開,圖片服務(wù)器采用獨(dú)立域名 ,css、js和圖片就可以并發(fā)請求了
方案二:簡單粗暴的壓縮方案
我們可以借助一些第三方軟件來進(jìn)行壓縮,比如https://tinypng.com/,壓縮后分辨率不變,肉眼看不失真
圖二
方案三:圖片懶加載
像淘寶或者京東這樣的APP頁面上有很多圖片,當(dāng)我們滑到下一屏?xí)r下一屏的圖片才會加載,這就采用了圖片懶加載的方式.
圖片懶加載,簡單來說就是在頁面渲染過程中,圖片不會一次性全部加載,會在需要的時候加載,比如當(dāng)滾動條滾動到某一個位置時觸發(fā)事件加載圖片,如下代碼:
通過js將img標(biāo)簽的data-src屬性賦值給src屬性
方案四:css Sprites
當(dāng)網(wǎng)站或者APP有大量小icon,如果上傳到圖片服務(wù)器比如CDN, 要加載所有這些小icon將增加大量請求,而CDN是按流量收費(fèi)的,這無疑將增加很多成本.
CSS Sprites 技術(shù)早已不新鮮,就是將這些小icon合并成一張圖片,只需要加載一次,每次通過background-position來控制顯示icon,這樣就可以節(jié)約大量請求,節(jié)約成本.
此方案是將網(wǎng)站上的一些小logo拼合成一個大圖,如圖
圖三(圖片來源于網(wǎng)絡(luò))
不過這也有一定的缺點(diǎn):在長期開發(fā)多人合作的項(xiàng)目中,會不好維護(hù)這些sprites,每次對icon做修改,都得相應(yīng)的改動css里background-position的值,相當(dāng)繁瑣.
方案五:將圖片壓縮成base64格式來節(jié)約請求
將圖片壓縮成base64,隨html或者css一起下載到瀏覽器,不需要額外的請求,這樣就節(jié)約了請求.
我們知道圖片在傳輸過程中是流傳輸,如果將圖片轉(zhuǎn)換成base64,實(shí)際上是變大了,并且瀏覽器在decode? base64編碼的圖片時需要耗費(fèi)很多時間的,所以如果我們選擇此種方案的話,最好選擇一些小圖片,不然得不償失,在webpack中可以設(shè)置最大多少byte的圖片壓縮成base64
圖四
針對decode base64編碼的圖片比較慢的問題,我們可以選擇使用canvas來加速.當(dāng)向canvas發(fā)出繪畫命令時,瀏覽器直接將指令發(fā)到圖形加速器而不需要開發(fā)者更多的干預(yù),硬件圖形加速器則以難以執(zhí)行的運(yùn)算速度實(shí)時繪畫和渲染圖形.因此,我們可以使用canvas來渲染base64編碼后的圖片
具體代碼如下: (代碼出處:? http://www.reibang.com/p/ea7c0ee8aa64)
