建站技术

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