2019 年夏季图片优化问卷调查的反馈

调查问卷回复者对各种图片优化技术的评论

本文列出了 Google Web DevRel 在 2019 年夏季图片优化技术调查中收到的自由格式反馈。 我们通过网站开发基础和 @ChromiumDev 征集了回复。开展这项调查的初衷是想了解,为什么大多数网站都没有遵循图片优化最佳实践,尽管这些实践似乎是提高性能的一种相对简单的方法。由于调查问卷方法存在缺陷,因此此处未列出回复数据。

受众群体

  • 如果您是 Web 开发者,您可能会发现,本文有助于您发现新的图片优化技术,或详细了解其他 Web 开发者如何解决您面临的问题,以及每种技术的成本、优势和局限性。
  • 如果您是图片服务或图片 CDN 提供商,本文可能会帮助您找到新的市场机会。
  • 如果您是框架、构建工具或 CMS 开发者,本文可能会为您提供有关要实现的新功能的想法。

评论

WebP

  • “我确实喜欢 WebP,但它尚未完全准备就绪。此外,我们的 WordPress 不支持 WebP。最受欢迎的照片编辑应用之一 Photoshop 也不支持 WebP。因此,我们无法依赖第三方应用或服务来压缩图片。”
  • “让 WebP 能够在 Safari 上使用。”
  • “如果能从 Photoshop/Figma/Sketch 导出 WebP,并且所有浏览器都支持 WebP,我很乐意使用它。”[注意:Sketch 支持 WebP]
  • “新一代格式化解决方案会很棒。”
  • “在浏览器支持不佳的情况下,不要如此大力地推广 WebP,并考虑在屏幕截图中使用 PNG 而非 JPEG。”
  • “Google 文档不支持 WebP。”
  • “我们想只使用 WebP,但担心浏览器兼容性问题。”
  • “首先修复浏览器兼容性问题,更新旧版浏览器或添加旧版修复程序,然后用户会更倾向于采用 WebP 等新图片类型…”
  • “鼓励插件/主题开发者考虑提供对 WebP 和其他新一代图片类型的支持,这样非开发者就不需要费心处理了。”

SVG 和矢量图像

  • “如果可能,我会使用(动画)SVG。gatsby-image 解决了许多此类问题。但如果你深入研究他们的做法,就会发现,一个普通网站为了让图片正常显示而不得不构建这样的系统,这完全不切实际。浏览器应该承担更多这方面的责任。”
  • “能否记录如何使用 lottie.js 创建 SVG 动画?”
  • “大多数情况下,我们都会尽量在网站中使用分辨率高、文件小的 JPEG 图片,以避免加载时间过长。我们还确保在必要时使用 SVG,以提供优质的自适应设计。”
  • “我们尽量对除图片以外的所有内容使用经过优化的矢量图形。”

其他图片格式

  • “我们 [需要] 更好地教育人们停止使用 GIF。”

延迟加载

  • “在考虑延迟加载等功能时,请务必考虑用户体验,因为对许多人来说,这种功能很烦人。”
  • “请让延迟加载属性与 background-image 搭配使用。”
  • “框架应该开箱即用地提供更好的资源处理功能。”
  • “我们很久以前就从延迟加载转换过来了。用户报告称,数百万张图片和网站“无法加载”。这是我们团队总结的理解。非技术用户很难描述问题。”
  • “我希望更好地了解如何使用 Intersection Observer API 进行延迟加载,而不是使用传统技术。”
  • “这个网站对我来说很好用:pwafire.org/developer/codelabs/progressive-loading。”

背景图片

  • “我通常在 CSS 中将图片作为背景加载。”
  • “<img> 标记存在问题,很难控制其细粒度细节,尤其是在用户提交的内容中。我们更常使用 <div> 和 background-image 样式,因为这样可以使用 background-size、background-position,并防止通过右键点击保存图片。”

透明度

  • “现在是 2019 年。JPG 怎么还是没有 Alpha 透明度?
  • “我只在需要透明背景时才会使用 PNG 格式的照片。”

