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

macro · 发表于 2017-1-1 20:07:06

前言：2015年响应式设计趋势的延续，也将带来更多的争议和思考，此文所引论据较为客观，点出了响应式概念的初衷和近年来跨屏设计的状况，并提供了解决思路和可参考的具体方法，原文下的评论也有诸多争议，有兴趣可以移步一览。

你脸上挂着微笑心情愉悦地缩放着浏览器窗口时，认为网站达成了移动端友好体验的目标。在探讨之前我要提前推论：如果你只是把响应式网页设计定为终极目标并且是唯一的移动端方案，是在流失用户，也许还有金钱。幸运的是我们能够修正这些错误。
这篇文章的内容将涉及移动网页与响应式设计的关系，始于如何提供灵巧的响应式设计，及移动端的性能为何如此重要、响应式设计何以不能视为网站的目标，并止于技术本身的性能争议，以便辅助理解问题的真正所在。
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是一种卓越的作为前后端之间流通架构的平台，这个架构方式下，前端工程师可以基于内部的流通性进行调整而不需要涉及后端架构，从而实现为所有设备提供轻快的响应式和可用性体验。
注：相关网站建设技巧阅读请移步到建站教程频道。

		自动登录	找回密码
密码			立即注册

[建站策划] 响应式设计引发的争议：留住用户与失去用户

相关帖子