响应式设计争议：留住用户与失去用户

译前言：2015年响应式设计趋势的延续，也将带来更多的争议和思考，此文所引论据较为客观，点出了响应式概念的初衷和近年来跨屏设计的状况，并提供了解决思路和可参考的具体方法，原文下的评论也有诸多争议，有兴趣可以移步一览。
原文：http://www.smashingmagazine.com/2014/07/22/responsive-web-design-should-not-be-your-only-mobile-strategy/
作者：Maximiliano Firtman

你脸上挂着微笑心情愉悦地缩放着浏览器窗口时，认为网站达成了移动端友好体验的目标。在探讨之前我要提前推论：如果你只是把响应式网页设计定为终极目标并且是唯一的移动端方案，是在流失用户，也许还有金钱。幸运的是我们能够修正这些错误。

这篇文章的内容将涉及移动网页与响应式设计的关系，始于如何提供灵巧的响应式设计，及移动端的性能为何如此重要、响应式设计何以不能视为网站的目标，并止于技术本身的性能争议，以便辅助理解问题的真正所在。

2000年起，设计师和开发者就已对移动端存在的问题过分简化，而现在有些人则认为响应式网页设计是一切难题的银弹。我们需要正视的是，达到移动网页的轻快体验应盖过其他任何目标。向所有移动设备传送一个快速可用并全兼容的体验是一个挑战，在实施响应式技术时也是如此。而在一开始便关注性能将协助我们更易达成目标。

响应式网页设计非常优秀，但它不是银弹。如果把它当作移动端的唯一法宝，那么也许会有性能问题将对转化率造成阻碍。现约有11%的网站是响应式的并且这个数字每个月都在上升，讨论它的时机到了。

根据Guy Podjarny的调查，72%的响应式网站统一传送相同数量的字节，而不依据屏幕尺寸区分处理，甚至在使用速度较慢的移动网络连接也是如此。但并非所有的用户都会耐心等待网站的加载。

实际上只需对问题有基本理解，我们就可以让损失降到到最低。

移动网站由来已久

我并不是说不该让设计做到响应式，或者建议应该采用一个m.*的子域名。事实上，社交分享已无所不在，不区分设备让每一个文件指向同一个URL是明智的。但这并不意味着单一的URL应该总是传送同一文件，或者说是所有的设备应该加载同一个资源。

引用创造“响应式网页设计”术语的Ethan Marcotte的一句话：

最重要的是，响应式网页设计不是特意为移动网站提供的一个替代解决方案。
（译补Ethan Marcotte原文：“我认为响应式设计是设计哲学的一部分，也是前端开发策略的一部分。而作为后者，应依实际项目所需评估其可行性。”）

响应、移动、快速

移动端的性能保证与响应式设计可以同时实现，只要用上一些其他技术。响应式网页设计从不意味着去制造性能问题，这也是我们无法归罪于这项技术本身的原因，而许多人相信它能解决一切问题才是错误的根源。

让设计响应式化的重要性在于，我们需要处理从台式机到手机的大区间viewport尺寸。但是只考虑屏幕尺寸低估了移动设备，台式机与手机的分界线正在变得模糊，不同类型的设备也趋于提供多样化功能。显然我们已无法再只依赖于使用媒体查询这一功能。

有些评论者称之为“负责任的响应式网页设计”，虽然其他人把它叫做现代化的响应式网页设计。撇开两种叫法语义上的差别，我们确实需要理解并意识到问题所在。

不存在银弹也没有可以一劳永逸的方案，我们能做的是使用组合技巧提升现有的响应式方案并且力求性能的最优化：

提供相同URL及内容，但针对不同设备结构不同；
在立项规划阶段便需遵循移动优先原则；
使用display: none时进行真机测试验证资源加载，而非依赖于桌面浏览器模拟；
在浏览器提供更好的解决方案（如srcset）之前，使用JavaScript分发响应式图片；
移动端初始viewport的文件内嵌，或者优先加载首屏内容。
提供更智能的响应式方案如：按需加载、分组响应式、服务器端的自适应处理。

按需加载

CSS媒体查询无法让设备区分加载和解析，这意味着移动端的手机会下载和解析为更大屏幕提供的CSS。再者，蜂窝网络下CSS的分区渲染浪费的毫秒十分宝贵，有必要避免全依赖于此。

正如我们知道的，iPhone不会动态转换为iPad的尺寸，采用JavaScript 的matchMedia查询方法替代CSS媒体查询，则能够保证不同设备显示内容的统一性并且只加载它们各自所需要的CSS。

使用特征检测工具可以做到更好，如Modernizr可以构建更智能的UI和功能定义，而不是只依赖于屏幕尺寸。

分组响应式

基于单HTML页面为所有屏幕进行响应式设计时，为台式电脑和智能手机传送同样的HTML结构是糟糕的，原因再次回归到移动端的性能问题。

