現(xiàn)代圖片性能優(yōu)化及體驗(yàn)優(yōu)化指南

Springboot3+微服務(wù)實(shí)戰(zhàn)12306高性能售票系統(tǒng)

download：https://www.zxit666.com/5932/

圖片資源，在我們的業(yè)務(wù)中可謂是占領(lǐng)了十分大頭的一環(huán)，特別是其對(duì)帶寬的耗費(fèi)是非常宏大的。

對(duì)圖片的性能優(yōu)化及體驗(yàn)優(yōu)化在今天就顯得尤為重要。本文，就將從各個(gè)方面論述，在各種新特性滿頭飛的今天，我們能夠如何盡可能的對(duì)我們的圖片資源，停止性能優(yōu)化及體驗(yàn)優(yōu)化。

圖片類型的選取及 Picture 標(biāo)簽的運(yùn)用
首先，從圖片的類型上而言，除了常見(jiàn)的 PNG-8/PNG-24，JPEG，GIF 之外，我們更多的關(guān)注另外幾個(gè)較新的圖片格式：

WebP
JPEG XL
AVIF
首先，經(jīng)過(guò)一張表格，快速過(guò)一下這幾個(gè)圖片，我們將從圖片類型、透明通道、動(dòng)畫(huà)、編解碼性能、緊縮算法、顏色支持、內(nèi)存占用、兼容性方面，比照它們：

Alpha 通道：圖片能否支持透明的特性首先，理解理解上述的一些參數(shù)含義：

當(dāng)然，需求指出的是，Alpha 沒(méi)有透明度的意義，不代表透明度。opacity 和 transparency 才和透明度有關(guān)，前者是不透明度，后者是透明度。比方 css 中的「opacity: 0.5」就是設(shè)定元素有 50% 的不透明度。后來(lái) Alvy Ray Smith 提出每個(gè)像素再增加一個(gè) Alpha 通道，取值為0到1，用來(lái)貯存這個(gè)像素能否對(duì)圖片有「奉獻(xiàn)」，0代表透明、1代表不透明。也就是說(shuō)，「Alpha 通道」貯存一個(gè)值，其外在表現(xiàn)是「透明度」，Alpha 和透明度沒(méi)啥關(guān)系
動(dòng)畫(huà)：很好了解，圖片能否支持多幀率動(dòng)態(tài)圖片，相似于 GIF
編解碼性能：圖像的解碼與編碼。這個(gè)很關(guān)鍵，很多人看待圖片容易無(wú)視圖片的編解碼性能，解碼圖像主要從圖像文件中讀出圖像數(shù)據(jù)，而編碼則是將圖像數(shù)據(jù)寫(xiě)入圖像文件。解碼與編碼的過(guò)程正好相反。而這兩者的性能耗時(shí)會(huì)影響我們頁(yè)面的的展現(xiàn)性能。
緊縮算法：該圖片格式能否支持緊縮，支持的話，圖片的緊縮又會(huì)分為無(wú)損緊縮與有損緊縮

有損緊縮算法是一種數(shù)據(jù)緊縮辦法，經(jīng)過(guò)此辦法緊縮、解壓的數(shù)據(jù)會(huì)與原始數(shù)據(jù)不同但是十分接近。原理是借由將次要的信息數(shù)據(jù)舍棄，犧牲一些質(zhì)量來(lái)減少數(shù)據(jù)量、進(jìn)步緊縮比
無(wú)損緊縮指數(shù)據(jù)經(jīng)過(guò)緊縮后，信息不受損失，還能完整恢復(fù)到緊縮前的原樣。無(wú)損緊縮通常用于嚴(yán)厲請(qǐng)求“經(jīng)過(guò)緊縮、解緊縮的數(shù)據(jù)必需與原始數(shù)據(jù)分歧”的場(chǎng)所。
顏色支持：會(huì)分為索引色與直接色，在過(guò)去，為了儉省存儲(chǔ)空間，并非一切圖片都能支持一切顏色值，因而存在索引色這種優(yōu)化方式。

