你应该使用哪种响应式图片解决方案？

最近有很多关于处理**响应式图片**的技术。 也就是说，帮助我们根据情况（例如屏幕大小和可用带宽）提供正确图片的解决方案。 它们都以略微不同的方式执行操作。为了跟踪这些技术，Christopher Schmitt 和我创建了 这个技术电子表格。

电子表格包含数据，但让我们通过实用问题的角度来理解它。

要选择适合您和您的项目的技术，以下问题可以作为指南。 许多问题可能适用于您的项目，因此您需要确定哪些技术适合哪些场景，并找到重叠之处。

我是否有遗留内容？

这实际上意味着……**我是否有更新起来不切实际的遗留内容？**例如，我在 CSS-Tricks 上有数千页的内容，只有一个写作人员。

我所知的唯一无需任何标记更改即可使用的技术是 自适应图像。 它通过将图像请求路由到 PHP 文件来工作，该文件智能地提供（并在需要时创建）适合屏幕宽度的图像。

另一个需要自问的问题是您是否关心遗留内容。 也许您网站的大部分流量都来自您**可以**进行标记更改的新内容，从而利用其他技术。 如果是这样，请继续阅读以发现这些其他技术。

如果您有一个小型项目、一个全新的项目或一个具有遗留内容并且您可以回溯更新的项目，您也可以选择一种确实需要特殊标记的技术，因此也请继续阅读。

我是否关心特殊标记？

这实际上是上述问题的子问题。 许多技术要求您使用特殊的 HTML。 例如，HiSRC 要求您将更高分辨率的图像作为数据属性。

<img src="200x100.png" data-1x="400x200.png" data-2x="800x400.png" />

我认为这是一种简洁、有效、语义化的技术，但它也意味着您需要在网站上的每个<img />上使用这些属性，这在具有大量遗留内容的网站上可能无法实现。

如果您知道特殊标记（或专门的 CSS）对您来说不是一种选择，那么真正唯一的选择是 自适应图像。 即使 Sencha.IO 也需要为 src 属性添加前缀，这在遗留内容中可能无法实现。

我是否关心语义？

一些响应式图像技术涉及并非严格语义化的标记。 最终，图像只有一个语义化的方式。 那就是如果它的src指向一个真实的图像，并且它具有描述该图像的alt文本。 Brad Frost 对此进行了很好的总结

@stowball 不幸的是，它没有那么简单。 马的图片必须是马的图片，否则它就不是马的图片。 :)

— Brad Frost (@brad_frost) 2012年4月5日

换句话说，如果该技术在任何时候需要图像的src丢失或链接到透明 GIF（或类似内容），则该技术不是语义化的。

那么为什么一些响应式图像技术会这样做呢？ 因为让图像的src指向马的图像意味着该图像将在浏览器解析该图像后立即开始下载。 没有办法阻止这种情况。 即使您非常快速地用更合适的版本替换该src，现在您也正在下载两个图像而不是一个图像，这会降低性能而不是提高性能。 您可能会认为这是可以接受的（例如，“桌面”环境通常具有更大的带宽）。 通常，如果使用此技术，则src中的图像将是最小可能的图像。

如果语义对您很重要，您应该查看 自适应图像（如上所述）或 HiSRC，这是 Christopher Schmitt 的一个插件，您可以将其与语义化的src属性一起使用。

一些技术使用

我是否关心有效性？

有效性是指根据 W3C 标记验证服务“是否验证通过”。 验证是一种帮助您查找问题并编写更好标记的工具。 但仅仅因为某些内容未通过验证并不意味着它不好或错误。 如果无效代码在所有浏览器中都能完美运行，那么您或任何其他人都不应该关心。

如果您确实关心有效性（也许客户不合理地要求您这样做，并以此为筹码扣留您的工资），那么您将无法使用一些技术。 例如，picturefill 技术使用<picture></picture>元素来发挥其魔力。 这最终可能会标准化，但尚未标准化，因此在技术上是无效的语法。 它也要求<img />元素具有src属性，因此为了解决双图像请求问题而删除该属性的技术是无效的。

如果有效性是您的要求，我建议使用以下技术：自适应图像、HiSRC 或 响应式增强。 它们都使用简单、有效的<img />语法，包括src。

我是否关心艺术指导？

一些响应式图像技术提供完全相同图像的不同分辨率版本。 虽然这简化了操作（即减少了工作量），但它可能无法接受。 这是一个直观的例子

这些图像由设计师手工制作，裁剪以保留意义和影响。 如果您取右侧的图像并将其缩小，图像中的人会非常小，并且图像的风格可能会丢失。

如果这个艺术指导的想法对您的项目很重要，您将需要一种可以允许您指定在什么情况下提供哪个src的技术。 这非常适合 picturefill，它允许您非常具体地指定源以及什么情况下获得什么。

<picture>
  <source src="small.jpg" />
  <source src="medium.jpg" media="(min-width: 400px)" />
  <source src="large.jpg" media="(min-width: 800px)" />