低质量图片占位符 (LQIP)

  • “我们使用 LQIP,这是一种非常棒的技术,可以让访问者保持互动,而无需过早加载高画质图片。”

性能

  • “我们最近确实遇到了图片性能问题。当用户在我们的网站上向下滚动时,我们会显示接下来的 60 张卡片,其中包含缩略图。由于同一网域存在 6 个连接的限制,缩略图以及用于在用户继续向下滚动时获取后续 60 张卡片的下一个 AJAX 请求都会被屏蔽。”
  • “我们很想使用 HTTP/2,但我们的大多数客户都使用 IE11!因此,我们正在探索网域分片/从其他网域加载 AJAX JSON 数据请求。”

大小

  • “抱歉,intrinsicsize 属性不合适;我认为利用 height/width 属性似乎更好。”
  • “正在寻找一种方法来减少尺寸数量,目前大约有 12 种。”
  • “动态调整图片大小非常困难,如果不使用 JS,根本无法实现。”
  • “responsivebreakpoints.com 之类的工具非常适合 web.dev :)。”

高画质和高分辨率图片

  • “如何在不降低 DPI 质量的情况下下载压缩图片?”
  • “我们是一家文档管理公司。我们的应用会处理数百万张高分辨率扫描图片,通常是 TIFF 或 PDF 格式。”
  • “这太麻烦了。高分辨率图片文件是印刷格式所必需的;必须针对网络进行优化。虽然为网页缩小图片尺寸很麻烦,但如果作者只为要印刷出版的图片提供轻量级文件,那才是真正的灾难。我们最终给出了关于提交带有插图的手稿的要求的混合信息。最终,我们不得不采用复杂的工作流来处理这些资料。”

浏览器功能

  • “如果能将‘从浏览器自动自适应剪裁 src’作为 [内置] 功能,那将非常有用,因为将所有图片剪裁成 4 种尺寸并编写所有标记非常耗时。如果我们能上传一张大照片,并编写一个简单的图片标记,让浏览器自动创建多个 src 属性,那将是一个非常棒的功能。”
  • “就我个人而言,当通过 CSS 为自适应图片设置图片宽度(max-width: 100%; height auto 或 height: width: 100%; height auto)时,我很难避免页面重排,尤其是在结合使用自适应图片/图片标签的艺术指导时。避免这种情况的最佳方法似乎是使用“负内边距技巧”来固定图片宽高比,然后将图片放置在此宽高比框内。如果能提供更好的浏览器支持/自适应图片处理,那就太棒了!”
  • “请仅提取第一帧,以停用 GIF‘自动播放’。”

CDN 和图片服务

  • “Google 应该提供像 Cloudflare 这样的免费 CDN。”
  • “如果能有更多工具来设置动态扩缩和不同提供商的 CDN,那就更好了。”
  • “单张超大、过度压缩的图片是一种非常不错的解决方案,不会产生额外的制作成本。对于移动设备(500 像素渲染宽度),您需要大约 1000 像素宽度的图片,这也是大型/桌面非 Retina 显示屏所需的尺寸。我认为图片调整大小 CDN 是一个非常糟糕的解决方案,尽管我过去曾使用过它。CMS 应负责调整大小,如果设置起来太复杂,那么单一解决方案是一个不错的折衷方案(目前)。
  • “CloudFlare 会自动缩放我们的图片,以尽可能匹配用户的显示屏。这样,我们就可以节省加载时间,因为图片是根据用户的显示屏加载的。例如,如果用户使用的是手机,则不会加载桌面设备尺寸的背景。”
  • “Cloudflare 在后台完成这项工作,我们只需在设置面板中勾选一个复选框,无需执行任何其他操作。”
  • “重申一下,我之所以能成功使用 srcset 等,唯一的原因就是 Cloudinary 简单易用。但 Cloudinary 的费用很快就会变得非常高。这感觉像是开发体验中的一个大漏洞。”
  • “我们需要一种能够轻松、智能地自动剪裁图片的方法,以便图片在不同情境下能以不同的宽高比呈现。”
  • “我还会使用 Unsplash 等其他提供商的图片,这些图片的分辨率、质量和压缩率很难控制。”