索引顏色是一種以有限的方式管理數(shù)字圖像顏色的技術(shù)，以儉省計(jì)算機(jī)內(nèi)存和文件存儲(chǔ)，同時(shí)加速顯現(xiàn)刷新和文件傳輸。即用一個(gè)數(shù)字來(lái)代表（索引）一種顏色，在存儲(chǔ)圖片的時(shí)分，存儲(chǔ)一個(gè)數(shù)字的組合，同時(shí)存儲(chǔ)數(shù)字到圖片顏色的映射。這種方式只能存儲(chǔ)有限種顏色。索引色常見(jiàn)有1位（即黑白），8位（即灰階/256色），16位（即高彩），24位（即真彩），30/36/48位（即全彩）。
直接色運(yùn)用四個(gè)數(shù)字來(lái)代表一種顏色，這四個(gè)數(shù)字分別代表這個(gè)顏色中紅色、綠色、藍(lán)色以及透明度（即 RGBA）。如今盛行的顯現(xiàn)設(shè)備能夠在這四個(gè)維度分別支持256種變化，所以直接色能夠表示2的32次方種顏色。
內(nèi)存占用：圖片對(duì)內(nèi)存資源的占用
兼容性：影響圖片格式能否大范圍推行的中心要素之一
WebP vs JPEG XL vs AVIF: JPEG 替代之戰(zhàn)
由于傳統(tǒng)的 PNG-8/PNG-24，JPEG，GIF 各自或多或少都存在一些問(wèn)題，近些年來(lái)它們的替代計(jì)劃之爭(zhēng)也愈演愈烈，中心領(lǐng)跑者可能是 WebP、JPEG XL、AVIF。

再簡(jiǎn)單理解理解它們：

WebP
WebP 最初由 Google 在 2010 年 9 月發(fā)布，其特性總結(jié)如下：

能夠同時(shí)提供無(wú)損/有損緊縮（像 JPEG 一樣）和支持透明度（像 PNG 一樣）的圖片文件格式
支持動(dòng)畫(huà)效果（像 GIF 一樣）
WebP 主要優(yōu)勢(shì)在于有損編碼，其無(wú)損編碼的性能和緊縮比表現(xiàn)普通
WebP 的缺陷在于其編解碼性能不是特別理想
在兼容性方面，除了 IE，根本曾經(jīng)得到了全系列閱讀器支持
關(guān)于復(fù)雜的圖像（比方照片）來(lái)說(shuō)，WebP 無(wú)損編碼表現(xiàn)并不好，但有損編碼表現(xiàn)卻十分棒。相近質(zhì)量的圖片解碼速度 WebP 相距 JPEG 也曾經(jīng)相差不大了，而文件緊縮比卻能提升不少。

下圖是我之前還在 TX 的時(shí)分做的一個(gè)測(cè)試比照：

加載同樣張數(shù)的 JPEG 與 WebP 的耗時(shí)比照：

關(guān)于 WebP 圖片格式，簡(jiǎn)單做個(gè)總結(jié)：

目前 WebP 與 JPEG 相比擬，據(jù)材料考證，編碼速度慢 10 倍，解碼速度慢 1.5 倍
WebP 固然會(huì)增加額外的解碼時(shí)間，但由于大幅減少了文件體積，縮短了加載的時(shí)間，大頁(yè)面圖片量較多的場(chǎng)景下，頁(yè)面的渲染速度是有較大加快的
目前而言，是 WebP、JPEG XL、AVIF 三者中兼容性最好的
截止至（2023-02-05）的兼容性圖：

JPEG XL
JPEG XL 由結(jié)合圖像專家組（開(kāi)發(fā)原始 JPEG 規(guī)范的同一組織）于 2021 年發(fā)布，旨在成為傳統(tǒng) JPEG 的長(zhǎng)期替代品。作為一種免版稅的開(kāi)源規(guī)范，JPEG XL 的創(chuàng)立者希望其格式的開(kāi)放性可以吸收網(wǎng)絡(luò)開(kāi)發(fā)人員采用該規(guī)范，該格式的擴(kuò)展名為 .jxl，JXL 中心比特流于 2021 年 1 月凍結(jié)，文件格式于 2021 年 4 月定稿。：

