Springboot3+微服务实战12306高性能售票系统-杨柳青青著地垂
现代图片性能优化及体验优化指南
Springboot3+微服务实战12306高性能售票系统
download：https://www.zxit666.com/5932/
图片资源，在我们的业务中可谓是占领了十分大头的一环，特别是其对带宽的耗费是非常宏大的。
对图片的性能优化及体验优化在今天就显得尤为重要。本文，就将从各个方面论述，在各种新特性满头飞的今天，我们能够如何尽可能的对我们的图片资源，停止性能优化及体验优化。
图片类型的选取及 Picture 标签的运用
首先，从图片的类型上而言，除了常见的 PNG-8/PNG-24，JPEG，GIF 之外，我们更多的关注另外几个较新的图片格式：
WebP
JPEG XL
AVIF
首先，经过一张表格，快速过一下这几个图片，我们将从图片类型、透明通道、动画、编解码性能、紧缩算法、颜色支持、内存占用、兼容性方面，比照它们：
Alpha 通道：图片能否支持透明的特性首先，理解理解上述的一些参数含义：
当然，需求指出的是，Alpha 没有透明度的意义，不代表透明度。opacity 和 transparency 才和透明度有关，前者是不透明度，后者是透明度。比方 css 中的「opacity: 0.5」就是设定元素有 50% 的不透明度。后来 Alvy Ray Smith 提出每个像素再增加一个 Alpha 通道，取值为0到1，用来贮存这个像素能否对图片有「奉献」，0代表透明、1代表不透明。也就是说，「Alpha 通道」贮存一个值，其外在表现是「透明度」，Alpha 和透明度没啥关系
动画：很好了解，图片能否支持多帧率动态图片，相似于 GIF
编解码性能：图像的解码与编码。这个很关键，很多人看待图片容易无视图片的编解码性能，解码图像主要从图像文件中读出图像数据，而编码则是将图像数据写入图像文件。解码与编码的过程正好相反。而这两者的性能耗时会影响我们页面的的展现性能。
紧缩算法：该图片格式能否支持紧缩，支持的话，图片的紧缩又会分为无损紧缩与有损紧缩
有损紧缩算法是一种数据紧缩办法，经过此办法紧缩、解压的数据会与原始数据不同但是十分接近。原理是借由将次要的信息数据舍弃，牺牲一些质量来减少数据量、进步紧缩比
无损紧缩指数据经过紧缩后，信息不受损失，还能完整恢复到紧缩前的原样。无损紧缩通常用于严厉请求“经过紧缩、解紧缩的数据必需与原始数据分歧”的场所。
颜色支持：会分为索引色与直接色，在过去，为了俭省存储空间，并非一切图片都能支持一切颜色值，因而存在索引色这种优化方式。
索引颜色是一种以有限的方式管理数字图像颜色的技术，以俭省计算机内存和文件存储，同时加速显现刷新和文件传输。即用一个数字来代表（索引）一种颜色，在存储图片的时分，存储一个数字的组合，同时存储数字到图片颜色的映射。这种方式只能存储有限种颜色。索引色常见有1位（即黑白），8位（即灰阶/256色），16位（即高彩），24位（即真彩），30/36/48位（即全彩）。
直接色运用四个数字来代表一种颜色，这四个数字分别代表这个颜色中红色、绿色、蓝色以及透明度（即 RGBA）。如今盛行的显现设备能够在这四个维度分别支持256种变化，所以直接色能够表示2的32次方种颜色。
内存占用：图片对内存资源的占用
兼容性：影响图片格式能否大范围推行的中心要素之一
WebP vs JPEG XL vs AVIF: JPEG 替代之战
由于传统的 PNG-8/PNG-24，JPEG，GIF 各自或多或少都存在一些问题，近些年来它们的替代计划之争也愈演愈烈，中心领跑者可能是 WebP、JPEG XL、AVIF。
再简单理解理解它们：
WebP
WebP 最初由 Google 在 2010 年 9 月发布，其特性总结如下：
能够同时提供无损/有损紧缩（像 JPEG 一样）和支持透明度（像 PNG 一样）的图片文件格式
支持动画效果（像 GIF 一样）
WebP 主要优势在于有损编码，其无损编码的性能和紧缩比表现普通
WebP 的缺陷在于其编解码性能不是特别理想
在兼容性方面，除了 IE，根本曾经得到了全系列阅读器支持
关于复杂的图像（比方照片）来说，WebP 无损编码表现并不好，但有损编码表现却十分棒。相近质量的图片解码速度 WebP 相距 JPEG 也曾经相差不大了，而文件紧缩比却能提升不少。
下图是我之前还在 TX 的时分做的一个测试比照：
加载同样张数的 JPEG 与 WebP 的耗时比照：
关于 WebP 图片格式，简单做个总结：
目前 WebP 与 JPEG 相比拟，据材料考证，编码速度慢 10 倍，解码速度慢 1.5 倍
WebP 固然会增加额外的解码时间，但由于大幅减少了文件体积，缩短了加载的时间，大页面图片量较多的场景下，页面的渲染速度是有较大加快的
目前而言，是 WebP、JPEG XL、AVIF 三者中兼容性最好的
截止至（2023-02-05）的兼容性图：
JPEG XL
JPEG XL 由结合图像专家组（开发原始 JPEG 规范的同一组织）于 2021 年发布，旨在成为传统 JPEG 的长期替代品。作为一种免版税的开源规范，JPEG XL 的创立者希望其格式的开放性可以吸收网络开发人员采用该规范，该格式的扩展名为 .jxl，JXL 中心比特流于 2021 年 1 月冻结，文件格式于 2021 年 4 月定稿。：
其主要特性有：
与传统图像格式（例如JPEG、GIF和PNG）相比，有着更佳的效率与更丰厚的功用
全面支持广色域和 HDR，支持 Alpha 通道，支持多帧（也就是动画支持）
有损紧缩时：相同的视觉质量，比 JPEG 小约 60％。
无损紧缩时：比 PNG 减小约 35％（关于 HDR，减小 50％）。
支持无损 JPEG 转码，减小约 20％ 文件大小。
渐进式解码，专为支持不同显现分辨率的响应式加载
看看同一张图片，相同质量下的大小表现：
JPEG XL 是目前而言，最有可能全面替代传统图片格式（Gif、PNG、JPEG）的下一代规范，当然，在今天，需求看看其兼容性：
好吧，目前的兼容有点离谱。Chrome 从 91 版本开端曾经实验室性质支持了 .jxl 格式的图片，需求经过 --enable-features=JXL 配置开启，遗憾的是，从 Chrome 110 开端，Chrome 又不再支持 JPEG XL 。
有趣的是，Chrome 从 110 版本开端中弃用了对 JPEG-XL 的支持，谷歌的答复是，人们对 JPEG-XL 没有足够的兴味，并且与现有格式相比也没有足够的优势。谷歌之前不断对 JPEG 的支持都是实验性的性质的，他们以为 JPEG XL 缺乏生态系统支持，并且该格式没有足够多的益处（相对 WebP 和 AVIF）。也就是说，目前而言，Chrome 对 WebP 和 AVIF 等替代格式更感兴味。
AVIF
最后，我们再来看看 AVIF 格式图片。
AVIF 是由开放媒体联盟 (AOM) 开发并于 2019 年发布的另一种最新图像格式。该格式基于 AV1 视频编解码器，源自视频帧。其特性如下：
同样的，与传统图像格式（例如JPEG、GIF和PNG）相比，有着更佳的效率与更丰厚的功用
支持有损、无损紧缩。AVIF 文件在低保真有损图像紧缩方面表现出色（比 JPEG XL 更优）。紧缩的 AVIF 图像保存了很高的图片质量，防止了恼人的紧缩伪影等问题
相对而言，AVIF 的解码和编码速度不如 JPEG XL，它不支持渐进式渲染
最后，再看看兼容性，目前（2023-02-05）它的兼容性介于 WebP 与 JPEG XL 之间
看看 CaniUse 的数据：
是 WebP vs JPEG XL vs AVIF 三者在图片解码上的性能表现：
从图中能够看到，关于解码性能的比照，结果竟然是 WebP > AVIF > JPEG XL 。JPEG XL 的编解码性能并没有其描绘的那么强大。
图片格式总结
总结一下，WebP、AVIF 和 JPEG XL 都是阅读器不普遍支持的新型图像格式。固然 WebP、AVIF 曾经存在很长时间，但到今天，影响它们大范围运用的照旧是兼容问题。它们各自有各自的特性与优势，谁能胜出仍未知晓。
固然 AVIF、JPEG XL 等新型图片格式未得到任何阅读器的完整支持，但是在新版本的 Chrome、Firefox 和 Edge Chromium，能够运用配置标志启用对应图像格式，配合 HTML 的 Picture 标签，我们还是能够一定水平上对我们的图片停止格式选择上的优化的。
这，就能够引出我们要说的第二局部 -- HTML Picture 标签的运用。
Picture 元素的运用
HTML5 标准新增了 Picture Element。那么 元素的作用是什么呢？
元素经过包含零或多个 元素和一个 元从来为不同的显现/设备场景提供图像版本。阅读器会选择最匹配的子 元素，假如没有匹配的，就选择 元素的 src 属性中的 URL。然后，所选图像呈如今 元素占领的空间中。
什么意义呢？怎样运用 元素呢？
假定，没有 ，只要 元素，我们想尽可能在支持一些现代图片格式的阅读器上运用相似于上述我们提到的 WebP、AVIF 和 JPEG XL 等图片格式，而不支持的阅读器回退运用常规的 JPEG、PNG 等。没错，就是一种渐进加强的思想，该怎样办呢？
只能是 JavaScript 去写对应的逻辑，经过 JS 脚本停止特性查询，动态赋值给 的 src。
而有了 后，阅读器将原生支持上述的一些列操作，我们来看看对应的语法：
<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 个 source 元素指向新 AVIF 格式的图像。假如阅读器支持 AVIF 图像，那么它会选择该图像文件。否则，它将挪动到下一个 source 元素。
第 2个 source 元素指向新 JPEG XL 格式的图像。假如阅读器支持 JPEG XL 图像，那么它会选择该图像文件。否则，它将挪动到下一个 source 元素。
第 3 个 source 元素指向一张WebP 格式的图像。假如阅读器可以渲染 WebP 图像，它将运用该图像文件。
否则阅读器将回退到运用 img 元素 src 属性中的图像文件。img 元素指向的是 JPEG 格式的图片，它是最终的兜底计划。
这意味着如今我们能够在不牺牲向后兼容性的状况下开端运用新的图像格式。
简而言之， 元素的作用：
经过 给出一系列对兼容性有所请求的现代图片格式选项
经过 给出兜底的高兼容性图片格式选项
阅读器经过对给出的图片格式做特性检测，要决议加载哪个 URL，user agent 检查每个 的 srcset、media 和 type 属性，来选择最匹配页面当前规划、显现设备特征等的兼容图像。
最终，所选图像呈如今 元素占领的空间中
模块总结
总结一下，本文对常见的图片格式以及最新的几种未被大范围兼容的图片格式停止的比照，它们分别是：
PNG-8/PNG-24
JPEG
GIF
WebP
JPEG XL
AVIF
其后，着重引见了 3 种现代图片格式：WebP、JPEG XL、AVIF。相关于 JPEG 等传统格式，它们在颜色表现、动画支持、能否支持无损有损紧缩、压损比率、编解码性能上有着更进一步的提升，正在成为下一阶段 Web 图像的规范。
最后，引见了 元素，借助它，我们能更好的完成图片的渐进加强。
适配不同的屏幕尺寸及 DPR
下一个模块，我们来看看图片资源如何更好的适配不同的屏幕尺寸。
这里首先会触及一个准备学问，屏幕的 DPR 值，那么，什么是 DPR 呢？要理解 DPR，又需求晓得什么是设备独立像素 以及 物理像素。
设备独立像素
以 iPhone6/7/8为例，这里我们翻开 Chrome 开发者工具：
这里的 375 * 667 表示的是什么呢，表示的是设备独立像素（DIP），也能够了解为 CSS 像素，也称为逻辑像素：
设备独立像素 = CSS 像素 = 逻辑像素
如何记忆呢？这里运用 CSS 像从来记忆，也就是说。我们设定一个宽度为 375px 的 div，刚好能够充溢这个设备的一行，配合高度 667px ，则 div 的大小刚好能够充溢整个屏幕。
物理像素
OK，那么，什么又是物理像素呢。我们到电商网站购置手机，都会看一看手机的参数，以 JD 上的 iPhone7 为例：
能够看到，iPhone7 的分辨率是 1334 x 750，这里描绘的就是屏幕实践的物理像素。
物理像素，又称为设备像素。显现屏是由一个个物理像素点组成的，1334 x 750 表示手机分别在垂直和程度上所具有的像素点数。经过控制每个像素点的颜色，就能够使屏幕显现出不同的图像，屏幕从工厂出来那天起，它上面的物理像素点就固定不变了，单位为pt。
设备像素 = 物理像素
DPR（Device Pixel Ratio） 设备像素比
OK，有了上面两个概念，就能够顺理成章引出下一个概念。DPR（Device Pixel Ratio） 设备像素比，这个与我们通常说的视网膜屏（多倍屏，Retina屏）有关。
设备像素比描绘的是未缩放状态下，物理像素和设备独立像素的初始比例关系。
简单的计算公式：
DPR = 物理像素 / 设备独立像素
我们套用一下上面 iPhone7 的数据（取设备的物理像素宽度与设备独立像素宽度停止计算）：
iPhone7’s DPR = iPhone7’s 物理像素宽度 / iPhone7's 设备独立像素宽度 = 2
750 / 375 = 2
或者是 1334 / 667 = 2
能够得到 iPhone7 的 dpr 为 2。也就是我们常说的视网膜屏幕。
视网膜（Retina）屏幕是苹果公司"创造"的一个营销术语。 苹果公司将 dpr > 1 的屏幕称为视网膜屏幕。
在视网膜屏幕中，以 dpr = 2 为例，把 4(2x2) 个像素当 1 个像素运用，这样让屏幕看起来更精致，但是元素的大小自身却不会改动：
OK，我们再来看看 iPhone XS Max：
它的物理像素如上图是 2688 x 1242，
它的 CSS 像素是 896 x 414，很容易得出 iPhone XS Max 的 dpr 为 3。
为不同 DPR 屏幕，提供恰当的图片
那么，DPR 和图片适配有什么关系呢？
举个例子，同样的 CSS 像素大小下，屏幕假如有不同 DPR，同样大小的图片渲染出来的效果不尽相同。
我们以 dpr = 3 的手机为例子，在 300 x 389 CSS 像素大小的范围内，渲染 1倍/2倍/3倍 图的效果如下：
实践图片所占的物理像素为 900 x 1167。
能够看到，在高 DPR 设备下提供只要 CSS 像素大小的图片，是十分含糊的。
因而，为了在不同的 DPR 屏幕下，让图片看起来都不失真，我们需求为不同 DPR 的图片，提供不同大小的图片。
那么，有哪些可行的处理计划呢？
计划一：无脑多倍图
假定，在挪动端假定我们需求一张 CSS 像素为 300 x 200 的图像，思索到如今曾经有了 dpr = 3 的设备，那么要保证图片在 dpr = 3 的设备下也正常高清展现，我们最大可能需求一张 900 x 600 的原图。
这样，不论设备的 dpr 能否为 3，我们统一都运用 3 倍图。这样即便在 dpr = 1，dpr = 2 的设备上，也能十分好的展现图片。
当然这样并不可取，会形成大量带宽的糜费。
现代阅读器，提供了更好的方式，让我们可以依据设备 dpr 的不同，提供不同尺寸的图片。
计划二：媒体查询
计划二，我们能够思索运用媒体查询。到今天，我们能够经过相应的媒体查询，得知当前的设备的 DPR 值，这样，我们就能够在对应的媒体查询中，运用对应的图片。
像是这样：
#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)
}
}
这个计划的缺陷在于：
要写的代码可能太多了，而且，可能存在一些介于 1~2，2~3 之间的 DPR 值，不好穷举出一切场景
需求留意语法需求的兼容性，需求添加前缀，譬如 -webkit-min-device-pixel-ratio，当然这个能够由 autoprefixer 辅助处理
