【学习图片】15.图像内容分发网络

本文首发于微信公众号：大迁世界, 我的微信：qq449245884，我会第一时间和你分享前端行业趋势，学习途径等等。
更多开源作品请看 GitHub https://github.com/qq449245884/xiaozhi ，包含一线大厂面试完整考点、资料以及我的系列文章。

了解图像内容交付网络如何具有转换和优化图像内容的能力。

你可能已经熟悉内图像内容分发网络（CDN）的核心概念：一个分布但相互连接的服务器网络，可以快速高效地向用户提供资源。当文件上传到CDN提供商时，该文件的副本将在全球CDN网络的其他节点上创建。当用户请求文件时，数据将由地理位置最近的节点发送给该用户，从而减少延迟。CDN的分布式特性还提供了冗余性，以防网络故障或硬件故障，并进行负载平衡以减轻流量峰值。

图像CDN可以提供所有这些好处，但有一个关键区别：根据用于访问它的URL字符串，能够转换和优化图像内容。

用户将上传一个规范的高分辨率图像到提供商，提供商将生成用于访问该图像的URL：

https://res.cloudinary.com/demo/image/upload/sample.jpg

尽管每个提供商使用的确切语法都会有所不同，但最基本的所有图像CDN都允许你更改源图像的尺寸、编码和压缩设置。例如，Cloudinary通过以下语法对上传的图像进行动态调整大小：h_后跟数字高度（以像素为单位），w_后跟宽度，以及一个c_值，允许你指定有关如何缩放或裁剪图像的详细信息。

可以通过在文件名和扩展名之前添加逗号分隔的值来应用任意数量的转换，这意味着上传的图像可以通过请求它的img元素的src进行根据需要操作。

<img src="https://res.cloudinary.com/demo/image/upload/w_400/sample.jpg" alt="…">

当用户首次访问包含这些转换的URL时，将生成并发送一个新版本的图像，该图像按比例缩放至宽度为400px（w_400）。然后在整个CDN上缓存该新创建的文件，以便将其发送给任何请求相同URL的用户，而无需按需重新创建。

虽然图像CDN提供商提供软件开发工具包以促进高级用法和与各种技术堆栈的集成并不罕见，但仅凭这种可预测的URL模式，我们就可以轻松地将单个上传文件转换为可行的srcset属性，而无需任何其他开发工具：

<img
  src="https://res.cloudinary.com/demo/image/upload/w_1000/sample.jpg 1000w"
  srcset="https://res.cloudinary.com/demo/image/upload/w_1000/sample.jpg 1000w,
          https://res.cloudinary.com/demo/image/upload/w_800/sample.jpg 800w,
          https://res.cloudinary.com/demo/image/upload/w_600/sample.jpg 600w"
  alt="…">

我们能够使用现在应该熟悉的语法来手动指定我们想要的压缩级别：q_，"质量 "的缩写，后面是压缩级别的数字缩写。

<img src="https://res.cloudinary.com/demo/image/upload/w_400,q_60/sample.jpg"  alt="…">

然而，由于大多数图像CDN提供了一系列强大功能：全自动压缩、编码和内容协商，你很少需要手动包含这些信息。

自动压缩

CDN所拥有的计算能力意味着它们能够提供一项非常强大的功能：通过分析图像内容来算法确定其理想的压缩水平和编码设置，就像你或我手动微调每个图像的压缩一样。

这些算法自动化了你可能会做出的在文件大小和感知质量之间权衡的决策，通过分析图像内容来寻找可度量的退化迹象，并相应地微调压缩设置。这通常意味着与一种大小适合所有的手动压缩方法相比，文件大小会大大减小。

尽管这个过程听起来很复杂，但它的实现却非常简单：对于Cloudinary来说，将“q_auto”添加到图像URL中即可启用此功能：

<img src="https://res.cloudinary.com/demo/image/upload/w_1400/sample.jpg" alt="…">
<!-- 250 KB-->

<img src="https://res.cloudinary.com/demo/image/upload/w_1400,q_auto/sample.jpg" alt="…">
<!-- 134 KB-->

自动编码和内容协商

当接收到对图像的请求时，图像CDN通过浏览器发送的HTTP头来确定浏览器支持的最新编码方式，这些HTTP头是在请求资源时发送的。具体来说，是通过“Accept”头部来指示浏览器可以理解的编码方式。我们使用与填充<picture>元素的<source>的type属性相同的媒体类型。

例如，在资产URL的图像转换列表中添加“f_auto”参数，明确告诉Cloudinary要提供浏览器能够理解的最有效的编码方式：

<img src="https://res.cloudinary.com/demo/image/upload/w_1200,q_auto,f_auto/sample.jpg" alt="…">

然后，服务器生成一个具有该编码的图像版本，并为所有具有相同浏览器支持水平的后续用户缓存该结果。该响应包括一个Content-Type头，明确告知浏览器该文件的编码，而不考虑文件的扩展名。即使一个使用现代浏览器的用户会对一个以.jpg结尾的文件提出请求，该请求也会伴随着一个标头，告知服务器支持AVIF，服务器会发送一个AVIF编码的文件，并明确指示将其视为AVIF。

最终的结果是一个过程不仅使你免于创建备用编码文件和手动微调压缩设置（或维护一个为你执行这些任务的系统），而且也不需要使用<picture>和type属性来有效地向用户传递这些文件。因此，仅使用srcset和sizes语法就可以为您的用户提供编码为AVIF的图像，如果不支持，则降级为WebP（或仅适用于Safari的JPEG-2000），再次降级为最明智的传统编码方式。

使用图像CDN的缺点更多是后勤问题而非技术问题，其中最主要的是成本。虽然图像CDN通常会为个人使用提供功能强大的免费计划，但生成图像资产需要带宽和存储空间进行上传，服务器上的处理来转换图像，并需要额外的空间来缓存转换结果，因此高级用法和高流量应用程序可能需要付费计划。

原文：https://web.dev/learn/images/automating/

代码部署后可能存在的BUG没法实时知道，事后为了解决这些BUG，花了大量的时间进行log 调试，这边顺便给大家推荐一个好用的BUG监控工具 Fundebug。

交流

有梦想，有干货，微信搜索 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。

本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试完整考点、资料以及我的系列文章。