其主要特性有：

與傳統(tǒng)圖像格式（例如JPEG、GIF和PNG）相比，有著更佳的效率與更豐厚的功用
全面支持廣色域和 HDR，支持 Alpha 通道，支持多幀（也就是動(dòng)畫(huà)支持）
有損緊縮時(shí)：相同的視覺(jué)質(zhì)量，比 JPEG 小約 60％。
無(wú)損緊縮時(shí)：比 PNG 減小約 35％（關(guān)于 HDR，減小 50％）。
支持無(wú)損 JPEG 轉(zhuǎn)碼，減小約 20％ 文件大小。
漸進(jìn)式解碼，專為支持不同顯現(xiàn)分辨率的響應(yīng)式加載
看看同一張圖片，相同質(zhì)量下的大小表現(xiàn)：

JPEG XL 是目前而言，最有可能全面替代傳統(tǒng)圖片格式（Gif、PNG、JPEG）的下一代規(guī)范，當(dāng)然，在今天，需求看看其兼容性：

好吧，目前的兼容有點(diǎn)離譜。Chrome 從 91 版本開(kāi)端曾經(jīng)實(shí)驗(yàn)室性質(zhì)支持了 .jxl 格式的圖片，需求經(jīng)過(guò) --enable-features=JXL 配置開(kāi)啟，遺憾的是，從 Chrome 110 開(kāi)端，Chrome 又不再支持 JPEG XL 。

有趣的是，Chrome 從 110 版本開(kāi)端中棄用了對(duì) JPEG-XL 的支持，谷歌的答復(fù)是，人們對(duì) JPEG-XL 沒(méi)有足夠的興味，并且與現(xiàn)有格式相比也沒(méi)有足夠的優(yōu)勢(shì)。谷歌之前不斷對(duì) JPEG 的支持都是實(shí)驗(yàn)性的性質(zhì)的，他們以為 JPEG XL 缺乏生態(tài)系統(tǒng)支持，并且該格式?jīng)]有足夠多的益處（相對(duì) WebP 和 AVIF）。也就是說(shuō)，目前而言，Chrome 對(duì) WebP 和 AVIF 等替代格式更感興味。
AVIF
最后，我們?cè)賮?lái)看看 AVIF 格式圖片。

AVIF 是由開(kāi)放媒體聯(lián)盟 (AOM) 開(kāi)發(fā)并于 2019 年發(fā)布的另一種最新圖像格式。該格式基于 AV1 視頻編解碼器，源自視頻幀。其特性如下：

同樣的，與傳統(tǒng)圖像格式（例如JPEG、GIF和PNG）相比，有著更佳的效率與更豐厚的功用
支持有損、無(wú)損緊縮。AVIF 文件在低保真有損圖像緊縮方面表現(xiàn)出色（比 JPEG XL 更優(yōu)）。緊縮的 AVIF 圖像保存了很高的圖片質(zhì)量，防止了惱人的緊縮偽影等問(wèn)題
相對(duì)而言，AVIF 的解碼和編碼速度不如 JPEG XL，它不支持漸進(jìn)式渲染
最后，再看看兼容性，目前（2023-02-05）它的兼容性介于 WebP 與 JPEG XL 之間
看看 CaniUse 的數(shù)據(jù)：

是 WebP vs JPEG XL vs AVIF 三者在圖片解碼上的性能表現(xiàn)：

從圖中能夠看到，關(guān)于解碼性能的比照，結(jié)果竟然是 WebP > AVIF > JPEG XL 。JPEG XL 的編解碼性能并沒(méi)有其描繪的那么強(qiáng)大。