即使服务器端存储同一个文件，基于设备分组也可以实现对终端的按需发送。举例来说，为6英寸及更大尺寸的屏幕提供大的浮动式菜单，而为小于6英寸的屏幕提供一个小的汉堡包菜单。响应式技术可以基于分组实现不同情境的适配，如横竖屏模式的转换、不同型号的iPhone（宽为320像素）、各式5英寸的安卓设备（宽为360像素）及平板（宽为400像素及以上）。

服务器端层面

更智能的响应式解决方案的最后一个选项是服务器，对移动网页来说服务器端进行特征检测及定义并不新奇，市面上早有诸如WURFL和Device Atlas之类的工具库。

把响应式设计与服务器端组件联合同样也有前例，已被知晓的有响应式设计+服务器端组件(RESS)，或被称为自适应设计，保障每个终端代码简约性的同时，提高了响应式的速度与可用性体验。

不幸的是，在过去几年里这些技术没有在社区里获得太多的推动，只需看看有多少为开发者提供的博客或杂志将“RESS” 与“自适应” 和“响应式”相提并论便可一知。其一原因在于：我们是前端工程师，任何涉及后端的内容都是个令人头疼的难题。

一部分情况是前端设计人员可以控制的是服务器上的脚本；另一部分情况是有远程开发团队管理，设计师并不想在每次需要调整UI时都与他们打交道，这种情形下的心情我能够理解。

这也是为何在大项目里头应该考虑新的架构层：一种不需要动用后端，只通过前端工程师就能够对服务器端架构进行操作的方式。Node.js是一种卓越的作为前后端之间流通架构的平台，这个架构方式下，前端工程师可以基于内部的流通性进行调整而不需要涉及后端架构，从而实现为所有设备提供轻快的响应式和可用性体验。

响应式设计、性能和技术数据

对这篇文章你可能抱有一些置疑，接下来我们将对技术细节进行重新审视以减轻你的疑虑。

响应式设计通常会为所有设备传送相同的HTML文件，再采取媒体查询的方式加载不同的CSS和image文件，这一点有的人可能不太同意，但很多情况下都是如此实施的。

你也可能会认为如今移动网络速度的提升已足够实现良好的体验，毕竟4G非常快，设备也运行得更为流畅，那么在下结论之前我们来看一些数据吧。

蜂窝连接

4G网络还没有广泛覆盖，而即便是全世界范围内都能够使用4G网络，可能也会有一些超出预期的状况。只论US地区的4G用户数量约为22%，而其中的40%并非随时处于4G连接状态，除外地区则只有不到3%的手机使用4G连接。

移动网络速度受限于带宽，3G可以达到5Mbps，4G可以达到50Mbps。但移动网页体验通常面临的最重要的现状是：消耗于接收大文件（如YouTube视频）的带宽越多，大批量小文件的并行下载越不顺畅，并会伴有确定性的高发延迟。延迟是设备对每个数据包的首字节发起请求接收的往返时间。

蜂窝网络比其他连接方式延迟更多。虽然US的家庭DSL连接延迟为20~45ms，3G网络
却可能达到150~450ms，4G网络则为100~180ms。这也就意味着蜂窝连接的延迟比家庭网络要高出5~10倍。

尚有其他延迟方面的问题如无线电广播引起的变动：当手机进入休眠状态后打开收音机频率需要获取更多数据而导致滞时；设备平均可用内存越低也就意味着电池和CPU消耗越多。

蜂窝网络下的响应式设计

一个实例：Keynote是一家提供性能解决方案的公司，发布了2014超级碗顶尖广告的网页性能数据。这份报告里陈述：在wired或Wi-Fi连接下加载时间为1~10s区间，而在蜂窝连接下加载时间为5~60s的区间。实在难以想象超级碗上投放的广告是需要加载整整一分钟的网页。

响应式设计争议：留住用户与失去用户 — 2014超级碗顶级广告网页性能（查看大图）

同样的报告显示有43%的网站提供了移动专属版本，平均体积为862KB；50%实行响应式方案的平均体积在3211KB（超出将近四倍）；另外7%对移动设备提供的则是桌面版，这基本可以认为响应式网站比移动专属网站的体积更大。

当然，响应式网站可以有不一样的表现，但不幸的是，这份报告之外的响应式网站的表现也基本与超级碗广告相似。

基于云技术的浏览器

如果对移动端网页的性能仍存有疑虑，想想看基于云技术开发浏览器的厂商正为用户做的——包括Opera Mini、基于亚洲的UC浏览器（根据statcounter的统计，其市场占有率为11%），Amazon Fire的Silk浏览器和目前的 Google Chrome（通过选项设置）。

这些厂商在云端压缩所有的网站和资源，随后浏览器下载优化过的版本到移动端，而他们如此做的理由是认识到了性能服务于用户的意义。

