一种尺寸适合一些人：响应式网页设计图像解决方案指南

已发表: 2022-03-11

随着移动和平板设备越来越接近最终统治世界，网页设计和技术正在竞相适应不断增长的屏幕尺寸。 然而，设计工具来应对这一现象的挑战带来了一系列全新的问题，其中一个最新流行词是“响应式网络”。 这是在不降低用户体验的情况下使网络在大多数（如果不是全部）设备上运行的挑战。 无需设计适合台式机或笔记本电脑的内容，信息必须可用于手机、平板电脑或任何连接到网络的表面。 然而，这种响应式网页设计的演变已被证明是一个困难的，有时甚至是痛苦的。

虽然容纳文本信息几乎是微不足道的，但当我们考虑到响应式图像、信息图表、视频等内容时，棘手的部分就出现了，这些内容曾经设计时只考虑桌面。 这不仅提出了正确显示内容的问题，而且还提出了如何使用不同的设备消费内容本身。 智能手机上的用户与台式机上的用户不同。 还必须考虑数据计划和处理速度等因素。 谷歌已开始在其搜索结果中突出显示适合移动设备的网站，一些人推测这将大幅提升此类网站的页面排名。 早期的解决方案通过部署仅限移动设备的子域（和重定向）解决了这个问题，但这增加了复杂性并且很快就过时了。 （并非每个站点都有能力负担这条路线。）

关于响应式 Web 图像的探索

响应式网页设计图像必须简单地缩放以适应现代常见的设备。

此时，开发人员和设计人员必须确保优化他们的网站负载以满足移动网站上的用户。 现在超过 20% 的网络流量是移动用户，而且这个数字还在上升。 由于图像占据了页面内容数据的最大份额，因此减少这种负载成为当务之急。 已经进行了几次尝试来简化响应式设计图像大小调整，包括服务器端和前端解决方案。 要讨论这些响应式图像解决方案，我们首先需要了解当前图像链接的缺点。

<img>标签只有 source 属性直接链接到图像本身。 如果没有任何附加组件，它无法确定所需的正确图像类型。

难道我们不能只包含 HTML 中包含的所有图像大小，并使用 CSS 规则来display:none除了正确的图像之外的所有图像？ 这是完美逻辑世界中最合乎逻辑的解决方案。 这样浏览器可以忽略所有未显示的图像，并且理论上不会下载它们。 但是，浏览器的优化超出了常见的逻辑。 为了使页面渲染得足够快，浏览器会在必要的样式表和 JavaScript 文件完全加载之前预取链接的内容。 我们最终没有忽略用于桌面的大图像，而是下载了所有图像并导致更大的页面加载。 CSS-only 技术仅适用于用作背景图像的图像，因为这些可以在样式表中设置（使用媒体查询）。

那么，网站要做什么呢？

后端响应式图像缩放解决方案

后端解决方案非常适合在响应式网页设计情况下处理图像大小。

除了移动站点/子域之外，我们只剩下嗅探用户代理 (UA) 并使用它来将正确大小的图像返回给用户。 但是，任何开发人员都可以证明此解决方案的不可靠程度。 新的 UA 字符串一直在不断弹出，使得维护和更新一个完整的列表变得很费劲。 当然，这甚至没有首先考虑到容易被欺骗的 UA 字符串的不可靠性。

自适应图像

但是，一些服务器端解决方案值得考虑。 对于那些喜欢后端响应式图像修复的人来说，自适应图像是一个很好的解决方案。 它不需要任何特殊标记，而是使用一个小的 JavaScript 文件，并在其后端文件中完成大部分繁重的工作。 它使用 PHP 和 nginx 配置的服务器。 它也不依赖任何 UA 嗅探，而是检查屏幕宽度。 自适应图像非常适合缩小图像，但在需要艺术指导的大图像时也很方便，即通过裁剪和旋转等技术来缩小图像 - 而不仅仅是缩放。

煎茶触摸

Sencha Touch 是另一种后端响应式设计图像解决方案，尽管将其称为第三方解决方案更好。 Sencha Touch 将通过嗅探 UA 来相应地调整图像大小。 以下是该服务如何工作的基本示例：

 <img src="http://src.sencha.io/http://example.com/images/kitty_cat.jpg" alt="My Kitty Cat">

还有一个选项可以指定图像大小，以防我们不希望 Sencha 自动调整图像大小。

归根结底，服务器端（和第三方）解决方案需要资源来处理请求，然后再发回正确的图像。 这需要宝贵的时间，进而减慢请求-响应行程。 更好的解决方案可能是设备本身确定要直接请求哪些资源，并且服务器做出相应的响应。

前端解决方案

前端响应式设计图像缩放解决方案是优化网站负载的绝佳选择。

最近，浏览器端在处理响应式图像方面有了很大的改进。