CMS、平台和框架

  • “在使用 CMS 构建网站时,我仍然很难找到使用图片的最佳方式。作者往往会配置不同尺寸的图片,并希望图片不会缩小或缩放。我不确定是否可以为图片设置 max-width 或 max-height”
  • “在过去几个项目中,我一直在使用 gatsby-image,并且从未后悔过。”
  • “图片通常是难点,因为它们是由最终用户放入 CMS 的,用户可能会使用任何尺寸、格式,有时无法提供理想图片格式和尺寸的原始图片。”
  • “图片很难维护,因为我们的系统是自助式的,除非在不影响分辨率的情况下自动执行操作,否则很难添加控制措施。此外,我们还发现图片在移动设备和桌面设备上的显示效果不一致”
  • “我帮助用户优化其网站 (WordPress)。我发现图片方面存在以下最大问题:需要依赖 CDN 或插件来创建 WebP。srcset/picture 必须由主题开发者正确编码。大多数延迟加载插件加载速度缓慢,导致用户体验不佳。背景图片很难延迟加载。”

成本/效益

  • “新做法很有效,但会增加网站的开发时间。”
  • “许多《财富》500 强公司在采用 srcset 和 WebP 等新标准方面进展缓慢。有鉴于此,许多公司都抵制这一变化,认为这是当前网站不必要的开发成本。最终用户 (UX) 很少讨论或报告性能提升。如果说有什么影响,那就是从网上保存图片变得稍微困难了一些。”
  • “制作和管理多个尺寸和版本,成本太高。”
  • “它们会占用我们服务器上的大量空间。”

SEO

  • “很难在可接受的图片质量和文件大小之间取得平衡。一方面,我希望快速加载以提升 SEO 效果,但另一方面,低质量的图片会影响界面/用户体验。”

图片在网络中的作用

  • “网上的信息太多了。停止使用无法增强文字内容的无用图片。”
  • “你还记得那个网络上没有图片、我们用 ASCII 艺术分享自拍的时代吗?”

工具、指南、标准和最佳实践:遇到的问题和提出的请求

  • [一位参与者针对此调查撰写了一篇博文]
  • “要求似乎一直在变。作为 Web 开发者,这非常令人沮丧,因为首先保存图片就很耗时。我们尽最大努力进行优化,检查网站,但几个月后,Google 却认为图片可以进一步压缩,或者需要采用其他格式。这会妨碍我们为客户提供持久的最佳解决方案,反而会给客户和我们带来高昂的成本。我们的一些小型企业客户根本没有预算让我们不断修正图片并重新保存,以符合要求。我们没有足够的预算来在他们的管理套餐中完成这项工作。此外,编写代码来为不同设备调用不同尺寸的图片也需要耗费时间。如果能想出一个可以长期保持一致的图片保存系统,那就太好了。”
  • “是的,我认为您对 Lighthouse 中的‘保持较低的请求数和较小的文件大小’存在误解。如果网站通过 HTTP1.x 提供服务,那么确实如此;但如果网站通过 HTTP2 提供服务,那么请求数量就不那么重要了,如果请求来自同一主机名,甚至根本不是问题。我有一个轻量级网站,但我在同一主机名上通过 HTTP2 加载了 30 个小型 WebP 文件,总共约 35 个请求。Lighthouse 将此问题标记为“保持较低的请求数和较小的文件大小”,但由于同一主机名上使用了 HTTP2,因此请求数不是问题,而且速度非常快。是的,这些文件已经很小了(大多数在 1 KB 到 2 KB 之间,甚至更小)。我可以加载一个精灵,但随后需要进行更多 CSS 计算。因此,请更新 Lighthouse 中的“保持较低的请求数和较小的文件大小”报告,将通过同一主机名使用 HTTP2 的情况考虑在内。”
  • “人们很难记住要压缩图片。”
  • “跨浏览器行为仍然无法预测,因此最简单的解决方案通常是最安全的。”