移动端的网页被低估

网络社区通常会低估移动浏览器的重要性，我曾听到人们说现今的移动端网页只有iOS的Safari和Android的Chrome浏览器，对响应式设计，我们只需顾及320像素宽的viewport。但实际情况比这复杂得多。

如今有不下于10个浏览器的市场占有率超过1%，就算只需考虑iOS和Android的默认浏览器也并不容易。大致情形来说，在移动端浏览网页的用户中，iOS占50%，Android占38%，Windows Phone占3%，Opera Mini占5%（包括各类操作系统），剩余4%则为其他平台。

而如今的Android平台有64%的用户使用自带浏览器，这是一个与Google Chrome存在差异并且本身具有多个版本的浏览器。此外，最新的三星Galaxy中有一些设备所提供的Android浏览器是自定义引擎的版本。

根据viewport的尺寸，仅Android系统的智能手机，如今我们需要处理的像素宽度就包括320、360、400、540。那么我要建议的是，不要低估移动端的网页，并去了解它那些独一无二的特征。

1秒内完成首屏内容的加载

在移动设备中，我们把在1秒或是更少时间完成首屏内容（即不需滚动直接显示的内容）渲染的网站视作是快的。我知道1秒钟看起来十分快速——特别是考虑到至少有一半的情形是要在蜂窝网络下来达到的——但这已被证实是可能的。1秒响应可保证用户聚焦于内容，从而提升转化率及减少流失。

达到1秒响应时间，首屏内容需要在传输控制协议（TCP）的单次往返时间中完成——不能忽略的是普遍的3G网络几乎存在半秒的延迟。由于TCP被称为“慢启动”，首次响应不能超过14KB以避免二次打包。这意味着首屏内容的HTML和CSS至少必须符合14KB的单次HTTP响应。如果我们做到这个，那么也就达成了1秒加载时间的感官体验。

这条规则并没有被明确列出，且要视实际需要而有所调整。然而，由于移动屏幕的首屏内容显示通常无法达到与桌面屏幕一致的效果，使用响应式设计达到1秒的目标是非常艰难的，但实现的难度是可以通过多种技术的结合降低的。

一个HTML服务所有平台

一个典型的响应式设计是对所有设备发送单一的HTML文件：电视、桌面、平板、智能手机及其后的所有手机。这听起来很赞，但我们生活的世界有蜂窝网络和其他的各种问题。移动设备下你的响应式HTML可能会正确渲染，但它不够快，本来它应该是可以更快的，这也在影响你的转化率。

一旦有display: none出现在CSS中，你的站点就会开始变慢。一个从零开始为语义设计的站点，响应式的超载会让一切工作几近化为无用；一个站点的HTML里包含的40个外部JavaScript里的绝大多数jQuery插件和功能库都是为大屏服务的，响应式超载会让一切崩溃。使用同一HTML，就等同于在所有设备加载同样的外部资源。

这并不是说不能做单一的响应式设计，只是站点不会自行进行优化。如果你已经留心到了性能，那么你的响应式方案将会不同寻常。

我们来审视一番星巴克的站点，它的主页是响应式的并且在我们测算的三种viewport下（屏幕截图见下）看起来都很赞。但查看结构之后，我们发现所有版本都加载33个外部JavaScript文件和6个CSS文件。使用3G延迟网络的移动设备需要加载到39个外部文件只为显示这样一个页面么？

不同情境下的星巴克站点 (查看大图）

你可能会认为，“啊，干嘛怪技术应该怪实现”，这是对的。这篇文章并不是和响应式网页设计作对，它驳斥的是瞄准了响应式却实现得很糟糕，它驳斥的是以响应式为目标而不顾性能，正如星巴克一般。

若你的响应式站点存在性能问题，那根源可能是出于你所定的目标。若为响应式设计实施规划，也必须为性能实施规划。

资源加载

媒体查询有多种应用方式，通常采用如下中的一种：

单独CSS文件添加多样的@media声明；
通过link标签的media属性为页面引入多样的CSS文件。

第一种情形中，只会产生一个CSS文件，故所有设备都会加载全平台的CSS，数百个无用的选择器都会被浏览器转译和解析。

你可能会认为多样的外部文件是更好的方式，因为浏览器会基于断点加载不同的资源，这是我们在各种博客、杂志、书和培训课程中得到的信息。

<link rel="stylesheet" href="desktop.css"
media="(min-width: 801px)">
<link rel="stylesheet" href="tablet.css"
media="(min-width: 401px) and (max-width: 800px)">
<link rel="stylesheet" href="mobile.css"
media="(max-width: 400px)">

好吧，你完全错了。所有的浏览器会不分环境地把所有的外部CSS一并加载。下面的屏幕截图显示iPhone下载了所有头部引用的CSS文件，包括与它无关的。