<picture>元素已由 W3C 在 HTML5 规范中引入和批准。 它目前并未在所有浏览器上广泛使用，但不久之后它就可以原生使用。 在那之前，我们依赖于 JavaScript 的 polyfills 来处理元素。 对于缺少该元素的旧版浏览器，Polyfills 也是一个很好的解决方案。

还有一种情况是srcset属性可用于多个基于 webKit 的浏览器的<img>元素。 这可以在没有任何 JavaScript 的情况下使用，如果要忽略非 webKit 浏览器，这是一个很好的解决方案。 对于其他解决方案不足的奇怪情况，这是一个有用的权宜之计，但不应被视为全面的解决方案。

图片填充

Picturefill 是<picture>元素的 polyfill 库。 它是响应式图像大小和缩放问题的前端解决方案中最受欢迎的库之一。 有两个版本； Picturefill v1 使用span模仿<picture>元素，而 Picturefill v2 在已经提供它的浏览器中使用<picture>元素并为旧版浏览器提供 polyfill（例如，对于 IE >= IE9）。 它有一些限制和变通方法，尤其是对于 Android 2.3 - 顺便说一下，这是img srcset属性发挥作用的一个例子。 下面是使用 Picturefill v2 的示例标记：

 <picture> <source media="(min-width: 768px)"> <source media="(max-width: 767px)"> <img alt="My Kitty Cat"> </picture>

为了提高数据计划有限的用户的性能，图片填充可以与延迟加载相结合。 但是，该库可以提供更广泛的浏览器支持并解决奇怪的情况，而不是依赖补丁。

Imager.js

Imager.js 是 BBC 新闻团队创建的一个库，用于使用与 Picturefill 使用的方法不同的方法来完成响应式图像。 虽然 Picturefill 尝试将<picture>元素带到不受支持的浏览器中，但 Imager.js 专注于仅下载适当的图像，同时还要注意网络速度。 它还结合了延迟加载，而不依赖于第三方库。 它通过使用占位符元素并用<img>元素替换它们来工作。 下面的示例代码展示了这种行为：

 <div> <div class="image-load" data-src="http://example.com/images/kitty_{width}.jpg" data-alt="My Kitty Cat"></div> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

呈现的 HTML 将如下所示：

 <div> <img src="http://example.com/images/kitty_480.jpg" data-src="http://example.com/images/kitty_{width}.jpg" alt="My Kitty Cat" class="image-replace"> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

浏览器支持比 Picturefill 的支持要好得多，但代价是它是一种比前瞻性解决方案更实用的解决方案。

源改组

Source Shuffle 从与其他前端库略有不同的角度处理响应式图像问题。 它类似于“移动优先”思想流派的东西，默认情况下它提供最小的分辨率。 在检测到设备具有更大的屏幕时，它会将图像源换成更大的图像。 感觉更像是一个 hack，而不是一个完整的库。 这对于主要是移动网站来说是一个很好的解决方案，但意味着桌面和/或平板电脑的双重资源下载是不可避免的。

其他一些值得注意的 JavaScript 库是：

  • HiSRC - 用于响应式图像的 jQuery 插件。 对 jQuery 的依赖可能是个问题。
  • Mobify.js - 一个更通用的响应式内容库，包括图像、样式表甚至 JavaScript。 它在资源加载之前“捕获” DOM。 Mobify 是一个功能强大的综合库，但如果目标只是响应式图像，则可能有点矫枉过正。

概括

归根结底，由开发人员决定哪种响应式网页设计图像方法适合用户群。 这意味着数据收集和测试将更好地了解采取的方法。

最后，在决定适当的响应式图像解决方案之前，考虑以下问题列表可能会有所帮助。

  • 旧版浏览器有问题吗？ 如果没有，请考虑使用更现代的方法（例如：Picturefill、 srcset属性）
  • 响应时间是否关键？ 如果没有，请寻求第三方或后端解决方案。
  • 解决方案应该是内部的吗？ 第三方解决方案显然会被排除在外。
  • 网站上是否已经有很多图像正在尝试转换为响应式图像？ 是否存在关于验证或语义标签（或者更确切地说是非语义标签）的问题？ 这将需要一个后端解决方案来将图像请求路由到诸如自适应图像之类的东西。
  • 艺术指导是否有问题（特别是对于包含大量信息的大图像）？ 对于这种情况，像 Picturefill 这样的库将是更好的解决方案。 此外，任何后端解决方案都可以正常工作。
  • 是否担心缺少 JavaScript？ 任何前端解决方案都将是不可能的，这留下了依赖 UA 嗅探的后端或第三方选项。
  • 移动响应时间是否优先于桌面响应时间？ 像 Source Shuffle 这样的库可能更合适。
  • 是否需要为网站的各个方面提供响应行为，而不仅仅是图像？ Mobify.js 可能会更好。
  • 完美世界实现了吗？ 使用纯 CSS display:none方法！