圖片格式總結(jié)
總結(jié)一下，WebP、AVIF 和 JPEG XL 都是閱讀器不普遍支持的新型圖像格式。固然 WebP、AVIF 曾經(jīng)存在很長(zhǎng)時(shí)間，但到今天，影響它們大范圍運(yùn)用的照舊是兼容問(wèn)題。它們各自有各自的特性與優(yōu)勢(shì)，誰(shuí)能勝出仍未知曉。

固然 AVIF、JPEG XL 等新型圖片格式未得到任何閱讀器的完整支持，但是在新版本的 Chrome、Firefox 和 Edge Chromium，能夠運(yùn)用配置標(biāo)志啟用對(duì)應(yīng)圖像格式，配合 HTML 的 Picture 標(biāo)簽，我們還是能夠一定水平上對(duì)我們的圖片停止格式選擇上的優(yōu)化的。

這，就能夠引出我們要說(shuō)的第二局部 -- HTML Picture 標(biāo)簽的運(yùn)用。

Picture 元素的運(yùn)用
HTML5 標(biāo)準(zhǔn)新增了 Picture Element。那么 元素的作用是什么呢？

元素經(jīng)過(guò)包含零或多個(gè) 元素和一個(gè) 元從來(lái)為不同的顯現(xiàn)/設(shè)備場(chǎng)景提供圖像版本。閱讀器會(huì)選擇最匹配的子 元素，假如沒(méi)有匹配的，就選擇 元素的 src 屬性中的 URL。然后，所選圖像呈如今 元素占領(lǐng)的空間中。

什么意義呢？怎樣運(yùn)用 元素呢？

假定，沒(méi)有 ，只要 元素，我們想盡可能在支持一些現(xiàn)代圖片格式的閱讀器上運(yùn)用相似于上述我們提到的 WebP、AVIF 和 JPEG XL 等圖片格式，而不支持的閱讀器回退運(yùn)用常規(guī)的 JPEG、PNG 等。沒(méi)錯(cuò)，就是一種漸進(jìn)加強(qiáng)的思想，該怎樣辦呢？

只能是 JavaScript 去寫(xiě)對(duì)應(yīng)的邏輯，經(jīng)過(guò) JS 腳本停止特性查詢，動(dòng)態(tài)賦值給 的 src。

而有了 后，閱讀器將原生支持上述的一些列操作，我們來(lái)看看對(duì)應(yīng)的語(yǔ)法：

<picture>

<source src="image.avif" type="image/avif">
<source src="image.jxl" type="image/jxl">
<source src="image.webp" type="image/webp">

<img src="image.jpg" type="image/jpeg">
</picture>
上述代碼的含義是：

第 1 個(gè) source 元素指向新 AVIF 格式的圖像。假如閱讀器支持 AVIF 圖像，那么它會(huì)選擇該圖像文件。否則，它將挪動(dòng)到下一個(gè) source 元素。
第 2個(gè) source 元素指向新 JPEG XL 格式的圖像。假如閱讀器支持 JPEG XL 圖像，那么它會(huì)選擇該圖像文件。否則，它將挪動(dòng)到下一個(gè) source 元素。
第 3 個(gè) source 元素指向一張WebP 格式的圖像。假如閱讀器可以渲染 WebP 圖像，它將運(yùn)用該圖像文件。
否則閱讀器將回退到運(yùn)用 img 元素 src 屬性中的圖像文件。img 元素指向的是 JPEG 格式的圖片，它是最終的兜底計(jì)劃。
這意味著如今我們能夠在不犧牲向后兼容性的狀況下開(kāi)端運(yùn)用新的圖像格式。

簡(jiǎn)而言之， 元素的作用：

經(jīng)過(guò) 給出一系列對(duì)兼容性有所請(qǐng)求的現(xiàn)代圖片格式選項(xiàng)
經(jīng)過(guò) 給出兜底的高兼容性圖片格式選項(xiàng)
閱讀器經(jīng)過(guò)對(duì)給出的圖片格式做特性檢測(cè)，要決議加載哪個(gè) URL，user agent 檢查每個(gè) 的 srcset、media 和 type 屬性，來(lái)選擇最匹配頁(yè)面當(dāng)前規(guī)劃、顯現(xiàn)設(shè)備特征等的兼容圖像。
最終，所選圖像呈如今 元素占領(lǐng)的空間中
模塊總結(jié)
總結(jié)一下，本文對(duì)常見(jiàn)的圖片格式以及最新的幾種未被大范圍兼容的圖片格式停止的比照，它們分別是：