</picture>

JavaScript 会从那里接管。

我是否关心 JavaScript？

大多数这些响应式图像技术都利用 JavaScript 来发挥其魔力。 一些只使用少量的 JavaScript 来设置 cookie，但仍然是 JavaScript。 有些要求您将<img />放在

JavaScript 库依赖性怎么办？

HiSRC 和 rwdImages 都依赖于 jQuery。如果你的项目使用了不同的库，那么这些方案可能不适合你。不过，你可以移植它们并开源！如果你没有使用任何库，嗯，你可能应该使用，但我们现在不讨论这个。

我需要关心服务器端组件吗？

其中一些技术并非完全依赖于 JavaScript。 自适应图片 主要通过 .htaccess 和 PHP 来实现其功能。嗯，.htaccess 预设了一个 Apache 服务器。当然，我们都知道并热爱 PHP（咳咳），但许多网站运行在 Ruby 或 Python 等技术之上。

响应式图片（最初的 Filament Group 技术）也使用 .htaccess。因此，如果你使用的是像 Nginx 这样的 Web 服务器，那么这种方案要么不可行，要么你必须将 .htaccess 组件移植到 Nginx 的类似但不同的语法中。

我需要关心带宽测试吗？

测试浏览器窗口宽度并根据它决定要提供哪张图片非常酷，并且是响应式图片概念的基础。但这实际上只是决定应该提供哪张图片的一半因素。另一半是可用带宽。如果用户拥有非常快速的网络连接速度，那么提供大图片是可以的。如果用户拥有非常慢的网络连接速度，那么他们应该获得更小的图片（无论屏幕尺寸如何）。不幸的是，原生 带宽媒体查询 不存在。

目前有两种技术将带宽测试作为其决策过程的一部分：Foresight.js 和 HiSRC（两者都基于 Foresight.js 中的技术）。它的工作原理是下载一个测试文件并测量完成所需时间（可配置）。测试本身会略微影响性能，但理论上，通过了解当前带宽来提供图片所节省的开销是一个净（明白了吗？）收益。

我需要关心依赖第三方吗？

Sencha.IO 是一种完全由第三方提供的处理响应式图片的方式。据我所知，它运行良好，并且没有出现任何重大停机时间，但当然你始终存在这种风险。

你可能在想：哇，Sencha.IO 技术真的很酷，但我担心第三方依赖性。我希望我可以在自己的服务器上运行它。 如果你想走这条路，可以使用公开的 WURFL 数据库 和这个 服务器端响应式图片技术，它可以在本地使用该数据库。

还有一些像 Device Atlas Cloud 这样的第三方服务，它可以为你进行设备检测。它也是你应用程序的第三方依赖项。毫无疑问，他们的目标和重点是始终保持可用和快速，但你必须非常小心地选择你依赖的机构和服务，尤其是对于你的业务而言。

另外一些第三方服务：ReSRC.it，Responsive.io，Thumber.io

是否有特定 CMS 涉及特定 CMS 功能？

假设你的项目在 WordPress 中。WordPress 内置了媒体上传器。当你使用它上传图片时，它可以为你创建该图片的多个版本（缩小）。这非常酷且强大，你可以/应该利用它。

但这不仅仅是 WordPress 的功能。我相信这里的工作原理可以在任何内容管理系统中实现（或使其能够实现）。

只要解决方案是移动优先，我需要关心双重请求吗？

许多这些解决方案试图以最佳方式解决问题：只对正确的资源发出一个请求。如果你可以接受链接到文件的最小版本（以便无论如何都会发出该请求）并在需要时替换为更大的图片，那么也许 源代码混排 适合你。请注意，现在使用的库 建议使用 font-family 而不是 content 来检测媒体查询的变化。

我可以等待未来吗？

“新 iPad”（第三代，为了持久性）的发布引发了许多这些技术和对话。它高像素密度非常适合矢量图和大型照片，但实际上不适合需要放大到正确尺寸的小图标，并且可能会出现模糊。但是提供更高分辨率的图标意味着更大的文件大小和更慢的网站。因此，需要只在需要的情况下/环境中提供它们。

Web 标准领域意识到了这个问题。有一个 专门讨论它的团队。随着时间的推移，他们可能会解决这个问题，然后我们可以开始使用他们想出的任何方法（假设它很棒并且比我们现在拥有的更好）。

它可能是像 Nicolas Gallagher 建议的那样 通过 CSS 内容切换图片的 src 属性。它可能是 <picture></picture> 元素。它可能是 HTML 中的 srclist 属性或 CSS 中的 src 属性。它可能是一个 前缀。

它可能是发送浏览器信息请求，就像在 Client-Hints 中一样。

更多资源

• Jason Grigsby 撰写了一篇关于响应式图片的史诗级三部分系列文章，从这里开始。
• Christopher Schmitt 的 关于响应式图片的完整演讲幻灯片。
• Mat Marquis 关于 响应式图片：它们是如何几乎成功以及我们还需要什么 的文章。