一种尺寸适合某些尺寸（响应式Web设计图像解决方案指南） _响应式设计

本文概述

关于响应式网络图像的追求
后端响应式图像缩放解决方案
前端解决方案
摘要

随着移动和平板设备越来越接近最终世界的统治地位, 网页设计和技术正在努力适应不断增长的屏幕尺寸。但是, 设计工具来应对这种现象的挑战带来了一系列全新的问题, 其中出现的最新流行词是” 响应式网络” 。这是使网络在大多数(如果不是全部)设备上运行而不降低用户体验的挑战。代替设计适合台式机或笔记本电脑的内容, 信息必须可用于手机, 平板电脑或连接到网络的任何表面。但是, 已证明这种响应式Web设计的发展非常困难, 有时甚至是痛苦的。
尽管容纳文本信息几乎是微不足道的, 但棘手的部分是当我们考虑诸如响应式图像, 信息图表, 视频等内容时, 这些内容一度只考虑了台式机。这不仅提出了正确显示内容的问题, 而且提出了如何使用不同的设备消费内容本身。智能手机上的用户不同于台式机上的用户。还必须考虑数据计划和处理速度之类的问题。 Google已经开始在其搜索结果中突出显示适合移动设备访问的网站, 并且有人猜测这将大大提高此类网站的网页排名。早期的解决方案通过部署仅移动子域(和重定向)来解决此问题, 但这增加了复杂性并很快过时。 (并非每个站点都有能力负担这条路线。)
关于响应式网络图像的追求

文章图片
在这一点上, 开发人员和设计人员必须确保优化其网站负载, 以满足移动网站上的用户的需求。现在, 超过20％的网络流量是移动用户, 并且这一数字仍在上升。对于图像占页面内容数据最大份额的图像, 减轻此负担成为当务之急。为了简化响应式设计图像的大小调整, 已经进行了多种尝试, 包括服务器端和前端解决方案。要讨论这些响应式图像解决方案, 我们首先需要了解当前图像链接的缺点。
< img> 标记只有source属性直接链接到图像本身。没有任何附加组件, 它无法确定所需的正确图像类型。
我们不仅可以将HTML中包含的所有图片大小都包含在内, 还不能使用CSS规则显示：除了正确的图片外, 没有其他所有图片？在完美的逻辑世界中, 这是最合乎逻辑的解决方案。这样, 浏览器可以忽略所有未显示的图像, 并且从理论上讲也不会下载它们。但是, 浏览器的优化超出了通用逻辑。为了使页面足够快地呈现, 浏览器会在完全加载必要的样式表和JavaScript文件之前预先提取链接的内容。最后, 我们没有忽略打算用于台式机的大图像, 而是下载了所有图像并导致更大的页面加载。纯CSS技术仅适用于用作背景图像的图像, 因为可以在样式表中设置这些图像(使用媒体查询)。
那么, 要做什么网站？
后端响应式图像缩放解决方案

文章图片
除非仅限移动网站/子域, 否则我们只能嗅探用户代理(UA)并使用它来将尺寸正确的图像提供回用户。但是, 任何开发人员都可以证明该解决方案的可靠性。新的UA字符串一直在弹出, 这使得维护和更新综合列表变得很费力。当然, 首先, 这甚至没有考虑到容易欺骗的UA字符串的不可靠性。
自适应图像
但是, 某些服务器端解决方案值得考虑。对于那些喜欢后端响应式图像修复的人来说, 自适应图像是一个很好的解决方案。它不需要任何特殊的标记, 而是使用一个小的JavaScript文件, 并在其后端文件中完成大部分繁重的工作。它使用PHP和nginx配置的服务器。它还不依赖任何UA嗅探, 而是检查屏幕宽度。自适应图像非常适合缩小图像, 但是在大图像需要艺术指导时也很方便, 例如通过裁剪和旋转等技术缩小图像, 而不仅仅是缩放。
Sencha Touch
Sencha Touch是另一种后端响应设计图像解决方案, 尽管最好将其称为第三方解决方案。 Sencha Touch将通过嗅探UA相应地调整图像大小。以下是该服务如何工作的基本示例：

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

如果我们不希望Sencha自动调整图像大小, 还有一个选项可以指定图像大小。
最终, 服务器端(和第三方)解决方案需要资源来处理请求, 然后再发送正确的映像。这将花费宝贵的时间, 进而减慢请求-响应行程。更好的解决方案可能是设备本身确定直接请求哪些资源, 然后服务器做出相应响应。
前端解决方案

文章图片
最近, 在浏览器方面已经有了很大的改进, 可以处理响应图像。
W3C在HTML5规范中引入并批准了< picture> 元素。目前尚不能在所有浏览器上广泛使用它, 但不久后它就可以本地使用。在此之前, 我们依靠JavaScript polyfills作为元素。对于缺少该元素的旧版浏览器, Polyfills也是一个不错的解决方案。
srcset属性也适用于< img> 元素的几种基于webKit的浏览器。无需任何JavaScript即可使用, 如果要忽略非webKit浏览器, 这是一个很好的解决方案。对于其他解决方案不足的奇怪情况, 这是一个有用的权宜之计, 但不应视为全面解决方案。
图片填充
Picturefill是< picture> 元素的polyfill库。它是用于响应图像大小和缩放问题的前端解决方案中最受欢迎的库之一。有两个版本。 Picturefill v1使用跨度模仿< picture> 元素, 而Picturefill v2在已经提供它的浏览器中使用< picture> 元素, 并为旧版浏览器提供polyfill(例如, 对于IE> = IE9)。它有一些局限性和解决方法, 尤其是在Android 2.3上-顺便说一句, 这是img srcset属性得到拯救的一个示例。以下是使用Picturefill v2的示例标记：

< picture> < source srcset="/images/kitty_large.jpg" media="(min-width: 768px)"> < source srcset="/images/kitty_medium.jpg" media="(max-width: 767px)"> < img srcset="/images/kitty_small.jpg" alt="My Kitty Cat"> < /picture>

为了提高数据计划有限的用户的性能, 可以将Picturefill与延迟加载结合使用。但是, 该库可以提供更广泛的浏览器支持并解决奇怪的情况, 而不是依赖补丁程序。
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 Shuffling从与前端库其余部分稍有不同的角度解决了响应式图像问题。它类似于” 移动优先” 思想中的某些东西, 因此默认情况下它提供的分辨率可能最小。在检测到设备具有更大的屏幕时, 它将图像源交换为更大的图像。感觉更像是一个hack, 而不是一个完整的库。对于主要是移动网站而言, 这是一个很好的解决方案, 但意味着台式机和/或平板电脑的双重资源下载是不可避免的。
其他一些著名的JavaScript库是：

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

摘要归根结底, 由开发人员决定哪种响应式网页设计图像方法适合用户群。这意味着数据收集和测试将更好地了解采用的方法。
【一种尺寸适合某些尺寸（响应式Web设计图像解决方案指南）】总结一下, 在确定适当的响应式图像解决方案之前, 下面的问题列表可能会有所帮助。

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