响应式网站设计留住用户与失去用户

你脸上挂着微笑心情愉悦地缩放着浏览器窗口时，以为网站达到了移动端友爱体会的方针。在讨论之前我要提早推论：假如你仅仅把呼应式页面计划定为终极方针而且是仅有的移动端计划，是在丢失用户，或许还有金钱。走运的是咱们可以批改这些过错。

这篇文章的内容将触及移动页面与呼应式计划的关系，始于怎么供给灵活的呼应式计划，及移动端的功用为何如此主要、呼应式计划何故不能视为网站的方针，并止于技能自身的功用争议，以便辅佐了解疑问的真正地点。

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是一种杰出的作为前后端之间流转架构的渠道，这个架构方法下，前端工程师可以根据内部的流转性进行调整而不需求触及后端架构，然后完成为一切设备供给轻捷的呼应式和可用性体会。