问卷调查受访者对各种图片优化技巧的评论
Sam Dutton
本文列出了 Google Web DevRel 在 2019 年夏季图片优化技术调查问卷中收到的自由形式反馈。我们通过网站开发基础和 @ChromiumDev 征集了回复。这样做是为了找出为什么大多数网站没有遵循图片优化最佳实践（虽然这些最佳实践似乎是一种相对简单的提升效果的方法）。由于问卷调查方法存在缺陷，因此此处未列出回复数据。
受众群体
- 如果您是 Web 开发者，可能会发现本博文有助于发现新的图片优化技术，或详细了解其他 Web 开发者如何解决您遇到的问题，以及每种技术的成本、收益和限制。
- 如果您是图片服务或图片 CDN 提供商，这篇帖子可能有助于您找到新的市场机会。
- 如果您是框架、构建工具或 CMS 开发者，本博文可能会为您提供有关要实现的新功能的想法。
评论
WebP
- “我很喜欢 WebP，但还没有完全准备好。此外，我们的 WordPress 不支持 WebP。Photoshop 是最受欢迎的照片编辑应用之一，也不支持开箱即用的 WebP。因此，我们不能依赖第三方应用或服务对图片进行压缩。”
- "使 WebP 在 Safari 上可用。"
- “如果我能从 Photoshop/Figma/Sketch 以及所有支持 WebP 的浏览器导出 WebP，我就乐意使用 WebP。”[注意：Sketch 支持 WebP]
- “新一代格式设置解决方案会很棒。”
- "当浏览器支持能力较差时，别再费力地推行 WebP 了，而要考虑使用 PNG 而不是 JPEG 来生成屏幕截图。"
- “Google 文档不支持 WebP。”
- “我们会只使用 WebP，但担心浏览器的兼容性。”
- “先修复浏览器兼容性，然后更新旧版浏览器或添加旧版修复程序，这样用户就更倾向于采用 WebP 等新图片类型...”
- "鼓励插件/主题开发者考虑为 WebP 和其他新一代图片类型提供支持，这样非开发者就不必费心去处理。"
SVG 和矢量图片
- “如果可能，我将使用（动画形式的）SVG。gatsby-image 解决了许多问题。但是，深入研究它们的功用，再想想也不现实：一个普通的网站必须构建这样的设计才能使图片正常显示，这是完全不切实际的。浏览器应承担更多这种责任。"
- “能否用 lottie.js 记录如何创建 SVG 动画？”
- “我们多数情况下都尝试在网站中使用低尺寸的大分辨率 JPEG 图片，以避免加载时间。我们还会确保在必要时使用 SVG，以提升自适应设计的质量。”
- “如果可能，我们会尝试对除图片之外的所有图片使用经过优化的矢量图形。”
其他图片格式
- “我们 [需要] 更好地教育人们，让他们停止使用 GIF。”
延迟加载
- "在考虑延迟加载等功能时，请为用户着想，因为这对很多人来说很烦人。"
- "让延迟加载属性对背景图片使用。"
- "框架应该能提供更出色的开箱即用型资产处理能力。"
- “很久之前，我们就已经从延迟加载转向。用户报告数百万图片和网站“未加载”。这就是我们团队对你的总结的理解。非技术用户很难描述问题。”
- “我希望更好地了解使用 Intersection Observer API 进行延迟加载，而不是使用传统技术。”
- “这非常适合我：pwafire.org/developer/codelabs/progressive-loading。”
背景图片
- "我通常会在 CSS 中将图片作为背景加载。"
- “
<img>标记存在问题，难以控制，尤其是用户提交的内容的精细细节。我们更多地使用<div>和背景图片样式，因为这支持我们使用背景大小和背景位置，并且不必右键点击图片即可保存图片。”
透明度
- “现在是 2019 年，JPG 如何仍然没有 alpha 透明度？"
- “我只在需要透明背景时才对照片使用 PNG 格式。”
低质量图片占位符 (LQIP)
- “我们采用 LQIPS，这是一种绝佳的技术，可以有效保持对访问者的吸引力，而不会提前加载高质量的图片。”
性能
- “实际上，我们最近在图片方面遇到了性能问题。当用户向下滚动浏览我们的网站时，我们会显示接下来的 60 张卡片，其中包含一个缩略图。由于同一网域设有 6 个连接限制，缩略图以及下一个 AJAX 请求都会被阻止，当用户继续向下滚动时，系统将无法继续获取下 60 张卡片。”
- “我们很想使用 HTTP/2，但是我们的大多数客户都使用 IE11！因此，我们正在探索域分片 / 加载其他域之外的 AJAX JSON 数据请求。”
大小
- “抱歉固有大小；我觉得利用高度/宽度似乎更好。”
- "正在寻找生成较少大小的方法，现在它只有 12 个左右。"
- "没有 JS，动态调整图像大小是非常困难且无法实现的。"
- “responsivebreakpoints.com 这样的工具非常适合 web.dev :)。”
高画质和高分辨率图片
- "如何在不损失 DPI 质量的情况下下载压缩图片？"
- “我们是一家文件管理公司。我们的应用处理数百万张高分辨率扫描图像，通常为 TIFF 或 PDF。”
- “这很麻烦。对于印刷格式，必须使用高分辨率的 img 文件；但必须针对网络进行优化。缩小 Web 图片的大小非常麻烦，但如果作者只为用于印刷发布的图片提供轻量级文件，则这样会非常麻烦。最终，我们会发布多种信息，说明有关提交手稿和艺术作品的要求。最终，我们完成了处理这些材料的复杂工作流。”
浏览器功能
- “从浏览器进行自动自适应 src 剪裁，因为 [内置] 功能非常实用，因为将所有图片剪裁为 4 种尺寸并编写所有标记非常耗时。如果我们能够上传一张大照片并编写一个简单的图片标记，则浏览器将自动创建多个 src 属性，这就是胜出的功能。"
- “就我个人而言，当 CSS 为自适应图片设置具有 的图片（最大宽度：100%；高度自动或高度：宽度：100%；高度自动；高度自动）时，我很难避免页面重排，尤其是与自适应图片/图片代码的艺术指导相结合时。为避免这种情况，最佳方式似乎是对固定图片宽高比使用“负填充黑客”，然后将图片放置到此比例框内。更好的浏览器支持/响应式图片处理会大有帮助！”
- “请仅提取第一帧，停用 GIF 的‘自动播放’功能。”
CDN 和图片服务
- “Google 应该提供 Cloudflare 这样的免费 CDN。”
- “也许有更多工具能帮助不同提供商设置动态扩缩和 CDN。”
- “单张超大的过度压缩图像是一个非常不错的解决方案，没有额外的制作成本。对于移动设备，您需提供大约 1000 像素的宽图片（呈现宽度为 500 像素），这也是大型/桌面设备非 Retina 显示屏所需的尺寸。虽然我以前使用过，但我认为调整 CDN 的图片大小是一个非常糟糕的解决方案。CMS 应处理大小调整，而这过于复杂，难以设置，（目前）单一解决方案是一个不错的折衷方案。”
- “CloudFlare 自动缩放我们的图片，以完美匹配用户的显示屏。这样我们可以节省加载时间，因为图片是相对于用户显示屏进行加载的。例如，如果用户正在使用手机，则相应内容无法在与桌面设备大小的背景中加载。"
- “Cloudflare 在后台执行此操作，我们无需执行任何操作，只需选中设置面板中的复选框即可。”
- “重申一下，我能够成功使用 srcset 等的唯一原因是 Cloudinary 的易用性。但 Cloudinary 变得昂贵，非常快速。这就像是开发体验中的一个重大漏洞。”
- “我们需要一种以智能方式轻松自动剪裁图片的方式，以便它们能够在不同的环境中支持不同的宽高比。”
- “我还会使用 Unsplash 等其他提供商，对分辨率、画质和压缩的控制力度非常低。”
CMS、平台和框架
- “在使用 CMS 构建网站时，我仍然难以确定使用图片的最佳方式。作者往往会配置不同尺寸的图片，并希望图片不会缩小或缩放。我不确定是否可以在图片上设置最大宽度或最大高度”
- “在最后几个项目中一直在使用 gatsby-image，而且从未回头。”
- “图片通常是最困难的部分，因为最终用户将它们放入 CMS 中，它们可能使用任何大小和格式，有时理想图片格式和尺寸的原始图片不可用。”
- “由于我们的系统是自助添加控件，因此图片维护起来很困难，除非一切都自动发生而不会影响分辨率。另外，对我们而言，图片在移动设备和桌面设备上的显示效果不正确”
- “我帮助用户优化网站 (WordPress)。我遇到过的图片最大的问题是：需要依赖 CDN 或插件来创建 WebP。主题开发者必须对 srcset/picture 进行正确编码。大多数延迟加载插件都加载速度缓慢，导致用户体验不佳。背景图片很难延迟加载。"
成本/效益
- “新做法虽然有效，但会增加网站的开发时间。”
- “许多财富 500 强公司都未遵循 srcset 和 WebP 等新标准，慢慢采用。鉴于这种情况，许多公司拒绝了这一改变，因为这对当前网站来说是不必要的开发成本。最终用户 (UX) 并没有广泛讨论或报告性能提升效果。如果有的话，这会增加保存网上图片的难度。”
- “创建和管理多种尺寸和版本的成本很高。”
- “它们占用了大量服务器空间。”
搜索引擎优化 (SEO)
- "我们很难在可接受的图片质量和文件大小之间取得平衡。一方面，我希望快速加载，有利于 SEO，但另一方面，图片质量不佳会削弱界面/用户体验。”
图片在网络上的作用
- “网络上的太多了，停止使用无用图片无益于改善文字内容。"
- “你还记得网络没有图片，我们以 ASCII-art 格式分享自拍照的那一天吗？”
工具、指南、标准和最佳实践：问题和请求
- [一位参与者撰写了一篇博文以回复此次调查]
- “需求似乎在不断变化。作为 Web 开发者，这非常令人沮丧，因为从一开始就要花费大量时间保存图片。我们竭尽全力进行优化，检查了相关网站。几个月后，Google 决定将这些图片进一步压缩，或者采用其他格式。这阻碍了我们向客户提供长效的最佳解决方案，反而让他们和我们付出了巨大的努力。我们的一些小型企业客户根本没有预算来继续修正图片并重新保存以符合相关要求。我们没有预算在他们的管理套餐中完成这项工作。编写相应代码来针对不同设备调用不同大小的图片也非常耗时。我希望能设计出一个保存更长时间的图片来保存图片，这真是太棒了。”
- “是，我想您在 Lighthouse 中遇到的‘保持请求数量少，文件大小保持小’全都错误的问题。如果网站通过 HTTP1.x 提供内容，那当然，但如果网站通过 HTTP2 提供内容，那么对于来自同一主机名的请求，请求数量没那么重要，甚至不算问题。我有一个精简版网站，但我在同一主机名上通过 HTTP2 加载了 30 个小型 WebP 文件，文件总数约为 35 个请求。Lighthouse 将此问题标记为“保持请求计数较少且文件大小保持小”问题，尽管它速度超快，并且由于同一主机名上使用了 HTTP2，请求数量不是问题。没错，文件已经很小（大多数文件在 1 KB 到 2 KB 或更小之间）。我可以加载一个精灵，但之后还需要执行更多的 CSS 计算。因此，请更新 Lighthouse 中的“Keep Request Counts Low and File Sizes Small”报告，以便将 HTTP2 用于同一主机名。”
- “人们很难记住压缩图像。”
- "跨浏览器行为仍然不可预测，因此最简单的解决方案往往是最安全的。"