与 Addy Osmani 合作的 Smashing Podcast 第 39 集：图像优化

本集得到了 Storyblok 亲爱的朋友的大力支持，他们帮助人们在任何平台上提供强大的内容体验：企业网站、电子商务网站、移动应用程序和屏幕显示。 谢谢！

在今天的 Smashing Podcast 中，我们谈论的是图像优化。 对于 2021 年的高性能图像，我们应该遵循哪些步骤？ 我与专家 Addy Osmani 进行了交谈以找出答案。

显示注释

• “图像优化”，Addy Osmani
• 艾迪在推特上
• 阿迪的个人网站

每周更新

• 认识 :has，一个原生 CSS 父选择器（以及更多）
  由阿德里安·贝斯撰写
• 我最近发现的三个前端审计工具
  由 Stefan Judis 撰写
• 有用的前端样板和入门套件
  由科西玛·米尔克撰写
• 网页设计做得很好：利用音频
  弗雷德里克·奥布莱恩 (Frederick O'Brien) 撰写
• 当 CSS 不够用时：可访问组件的 JavaScript 要求
  斯蒂芬妮·埃克斯写的

成绩单

Drew McLellan：他是一名工程经理，负责 Google Chrome，他的团队专注于速度，帮助保持网络快速。 致力于开源社区，他过去的贡献包括 Lighthouse、Workbox、Yeoman、Critical 和做 NVC。 所以我们知道他知道如何优化网络性能。 但是你知道他因为笔误而想要获得奥斯卡最佳女配角奖吗？ 我的粉碎朋友，请欢迎 Addy Osmani。 嗨，艾迪。 你好吗？

Addy Osmani：我太棒了。

德鲁麦克莱伦：很高兴听到。 我今天想和你谈谈网络上的图像。 在过去的几年里，这个领域发生了惊人的变化和创新，而您刚刚写了一本非常全面的书，内容涉及 Smashing 的图像优化。 这个时候想“现在是出一本关于图像优化的书的时候了”的动机是什么？

Addy Osmani：这是一个很好的问题。 我想我们知道，几十年来图像一直是网络的一个非常关键的部分，我们的大脑能够比文本更快地解释图像。 但随着时间的推移，这个整体主题会变得越来越有趣和微妙。 我总是告诉人们这可能是我的第三或第四本书。 我从来没有刻意去写一本书。

Addy Osmani：我开始这本书时写了一篇关于图像优化的文章，然后随着时间的推移，我发现我不小心写了一整本关于它的书。 我们在这个项目上工作了大约两年。 即使在那个时候，该行业一直在发展浏览器，围绕图像和图像格式的工具也在不断发展。

Addy Osmani：所以我写这本书是因为我发现自己很难掌握所有这些变化。 我想，“我将成为一名优秀的网络公民，并尝试在一个地方跟踪我学到的所有内容，以便其他人可以利用它。”

Drew McLellan：我认为这是其中之一，在浏览器中进行了大量性能优化，这是一个快速变化的领域，不是吗？ 当你学到的一种技术是最新的和最佳实践时，就会发生一些技术转变，然后你会发现它实际上是一种反模式，你不应该这样做。 并且试图保持你的知识并确保你正在阅读正确的文章并学习正确的东西并且你没有阅读两年前的东西是非常困难的。

Drew McLellan：因此，从权威来源将所有内容收集在一本经过充分研究的书中真是太棒了。

阿迪奥斯马尼：是的。 即使从作者的角度来看，最有趣的事情之一，也许是我们编辑团队压力最大的事情之一就是我会交出一章并说它已经完成。 然后两周后，浏览器会发生一些变化，我会说，“哦，等等。 我必须在最后一刻再做出改变。”

Addy Osmani：但图像景观已经发生了很大变化，即使在去年也是如此。 我们已经看到 WebP 支持终于在大多数现代浏览器中越过了终点线。 AVIF 图像支持在 Chrome、Firefox、JPEG XL、延迟加载。 总的来说，我们已经看到了如何在浏览器中非常具体地使用网络上的图像的增强功能。 但同样，人们需要掌握很多东西。

Drew McLellan：有些人可能会认为图像优化是一个非常老套的话题。 在我们职业生涯的某个阶段，我们都学会了如何从我们的图形软件中导出网页。 我们中的一些人可能习惯于获取这些导出的图像并通过 ImageOptim 之类的工具运行它们。

Drew McLellan：所以我们可能知道当它是照片图像时我们应该选择 JPEG，而当它是基于图形的图像时我们应该选择 PNG，然后认为，“好吧，就是这样。 我知道图像优化，我已经完成了。” 但实际上，这些事情只是赌注，不是吗？

Addy Osmani：是的，他们是。 我认为，随着时间的推移，我们即使在不同的环境中也能显示更详细、更清晰的图像和图像，这取决于你是否关心艺术指导。 我认为需要弄清楚如何让这些图像看起来像最终用户想要的那样漂亮，同时牢记他们的环境、设备限制、网络限制是一个难题，而且我知道很多人仍然知道这一点与之斗争。

Addy Osmani：因此，在考虑图像并对其进行更精细的处理时，不仅仅是“嘿，让我们使用 JPEG”或“让我们使用 PNG”，我认为这有几个方面的价值牢记。 第一个只是一般的压缩。 您提到了 ImageOptim，我们中的很多人都习惯于将图像拖到一个地方，然后从它的后面得到一些更小的东西。

Addy Osmani：现在，谈到压缩，我们通常谈论不同的编解码器。 编解码器是一种压缩技术，通常具有用于编码文件的编码器组件和用于解码和解压缩它们的解码器组件。 当您决定是否使用某些东西时，您通常需要考虑您使用的照片或图像是否适合您使用有损压缩方法或无损压缩方法。

Addy Osmani：以防万一人们对这些概念不太熟悉，无损方法是在解压缩的最后重现完全相同的文件。 因此，您在质量方面并没有真正失去太多。 无损是更多地将您的图像通过传真机。 你得到一份原件的传真，它不会是原始文件。 那里可能有一些不同的工件。 它可能看起来略有不同。 但总的来说，你压缩的越多，你通常损失的质量就越多。

Addy Osmani：因此，对于所有这些现代图像编解码器，他们试图了解您可以挤出多少质量，同时仍保持相对不错的文件大小，具体取决于用例。

Drew McLellan：所以说真的，从技术的角度来看，你有一个源图像，然后你就有了目标文件格式。 但是将一个变成另一个的过程是有争议的。 只要你有一个符合要求的文件，你怎么做取决于一个可以有很多不同实现的编解码器，有些会比其他的更好。

Addy Osmani：当然。 绝对地。 而且我认为，再次回到我们从 JPEG 和 PNG 开始的地方，人们可能知道 JPEG 是为有损压缩照片而创建的。 您通常会从它的背面得到一个较小的文件，它有时可能会有不同的条带伪影。 PNG 最初是为无损压缩而创建的，在非摄影图像上效果很好。

Addy Osmani：但从那以后，事情发生了变化。 大约在 2010 年左右，我们开始获得对 WebP 的支持，它本应取代 JPEG 和 PNG，并在压缩方面略胜一筹。 但从那时起，桌面上的图像格式和选项的数量就猛增了。 我认为事情总体上朝着一个好的方向发展，特别是对于像 AVIF 和 JPEG XL 这样的现代格式。 但我们花了一段时间才到这里。 即使在所有浏览器上获得 WebP 支持也需要相当长的时间。

Addy Osmani：我认为最终影响它的是确保开发人员一直在要求它，他们渴望能够从这些现代格式中获得更好的压缩，并且渴望在浏览器之间具有良好的兼容性对于这些事情，也是。

德鲁麦克莱伦：是的。 WebP 对我来说似乎真的很有趣，因为除了在格式中提供无损和有损压缩之外，我们显然还可以大大减少文件大小。 并且有很好的浏览器支持，我们看到谷歌和 Netflix 等大公司以及各种大公司的采用。

Drew McLellan：但我对行业的看法是，我们在基层看不到同样的吸收。 WebP 还在等待它的到来吗？

Addy Osmani：我想我会说 WebP 即将到来。 很多人一直在等待 Safari 和 WebKit 支持实现，而我们终于有了。 但是当我们考虑新的图像格式时，理解支持的真正含义是非常重要的。 浏览器支持解码这些图像。 我们还需要非常好的工具支持，以便无论您是在节点环境、图像 CDN 中，还是在 CMS 中，您都可以使用这些图像格式。

Addy Osmani：我记得很多年前 WebP 第一次问世的时候。 早期采用者会遇到这样一个问题，即您将 WebP 文件保存到桌面，然后突然，“哦，等等。 我需要把它拖到我的浏览器中查看吗？”或者，“如果我的用户正在下载 WebP，他们会卡住并想知道发生了什么吗？”

Addy Osmani：因此，我认为，确保在操作系统级别以及其他环境中对图像格式提供相当全面的支持对于图像格式的起飞非常重要。 对于提供图像的人来说，稍微考虑一下这些用例也很重要，这样，如果我正在保存或下载文件，您就会尝试将其转换为人们通常可以轻松共享的便携式格式。 我认为这就是至少在 iOS 上，iOS 支持加息和连字符的地方。 并在必要时将内容转换为 JPEG，以便人们共享它们。

Addy Osmani：因此，我认为，考虑这些类型的用例，我们可以确保用户在我们提供更好的压缩效果的同时不会丢失，这一点很重要。

Drew McLellan：我运行了一个幻灯片共享服务，你可以想象，它处理数十万张图像。 当我研究 WebP 时，可能是三年前，我主要是在寻找一种降低 CDN 带宽成本的方法，因为如果您提供较小的文件，则提供服务的费用会减少。 但是，虽然我仍然需要一个完整的图像，一种传统的图像格式，但我的计算表明，存储整个其他图像集的成本超过了提供较小文件的好处。 所以我们到了 2021 年。我现在应该重新考虑这个决定吗？

Addy Osmani：我认为这是一个非常重要的考虑因素。 有时，当我们谈论你应该如何接近你的形象策略时，很容易给人们一个高层次的回答，“嘿，是的。 只需生成五种不同的格式，就可以无限扩展。” 并非总是如此。

Addy Osmani：我认为，当您必须牢记存储时，有时要牢记什么是最好的、最常见的服务于您的用户的分母。 这些天来，我实际上会说 WebP 是值得考虑的共同点。 对于习惯于使用图片标签有条件地为人们提供不同格式的人，通常您会使用 JPEG 作为主要的后备。 也许这些天实际上使用 WebP 作为大多数用户的后备是可以的，除非你有使用非常非常旧的浏览器的人。 而且我认为这些天我们看到的要少得多。 但是你肯定有一些灵活性。

Addy Osmani：现在，如果你想要面向前方，我会说选择一种你认为非常有效的格式。 如果您可以以可扩展且灵活满足您需求的方式处理存储，我想说人们应该做的是考虑 JPEG XL。 从技术上讲，它还没有在浏览器中发布。 当它这样做时，JPEG XL 对于有损或无损用例中的许多照片或非照片用例来说应该是一个非常好的选择。 它可能会比 WebP V1 好得多。 所以这是一个地方。

Addy Osmani：我认为如果你需要达到非常低的比特率，AVIF 可能会更好。 也许您非常关心带宽。 也许您不太关心图像保真度。 在这些比特率下，我可以想象它看起来比一些替代品更清晰。 在我们拥有 JPEG XL 之前，我会尝试查看您的分析并了解您是否可以提供 AVIF。 否则，我会专注于那个 WebP。 如果您是分析人员，我想大多数人都可以使用 WebP，并且您不太关心广域或文本覆盖，在 WebP 中染色体采样可能不完美的地方。 这当然是值得牢记的。

Addy Osmani：所以我会尽量记住，不会有一种适合所有人的尺寸。 就我个人而言，这些天来，我不太担心存储、出口和带宽成本，只是因为我使用了图像 CDN。 我很高兴地说我个人使用 Cloudinary。 我们在我工作的地方使用了许多不同的图像 CDN。 但我发现不必担心处理图像管道的维护成本，处理我将如何支持的问题，“哦，嘿，这是另一种图像格式或新类型的后备或新的 Web API ，”这对投资于只为我照顾它的东西来说是一个很好的好处。

Addy Osmani：然后我的用例的总体成本还可以。 但我完全可以想象，如果您以这种规模运行幻灯片服务，那也不一定是一种选择。

德鲁麦克莱伦：是的。 所以我想回到这些即将到来的未来格式中。 但我认为这值得深入研究，因为使用任何类型的性能工具、Lighthouse 或 WebPageTests，如果我们中的任何人通过它运行我们的网站，它会建议的关键之一是我们使用 CDN 来存储图像。 对于非常大的公司来说，这是一件非常现实的事情。 它是现实的并且在人们构建小型网站和应用程序的范围内，还是真的像听起来那么容易？

Addy Osmani：我认为人们应该问的问题是，“你用图像做什么？” 如果你只有几张图片，如果你正在构建一个博客并且你添加的图片相对简单，你没有成百上千张图片，你可能只需要接近这个就可以了在构建时，以非常静态的方式安装几个 NPM 包。 也许你只是在使用夏普。 这在很大程度上照顾了你。

Addy Osmani：有一些工具可以帮助您生成多种格式。 它确实会稍微增加你的构建时间，但这对很多人来说实际上可能没问题。 然后对于那些确实希望能够利用多个 -

Addy Osmani：对于那些确实希望能够利用多种格式的人来说，他们不想处理太多的工具细节，并且希望能够获得一个非常丰富的响应式图像或故事，我会说尝试图像 CDN。 出于成本考虑，我个人最初对将其用于个人项目非常谨慎，然后随着时间的推移，当我查看我的账单时，我实际上意识到这可以节省我的时间，否则我会自己投资解决这些问题。 我不知道过去您必须编写多少自定义脚本来处理您的图像，但我意识到如果我可以每月通过这些不同的 npm 包为自己节省至少几天的调试时间，那么成本有点照顾我节省的时间，所以没关系。

Addy Osmani：但是，如果您要扩展到 100 个或 1000 个或数百万个图像，并且这不是您的收入必然涵盖的东西，或者您不准备支付的东西，您确实需要考虑替代策略。 而且我认为我们很幸运，我们今天可用的工具有足够的灵活性，可以朝这两个方向发展，我们做一些更多的定制，我们自己解决或滚动我们自己的图像 CDN 或者我们投资一些稍微商业化的东西。 而且我们处于一个我会说对于某些用例的地方，是的，您可以使用图像 CDN，而且价格实惠。

Drew McLellan：我想，其中一种指导原则就是始终保持敏捷并为变化做好准备。 您可能会开始使用图像 CDN 来根据请求为您动态转换图像，如果这到了在成本方面不可持续的地步，您可以查看另一种解决方案并让您的代码库处于某种状态用一种解决方案替换另一种解决方案很容易。 我认为一般和任何你依赖第三方服务的地方，这是一个很好的原则，不是吗？ 所以这些即将到来的图像格式，你提到了JPEG XL。 什么是 JPEG XL？ 它来自哪里？ 它对我们有什么作用？

Addy Osmani：这是一个很好的问题。 所以 JPEG XL 是下一代图像格式，它应该是通用的，它是来自 JPEG 委员会的编解码器。 它起源于谷歌的图片格式，然后是 Cloudinary 的 FUIF 格式。 多年来，这种努力已经包含了很多格式，但它已经不仅仅是其各个部分的总和，JPEG XL 的一些好处是它非常适合高保真度图像，非常适合无损，它支持渐进式解码，无损JPEG转码，而且它也有点大惊小怪和免版税，这绝对是一个好处。 我认为 JPEG XL 可能是一个非常强大的候选者。 我们之前讨论过，如果你只选择一个，你会用什么？ 我认为 JPEG XL 有潜力成为那个。

Addy Osmani：我也不想过度承诺，​​我们还处于浏览器支持的早期阶段。 所以我认为我们真的应该拭目以待，试验和评估它在实践中的表现如何，并满足人们的期望，但我认为 JPEG XL 在有损和无损情况下都有很大的潜力。 现在，我相信 Chrome 可能在支持方面是最先进的，但我也看到 Mozilla 和其他浏览器对此肯定感兴趣，所以我对 JPEG XL 的未来感到兴奋。 如果我们要说，人们感兴趣的更短期限是什么？ 当然还有AVIF。

Drew McLellan：告诉我们关于 AVIF，这是我不熟悉的另一个。

阿迪·奥斯马尼：好的。 因此，我们前面提到过，如果您需要低比特率并且您更关心带宽而不是图像保真度，那么 AVIF 可能是一个更好的选择，作为一般原则，AVIF 确实在低保真高吸引力压缩方面处于领先地位。 和 JPEG XL，它应该在中高保真度方面表现出色，但它们本身的格式略有不同。 我们正处于 AVIF 获得越来越好的浏览器支持的地方，但让我退后一步，多谈谈格式。 所以 AVIF 本身是基于开放媒体联盟标准化的 AV1 视频编解码器，它试图让人们在我们之前讨论的 JPEG 和 WebP 上获得显着的压缩增益。 虽然您可以从 AVIF 获得的确切节省取决于内容和您的质量目标，但我们已经看到很多情况下，与 JPEG 相比，它可以提供超过 50% 的节省。

Addy Osmani：它有很多很好的功能，它能够为您提供容器支持，以支持高动态范围和宽色域、胶片颗粒合成等新功能。 再次，类似于谈论面向前方，图片标签的好处之一是您可以立即为用户提供 AVIF 文件，并且在不一定支持的情况下，它仍会退回到您的 WebP 或 JPEG . 但是回到您关于 Photoshop Save For Web 的示例，您可以使用 500 KB 大小的 JPEG，尝试拍摄与 Photoshop Save For Web 和使用 AVIF 相似的质量，我会说您可能能够获得该文件大小约为 90 KB，100 KB，因此节省了很多，而质量没有明显的损失。

Addy Osmani：其中一件好事是，理想情况下，您不会在任何具有丰富细节的图像中看到太多的纹理损失。 因此，如果您有森林或露营或任何此类事物的照片，它们应该仍然看起来非常丰富 AVIF。 所以我对 AVIF 的发展方向感到非常兴奋。 我确实认为在工具支持方面需要做更多的工作。 所以我前几天发布了一条关于这个的推文，我们现在有很多使用 AVIF 的选项，对于单个图像，我们有 Squoosh，squoosh.app，它是由另一个团队在 Chrome 中编写的，所以喊感谢 Surma 和 Jake 在 Squoosh 上的工作。 Avif.io 为今天尝试使用 AVIF 的人们提供了许多不错的选择，无论他们关注什么技术堆栈，Sharp 也支持 AVIF。

Addy Osmani：但通常你会想到我们处理图像的其他地方，无论是在 Figma、Sketch、Photoshop 还是其他地方，我想说我们仍然需要在以下方面做一些工作AVIF 支持在那里，因为它需要无处不在，让开发人员和用户真正感觉到它已经着陆并回家了。 这是我们目前在 Chrome 中开发 AVIF 的团队关注的领域之一，试图确保我们可以将工具带到一个非常好的地方。

Drew McLellan：所以我们现在有了 HTML，即图片元素，它为我们提供了比传统图像标签更大的灵活性。 虽然图像标签也有很长的路要走，不是吗？ 但是我们看到图片被添加了，它与原生视频标签大约在同一时间，我认为是在原始的一批 HTML5 更改中。 这使我们能够指定多个来源，对吗？

Addy Osmani：是的，没错。

Drew McLellan：因此，您可以列出不同格式的图像，浏览器会选择它支持的一种，这使我们能够立即进行相当多的实验，而无需过多担心会破坏旧浏览器的用户。

Addy Osmani：当然。 我认为这是在我们考虑方向的用例之外使用图片标签的最大好处之一，只是能够为人们提供图像并让浏览器浏览潜在来源列表并查看，好吧，好吧，我将使用该列表中我理解的第一个，否则我会退回，这对人们来说是一个非常强大的功能。 我想同时，我也听到一些人表达了一些担忧或担忧，当我们尝试支持多种格式时，我们正在重新生成非常大的标记块，并且您考虑到这些格式的不同大小和突然它变得有点笨重。

Addy Osmani：那么我们还有其他方法可以解决这些问题吗？ 我不想在图像 CDN 上向人们推销太多，我希望他们独立存在。 但这是一个名为内容协商的想法实际上可以为您提供有趣路径的地方之一。 所以，我们已经讨论了一些关于图片标签的内容，您必须在其中生成一堆不同的资源并决定优先顺序，正确的，额外的 HTML。 对于内容协商，它说的是让我们在服务器上完成所有这些工作。 因此，客户端可以通过接受 HTTP 标头通过 MIME 类型列表预先告诉服务器它支持哪些格式。 然后服务器可以完成所有繁重的工作，生成和管理最终资源，并决定将哪些资源发送给客户端。 这里的强大功能之一是，如果您使用的是图像 CDN，则可以指向单个资源。

Addy Osmani：所以也许如果我们有一个像puppy.JPEG 这样的小狗图像，我们可以给人们一个puppy.JPEG 的URL，如果他们的浏览器支持WebP 或者它支持AVIF，那么服务器就可以非常聪明地提供正确的服务根据他们的支持情况向这些用户提供图像，但在其他情况下无需您自己做大量额外工作即可退回。 现在，我认为这是一个强有力的想法。 您可以在服务器上做很多事情，我们有时会谈论不是每个人都能获得真正强大的网络质量，您的有效连接类型可能会因您所在的位置而异。

Addy Osmani：即使住在硅谷，我也可能从咖啡店步行到酒店，或者我可能在车里，我的 wifi 质量或信号可能不是那么好。 因此，在这里您可以访问其他 API，如果用户选择了数据节省，其他想法（如 Save-Data 客户端提示）可能能够为人们提供更小的资源。 所以我们可以在服务器端做很多有趣的事情，我确实认为我们应该继续推动这些想法，找到一个很好的平衡，让那些习惯于做市场路径的人得到所有的灵活性。想要更神奇的解决方案的人也有一些选择。

Drew McLellan：这种数据保护方法的概念是我首先从您的书中了解到的。 我的意思是，让我们再深入一点，因为这很有趣。 因此，您说的是浏览器能够发出信号，表示希望减少数据体验，因为它可能处于计量连接或电池电量不足之类的情况下。

阿迪·奥斯马尼：没错。 确切地。 我一直在正常旅行或之前旅行，那时我们会旅行更多，我经历过世界上很多地方或我的网络质量可能非常差或非常不稳定的情况，甚至开放启动网页可能是令人沮丧或困难的经历。 我可能正在查找菜单，如果我看不到他们提供的美味食物的图片，我可能会去我可以去的地方，或者我可能会，我不知道，给自己做点食物。 但我认为数据保护程序的一个有趣之处在于它可以让您了解用户的偏好。 因此，如果作为用户，我知道我的网络连接很困难。 我可以说：“好吧，我将在浏览器中选择进入数据保护模式。”

Addy Osmani：然后作为开发人员，你可以用它作为一个信号，说：“好吧，好吧，用户有点受限，也许我们会在他们浏览小得多的图像或质量低得多的图像时浏览他们。” 但是他们仍然可以看到一些图像，这比他们等待很长时间才能提供更丰富的东西要好。 这些类型的信号的其他好处是您可以将它们用于有条件地提供媒体。 因此，也许在某些情况下，文本是该页面中最重要的内容，如果您发现用户处于某种受限环境中，也许您可​​以关闭这些图像。 我只会花 30 秒在这上面，但你真的可以把这个想法推向极端。 使用 Save-Data 可以做的一些有趣的事情甚至可能是关闭在 JavaScript 中实现的非常昂贵的功能。

Addy Osmani：如果您有某些组件被认为是可选的，那么如果它们只是增强体验，则不一定需要将它们发送给所有用户。 您仍然可以为每个人提供非常核心、小型、快速的体验，然后为拥有更快连接或设备的人添加一些漂亮的糖霜。

Drew McLellan：潜在地，我猜它可能会影响分页，你可以在一页上返回 10 个结果而不是 100 个以及类似的东西。 那里有很多有趣的功能。 我认为我们都熟悉准备新网站、优化所有图像、将其交给客户、给他们一个 CMS 来管理内容并发现他们只是用图像优化不佳。 我的意思是，我想，图像 CDN 将是一个非常方便的解决方案，但是还有其他解决方案吗，CMS 可以在服务器上做些什么来帮助解决这个问题，或者图像 CDN 可能只是怎么走？

Addy Osmani：我认为，在尝试让每个人优化他们的图像至少六七年之后，我们发现这是一个难题，其中一些参与图片的人可能在技术上稍微更精通并且可能更舒适的设置建立自己的工具或运行 Lighthouse 或尝试其他工具，让他们知道是否有改进的机会。 如果您有机会进一步优化或提供合适尺寸的图像，我希望看到人们一直使用 Lighthouse 之类的东西来捕捉，但除此之外，有时我们会遇到上传图像的人可能不会的用例甚至必须了解他们上传的资源的成本。 这通常是我们遇到的问题，我会道歉，我不会过多地大声疾呼，但即使是在 Google 博客上，我们也会遇到这种情况。

Addy Osmani：每隔几周在 Google 博客上，我们就会有人上传一个非常大的 20 或 30 兆字节的动画 GIF。 而且我不希望他们知道这不是一个好主意，他们试图让文章看起来很酷，非常吸引人和互动，但这些观众不一定会知道去运行工具或使用 ImageOptim或者使用这些其他工具中的任何一个，并为他们记录，以便他们检查它们，当然是一种选择。 但是，能够自动解决问题，我认为非常引人注目，并帮助我们始终如一地达到我们希望平衡所有 CMS 用户的需求的地方，无论他们是技术性的还是非技术性的，以及作为我们用户的需求。

Addy Osmani: So I think the image CDNs can definitely play a role in helping out here. Ultimately, the thing that's important is making sure you have a solution in place between people, stakeholders who might be uploading those images, and what gets served down to users. If it's an image CDN, if it's something you've rolled yourself, if it's a built step, just needs to be something in place to make sure that you are not serving down something that's very, very large and inefficient.

Drew McLellan: Talking about animated GIFs, they're surprisingly popular. They're fun, we love them, but they're also huge. And really, it's a case where a file format that was not designed for video is being used for video. Is there a solution to that with any of these image formats? 我们可以做什么？

Addy Osmani: Oh, gosh. The history of GIFs is fascinating. We saw a lot of the formats we know and love or have been around for a while were originated in the late '80s to early '90s, and the GIF is one of those. It was created in 1987. I'm about as old as the GIF.

Addy Osmani: As you mentioned, it wasn't originally created necessarily for use case. I think it was Netscape Navigator which in mid '90s maybe added support for looping GIFs and giving us this kind of crazy fun way to do memes and the like, but GIFs have got so many weaknesses. They're kind of limited in many cases to a very finite color palette; 256 colors, in many cases. They're a bitmapped raster format with pixel value stored in image files.

Addy Osmani: They're very inefficient, for a number of reasons. And you mentioned that they're also quite large. I think that we've gotten into this place of thinking that if we want a short segment of video or animation that's going to be looping, the GIF is the thing that we have to use. And that's just not the case.

Addy Osmani: While we do see that there are modern image formats that have support for animation, I think that the most basic thing you can do these days is make sure you're serving a video down instead of a GIF. Muted auto-play videos combined with HD64, HD65, whatever video you're going to use, can be really powerful, and significantly smaller for use cases where you need to be showing a sequence of images.

Addy Osmani: There are options for this. AVIF has got image sequences in there, potentially. Other formats have explored these ideas as well. But I think that one thing you can do is, if you're using GIFs today, or you have users who are slightly less technical who are using GIFs today, try to see if you can give them tools that will allow them to export a video instead, or if your pipeline can take care of that for them, that's even better.

Addy Osmani: I have plenty of conversations with CMS providers where you do see people uploading GIFs. They don't know the difference between a video and a GIF file. But if you can just, whether it's with an image CDN or via some built process, change the file over to a more efficient format, that would be great.

Drew McLellan: We talked briefly about tools like ImageOptim that manage to strip out information from the files to give us the same quality of result with a smaller file size. I'm presuming that's because the file formats that we commonly deal with weren't optimized for delivery over the Web in the first place, so they're doing that step of removing anything that isn't useful for serving on the Web. Do these new formats take that into consideration already? Is something like ImageOptim a tool that just won't be required with these newer formats?

Addy Osmani: I'm anticipating that some of the older formats… Things that have been around for a while, take a while to phase out or to evolve into something else. And so I can see tools like ImageOptim continuing to be useful. Now, what are modern image formats doing that are much better? Well, I would say that they're taking into account quite a few things.

Addy Osmani: They're taking into account, are there aspects of the picture that the human eye can't necessarily make out a difference around? When I'm playing around with different quality settings or different codecs, I'm always looking for that point where if I take the quality down low enough, I'm going to see banding artifacts. I'm going to see lots of weird looking squares around my buildings or the details of my picture.

Addy Osmani: But once those start to disappear, I really need to start zooming in to the image and making comparisons across these different formats. And if users are unlikely to do that, then I think that there are good questions around is that point of quality good enough? I think that modern image formats are pretty good at being able to help you navigate, filtering out some of those details pretty well. Keeping in mind what are the needs of color, because obviously we've got white gamut as a thing right now as well.

Addy Osmani: Some people might be okay with an amount of changing your color palette versus not, depending on the type of images that you have available, but definitely I see modern formats trying to be resilient against things like generational loss as well. Generational loss is this idea that… We mentioned memes earlier. A common problem on the Web today is you'll find a meme, whether it's on Facebook or Instagram or Reddit or wherever else, you'll save it, and maybe you'll share it around with a friend. Maybe they'll upload it somewhere else. And you suddenly have this terrible kind of copy machine or fax effect of the quality of that image getting worse and worse and worse over time.

Addy Osmani: And so when I see something get reshared that I may have seen three months ago, now it might not be really, really bad quality. You can still make out some of the details, but image formats, being able to keep that in mind and work around those types of problems, I think are really interesting.

Addy Osmani: I know that JPEG XL was trying to keep this idea of generational loss in mind as well. So there's plenty of things that modern codecs and formats are trying to do to evolve for our needs, even if they're very meme focused.

Drew McLellan: Let's say you've inherited a project that has all sorts of images on it. What would be the best way to assess the state of that project in terms of image optimization? Are there tools or anything that would help there?

Addy Osmani: I think that it depends on how much time you've got to sink into the problem. There are very basic things people can try doing, like obviously batch converting those images over to more modern formats at the recommended default quality and do an eyeball check on how well they're doing compared to the original.

Addy Osmani: If you're able to invest a little bit more time, there are plenty of tools and techniques like DSSIM and other ways of being able to compare what the perceptual quality differences are between different types of images that have been converted. And you can use that as a kind of data-driven approach to deciding, if I'm going to batch convert all of my old images to WebP, what is the quality setting that I should be relying on? If I'm going to be doing it for AVIF or JPEG XL, what is the quality setting that I should be relying on?

Addy Osmani: I think that there's plenty of tools people have available. It really just depends on your time sink that's possible. Other things that you can do, again, going back to the image CDN aspect, if you don't have a lot of time and you're comfortable with the cost of an image CDN, you can just bulk upload all of those images. And there are CDNs that support this idea of automatic quality setting. I think in Cloudinary it's q_auto, or something like that.

Addy Osmani: But the basic idea there is they will do a scan of the image, try to get a sense of the type of content that's in there, and automatically decide on the right level of quality that you should be using for the images that are getting served down to users. And so you do have some tooling options that are available here, for sure.

Drew McLellan: I mean, you mentioned batch processing of images. Presumably you're into the area of that generational loss that you're talking about, when you do that. When you take an already compressed JPEG and then convert it to a WebP, for example, you risk some loss of quality. Is batch converting a viable strategy or does that generational loss come too much into play if you care about the pristine look of the images?

Addy Osmani: I think it depends on how much you're factoring in your levels of comfort with lossy versus lossless, and your use case. If my use case is that I've inherited a project where the project in question is all of my family's photos from the last 20 years, I may not be very comfortable with there being too much quality loss in those images, and maybe I'm okay with spending a little bit more money on storage if the quality can remain mostly the same, just using a more modern format.

Addy Osmani: If those are images for a product catalog or any commerce site, I think that you do need to keep in mind what your use case is. Are users going to require being able to see these images with a certain level of detail? And if that's the case, you need to make those trade-offs in mind when you're choosing the right format, when you're choosing the right quality.

Addy Osmani: So I think that batch is still okay. To give you a concrete idea of one way of seeing people approach this at scale, sometimes people will take a smaller sample of the images from that big collection that they've inherited, and they'll try out a more serious set of experiments with just that set. And if they're able to land on an approach that works well for the sample, they'll just apply it to the whole batch. And I've seen that work to varying degrees of success.

Drew McLellan: So optimizing file size is just sort of one point on the overall image optimization landscape. And I'd like to get on to talking about what we can do in our browsers to optimize the way the images are used, which we'll do after a quick word from this episode sponsor.

Drew McLellan: So we've optimized and compressed our large files, but now we need to think about a strategy for using those in the browser. The good old faithful image tag has gained some new powers in recent times, hasn't it?

Addy Osmani: Yeah, it has. And maybe it's useful for folks… I know that a lot of people that ask me about images these days also ask me to frame it in terms of metrics and the Core Web Vitals. Would it be useful for me to talk about what the Core Web Vitals are and maybe frame some of those ideas in those current terms?

Drew McLellan: Absolutely, because Core Web Vitals is a sort of initiative from Google, isn't it, that we've seen more recently? We're told that it factors into search ranking potentially at some level. What does Core Web Vitals actually mean for us in terms of images?

Addy Osmani: Great question. As you mentioned, Core Web Vitals is an initiative by Google, and it's all about trying to share unified guidance for quality signals. That can be pretty key to delivering a great user experience on the Web. And it is part of a set of page experience signals Google Search may be evaluating for ranking purposes, but they can impact the Core Web Vitals in a number of ways.

Addy Osmani: Now, before I talk about what those ways are, I should probably say, what are the Core Web Vitals metrics? There's currently three metrics that are in the Core Web Vitals. There's largest contentful paint, there's cumulative layout shift, and there's first input delay. Now, in a lot of modern Web experiences we find that images tend to be one of the largest visible elements on the page. We see a lot of product pages where we have a big image that's the main product item image. We see images in carousels, in stories and in banners.

Addy Osmani: Now, largest contentful paint, or LCP, is a Core Web Vitals metric that tries to measure when the largest contentful element, whether it's an image text or something else, is in a user's viewport, such that we're able to tell when that image becomes visible. And that really allows a browser to determine when the main content of the page has really finished rendering.

Addy Osmani：所以如果我想访问一个食谱网站，我可能会关心这个食谱的外观，所以我们关心的是确保我可以看到这个食谱的大英雄形象。 现在，LCP 元素可以随着时间而改变。 很有可能在加载的早期，最大的东西可能是标题，但随着页面的继续加载，它实际上可能最终成为更大的图像或某种海报。

Addy Osmani：因此，当您尝试优化最大内容的绘画时，您可以做四件事。 第一件事是确保您尽早请求您的关键英雄形象。 通常，我们在页面中有许多重要的东西。 我们要确保我们可以渲染主页面的内容和布局。

Addy Osmani：对于布局，通常我们谈论的是 CSS。 因此，您可能在页面中使用关键 CSS、内联 CSS，希望避免出现渲染阻塞的情况，但是当涉及到您的图像时，理想情况下您应该尽早请求该图像。 考虑到我们现在很多人都依赖于框架，也许这只是确保浏览器可以尽早在页面中发现该图像。

Addy Osmani：如果您不一定使用 SSR，服务器端渲染，如果您正在等待浏览器发现您的一些 JavaScript 捆绑包，您的组件捆绑包，无论您是否有用于英雄图像或产品图像的组件，如果浏览器必须等待获取、解析、执行、编译和执行所有这些不同的文件才能发现图像，这可能意味着您最大的内容图像需要一些时间才能被发现。

Addy Osmani：现在，如果是这种情况，如果您发现自己在一个请求图像的地方很晚，您可以利用称为链接 rel preload 的浏览器功能来确保浏览器可以尽早发现该图像尽可能。 现在，预加载是一项非常强大的功能。 这也是你需要非常小心的一个。 这些天来，很容易到达一个地方，也许你听说我们建议为你的钥匙预装——

Addy Osmani：也许您听说我们建议为您的关键英雄图像、关键脚本和关键字体进行预加载。 它变得非常庞大，试图确保您以正确的顺序对事物进行排序。 因此，LCP 图像绝对是值得牢记的一个关键位置。

Addy Osmani：另一件事，正如我提到的四件事，另一件事是确保您使用源集和高效的现代图像格式。 我认为源集真的很强大。 我还看到有时人们在使用它时，他们会尝试过度补偿，并且可能会为每种可能的分辨率提供 10 个不同版本的图像。 至少在一些研究中，我们倾向于发现，除了三幅图像之外，用户很难分辨出图像质量、清晰度和细节方面的差异。 所以DPR capping，device pixel ratio capping，当然是一个值得牢记的想法。

Addy Osmani：对于现代图像格式，我们之前讨论过格式，但请考虑您的 WebP、AVIF、JPEG XL。 避免浪费像素。 制定良好的质量策略非常重要。 而且我认为在很多情况下，即使是默认质量有时也可能太多了。 所以我会尝试降低你的比特率，降低你的质量设置，看看你可以在保持清晰度的同时为你的用户做多远。

Addy Osmani：然后当我们谈论加载时，图像标签在过去几年中已经发展到支持的其他事情之一就是延迟加载。 因此，通过加载等于延迟，您不再需要使用 JavaScript 库来为您的图像添加延迟加载。 你只要把它放到你的图像上。 在 chromium 浏览器和 Firefox 中，您将能够延迟加载这些图像，而无需使用任何第三方依赖项。 这也很好。

Addy Osmani：所以，我们已经有了延迟加载。 我们已经获得了对同步解码等其他功能的支持，但我将继续进行下去，并快速讨论其他两个核心生命体征指标。

德鲁麦克莱伦：去吧，是的。

Addy Osmani：所以，摆脱布局变化。 没有人喜欢在他们的页面上跳跃的东西。 我觉得，我最大的挫折之一是我打开了一个网页。 我将手指悬停在我想点击的按钮上，然后突然出现一堆没有尺寸设置或其他东西的广告或图像。这会导致非常不愉快的体验。

Addy Osmani：所以累积布局转变试图衡量内容的不稳定性。 很多时候，推动布局转变的常见因素是页面上没有设置尺寸的图像或其他元素。 我认为这是人们通常可以直接设置图像尺寸的地方之一。 也许这不是我们历史上做过的事情，但肯定值得花时间去做。 在灯塔之类的工具中会尝试帮助您收集，例如您页面上需要尺寸的图像列表是什么？ 所以你可以去，你可以设置它们。

Drew McLellan：我想说，这是一个非常有趣的观点，因为当响应式网页设计成为一件事时，我们都浏览了我们的网站并去除了图像尺寸，因为我们可以使用的工具来完成这项工作需要我们没有我们的图像没有高度和宽度属性。 但现在这是个坏主意，不是吗？

Addy Osmani：旧的又是新的。 我会说绝对值得在您的图像上设置尺寸。 为您的广告、您的眼睛框架以及任何可能改变尺寸的动态内容设置尺寸都值得设置尺寸。

Addy Osmani：对于那些正在构建真正有趣的体验的人来说，那里是错误的短语，真正有趣的布局体验，也许你需要在响应卡等方面做更多的工作； 我会考虑使用 CSS 纵横比或纵横比框来保留您的空间。 这也可以补充这些图像的尺寸设置，以确保在您尝试避免布局变化时尽可能固定。

Addy Osmani：最后，最后一个 Core Web Vital 是第一个输入延迟。 这是人们在谈到图像时不一定总是想到的事情。 因此，图像实际上有可能在页面加载时阻塞用户的带宽和 CPU。 它们可能会妨碍其他关键资源的加载方式，特别是在连接速度非常慢或可能导致带宽饱和的低端移动设备上。

Addy Osmani：所以第一次输入延迟是一个核心 Web Vital 指标，它捕捉用户对网站交互性和响应能力的第一印象。 因此，通过减少主线程 CPU 使用率，您的第一次输入延迟也可以最小化。 所以一般来说，只要避免可能导致网络争用的图像。 他们没有渲染阻塞。 但它们仍然会间接影响您的渲染性能。

Drew McLellan：我们可以对图像做些什么来阻止它们的渲染阻塞？ 我们能否在初始阶段以某种方式减轻浏览器的负载，以使我们能够更快地进行交互？

Addy Osmani：我认为现在越来越重要的是要很好地理解正确的最佳图像序列以在首屏显示某些东西。 我知道首屏是一个重载的术语，但就像在用户的第一个视口中一样。 很多时候，我们最终可能会尝试请求大量资源，其中一些是图像，对于用户立即看到的内容来说并不是真正必要的。 这些往往是在页面生命周期后期加载的绝佳候选者，适合延迟加载的好东西。 但是，如果您要请求大量图像，例如很早之前的整个队列，则可能会产生影响。

德鲁麦克莱伦：是的。 所以，我的意思是，你提到了延迟加载图像，我们在历史上需要一个 JavaScript 库来完成，我认为这有其自身的挫折，因为浏览器优化加载图像的历史方式，几乎不可能阻止它们加载图像，除非你只是不给它一个来源。 如果你不给它一个源，然后尝试用 JavaScript 更正它，如果那个 JavaScript 没有运行，你就没有图像。 所以延迟加载，本机延迟加载是所有这些的答案。

Addy Osmani：是的，当然。 而且我认为这是我们尝试改进跨浏览器的地方，即去年的原生延迟加载体验。 如您所知，这是我们早期发布的功能之一，我们能够利用与行业思想领袖的对话来了解，“哦，嘿，您实际手动设置的阈值是多少如果您正在使用延迟大小，或者您正在使用其他 JavaScript 的延迟加载库？” 然后我们调整了我们的阈值，以尝试接近您期望它们的位置。

Addy Osmani：所以在很多情况下，您可以只使用本机延迟加载。 如果您需要更精细的东西，如果您需要更多地控制能够设置交叉点观察者阈值，浏览器何时请求事物的时间点，我们通常建议，在这些情况下使用库，只是因为我们试图解决 90% 的用例。 但是 10% 仍然有效。 可能有些人还需要更多的东西。 因此，对于大多数人来说，我希望原生延迟加载在可预见的未来足够好。

Drew McLellan：最重要的是，它是免费的。 添加一个简单的属性，您就可以免费获得所有这些功能，这很棒。 如果我们的听众可以做一件事，可以离开并在他们的网站上做以改善他们的图像优化，那会是什么？ 他们应该从哪里开始？

Addy Osmani：一个好的起点是了解这对您的网站有多大的问题。 我会去看看灯塔或支付速度见解。 在一些最受欢迎的页面上运行它，看看会出现什么。 如果看起来你只有一两件小事要做，那就太好了。 也许你可以花一些时间在那里。

Addy Osmani：如果你要做一长串事情，不妨看看你在其中拥有的最高机会，上面写着：“哦，嘿，如果你要做这件事，你可以节省几秒钟事物。” 并从一开始就集中精力。

Addy Osmani：正如我们在这里所讨论的，现代图像格式的工具随着时间的推移变得越来越好。 图像 CDN 绝对值得考虑。 但除此之外，您还可以采取许多小步骤。 有时，如果它是一个足够小的站点，即使只是打开并打开 Squoosh，将您的一些图像通过那里也可能是一个很好的起点。

德鲁麦克莱伦：这是可靠的建议。 现在我知道这是一本轰动一时的出版物，但我真的必须祝贺你出版了这本书。 它是如此全面，非常容易消化。 我认为这是一本非常有价值的读物。

Drew McLellan：所以我一直在学习图像优化。 你最近在学习什么，艾迪？

Addy Osmani：我最近学到了什么？ 实际上，在一个稍微不同的主题上仍然与图像有关，所以当我在大学攻读硕士学位时，我非常深入地研究计算机视觉并试图理解，我们如何检测图像的不同部分并进行狂野和有趣的事情？

Addy Osmani：我最近一直在研究的一个具体问题是，我一直在看自己小时候的照片。 那时，我父母带的很多食物不一定是在数码相机上。 他们是宝丽来。 它们通常是分辨率较低的图像。 我想要一种能够扩大规模的方法。 所以我最近又开始研究这个问题。 它让我更多地了解了我可以在浏览器中做什么。

Addy Osmani：所以我一直在构建一些小工具，让你可以使用机器学习、TensorFlow、现有技术拍摄分辨率相对较低的图像或插图，然后将它们升级到更高质量的图像。 所以这比简单地拉伸图像要好。 这就像实际填写详细信息一样。

Addy Osmani：这很有趣。 我一直在学习很多关于 Web 程序集现在跨浏览器的稳定性，以及您可以如何将其中一些想法用于桌面应用程序用例。 这真的很有趣。 所以我最近一直在研究很多 Web 程序集。 这很酷。

德鲁麦克莱伦：这很有趣，不是吗？ 当一项技术出现时，它会颠覆你所知道的一切。 我们一直说，在网络上，我们可以将图像变小。 但是，如果我们只有一个小图像，我们就无法将其放大。 这是不可能的。 但现在我们拥有的技术，在很多情况下，都可能使之成为可能。 这真的很迷人。

Drew McLellan：亲爱的听众，如果您想了解更多关于 Addie 的信息，您可以在 Twitter 上找到他的@AddieOsmani，并在 AddyOsmani.com 上找到他的所有项目链接。 Smashing 现在可以在 smashingmagazine.com 上获得“图像优化”一书的实体版和数字版。 感谢您今天加入我们，艾迪。 你有什么离别词吗？

Addy Osmani：有什么离别词吗？ 我有一点历史上的怪癖，我将与人们分享。 Tim Berners-Lee 于 1992 年将第一张图片上传到互联网。我不确定你是否能猜出它是什么，但你可能会感到惊讶。 德鲁，你有什么猜测吗？

德鲁麦克莱伦：我猜是一只猫。

Addy Osmani：一只猫。 这是一个很好的猜测，但不是。 这是在欧洲核子研究中心。 这张照片实际上是一支名为 Les Horribles Cernettes 的乐队，这是一支由一群 CERN 员工组成的模仿流行乐队。 他们会做的音乐就像doo-wop音乐。 他们会唱关于对撞机、怪癖、液氮和反物质的情歌，他们穿着六十年代的服装，我觉得这很美妙而且很随意。