PNG-8/PNG-24
JPEG
GIF
WebP
JPEG XL
AVIF
其后，著重引見(jiàn)了 3 種現(xiàn)代圖片格式：WebP、JPEG XL、AVIF。相關(guān)于 JPEG 等傳統(tǒng)格式，它們?cè)陬伾憩F(xiàn)、動(dòng)畫(huà)支持、能否支持無(wú)損有損緊縮、壓損比率、編解碼性能上有著更進(jìn)一步的提升，正在成為下一階段 Web 圖像的規(guī)范。

最后，引見(jiàn)了 元素，借助它，我們能更好的完成圖片的漸進(jìn)加強(qiáng)。

適配不同的屏幕尺寸及 DPR
下一個(gè)模塊，我們來(lái)看看圖片資源如何更好的適配不同的屏幕尺寸。

這里首先會(huì)觸及一個(gè)準(zhǔn)備學(xué)問(wèn)，屏幕的 DPR 值，那么，什么是 DPR 呢？要理解 DPR，又需求曉得什么是設(shè)備獨(dú)立像素 以及 物理像素。

設(shè)備獨(dú)立像素
以 iPhone6/7/8為例，這里我們翻開(kāi) Chrome 開(kāi)發(fā)者工具：



這里的 375 * 667 表示的是什么呢，表示的是設(shè)備獨(dú)立像素（DIP），也能夠了解為 CSS 像素，也稱為邏輯像素：

設(shè)備獨(dú)立像素 = CSS 像素 = 邏輯像素

如何記憶呢？這里運(yùn)用 CSS 像從來(lái)記憶，也就是說(shuō)。我們?cè)O(shè)定一個(gè)寬度為 375px 的 div，剛好能夠充溢這個(gè)設(shè)備的一行，配合高度 667px ，則 div 的大小剛好能夠充溢整個(gè)屏幕。

物理像素
OK，那么，什么又是物理像素呢。我們到電商網(wǎng)站購(gòu)置手機(jī)，都會(huì)看一看手機(jī)的參數(shù)，以 JD 上的 iPhone7 為例：

能夠看到，iPhone7 的分辨率是 1334 x 750，這里描繪的就是屏幕實(shí)踐的物理像素。

物理像素，又稱為設(shè)備像素。顯現(xiàn)屏是由一個(gè)個(gè)物理像素點(diǎn)組成的，1334 x 750 表示手機(jī)分別在垂直和程度上所具有的像素點(diǎn)數(shù)。經(jīng)過(guò)控制每個(gè)像素點(diǎn)的顏色，就能夠使屏幕顯現(xiàn)出不同的圖像，屏幕從工廠出來(lái)那天起，它上面的物理像素點(diǎn)就固定不變了，單位為pt。

設(shè)備像素 = 物理像素

DPR（Device Pixel Ratio） 設(shè)備像素比
OK，有了上面兩個(gè)概念，就能夠順理成章引出下一個(gè)概念。DPR（Device Pixel Ratio） 設(shè)備像素比，這個(gè)與我們通常說(shuō)的視網(wǎng)膜屏（多倍屏，Retina屏）有關(guān)。

設(shè)備像素比描繪的是未縮放狀態(tài)下，物理像素和設(shè)備獨(dú)立像素的初始比例關(guān)系。

簡(jiǎn)單的計(jì)算公式：

DPR = 物理像素 / 設(shè)備獨(dú)立像素

我們套用一下上面 iPhone7 的數(shù)據(jù)（取設(shè)備的物理像素寬度與設(shè)備獨(dú)立像素寬度停止計(jì)算）：

iPhone7’s DPR = iPhone7’s 物理像素寬度 / iPhone7's 設(shè)備獨(dú)立像素寬度 = 2

750 / 375 = 2
或者是 1334 / 667 = 2
能夠得到 iPhone7 的 dpr 為 2。也就是我們常說(shuō)的視網(wǎng)膜屏幕。

視網(wǎng)膜（Retina）屏幕是蘋(píng)果公司"創(chuàng)造"的一個(gè)營(yíng)銷術(shù)語(yǔ)。 蘋(píng)果公司將 dpr > 1 的屏幕稱為視網(wǎng)膜屏幕。

在視網(wǎng)膜屏幕中，以 dpr = 2 為例，把 4(2x2) 個(gè)像素當(dāng) 1 個(gè)像素運(yùn)用，這樣讓屏幕看起來(lái)更精致，但是元素的大小自身卻不會(huì)改動(dòng)：

OK，我們?cè)賮?lái)看看 iPhone XS Max：

它的物理像素如上圖是 2688 x 1242，

它的 CSS 像素是 896 x 414，很容易得出 iPhone XS Max 的 dpr 為 3。

為不同 DPR 屏幕，提供恰當(dāng)?shù)膱D片
那么，DPR 和圖片適配有什么關(guān)系呢？

舉個(gè)例子，同樣的 CSS 像素大小下，屏幕假如有不同 DPR，同樣大小的圖片渲染出來(lái)的效果不盡相同。

我們以 dpr = 3 的手機(jī)為例子，在 300 x 389 CSS 像素大小的范圍內(nèi)，渲染 1倍/2倍/3倍 圖的效果如下：

實(shí)踐圖片所占的物理像素為 900 x 1167。
能夠看到，在高 DPR 設(shè)備下提供只要 CSS 像素大小的圖片，是十分含糊的。

因而，為了在不同的 DPR 屏幕下，讓圖片看起來(lái)都不失真，我們需求為不同 DPR 的圖片，提供不同大小的圖片。

那么，有哪些可行的處理計(jì)劃呢？

計(jì)劃一：無(wú)腦多倍圖
假定，在挪動(dòng)端假定我們需求一張 CSS 像素為 300 x 200 的圖像，思索到如今曾經(jīng)有了 dpr = 3 的設(shè)備，那么要保證圖片在 dpr = 3 的設(shè)備下也正常高清展現(xiàn)，我們最大可能需求一張 900 x 600 的原圖。

這樣，不論設(shè)備的 dpr 能否為 3，我們統(tǒng)一都運(yùn)用 3 倍圖。這樣即便在 dpr = 1，dpr = 2 的設(shè)備上，也能十分好的展現(xiàn)圖片。

當(dāng)然這樣并不可取，會(huì)形成大量帶寬的糜費(fèi)。

現(xiàn)代閱讀器，提供了更好的方式，讓我們可以依據(jù)設(shè)備 dpr 的不同，提供不同尺寸的圖片。

計(jì)劃二：媒體查詢
計(jì)劃二，我們能夠思索運(yùn)用媒體查詢。到今天，我們能夠經(jīng)過(guò)相應(yīng)的媒體查詢，得知當(dāng)前的設(shè)備的 DPR 值，這樣，我們就能夠在對(duì)應(yīng)的媒體查詢中，運(yùn)用對(duì)應(yīng)的圖片。

像是這樣：

#id {
background: url(xxx@2x.png)
}
@media (device-pixel-ratio: 2) {
#id {
background: url(xxx@2x.png)
}
}
@media (device-pixel-ratio: 3) {
#id {
background: url(xxx@3x.png)
}
}
這個(gè)計(jì)劃的缺陷在于：

要寫(xiě)的代碼可能太多了，而且，可能存在一些介于 1~2，2~3 之間的 DPR 值，不好窮舉出一切場(chǎng)景
需求留意語(yǔ)法需求的兼容性，需求添加前綴，譬如 -webkit-min-device-pixel-ratio，當(dāng)然這個(gè)能夠由 autoprefixer 輔助處理