网站优化

在这篇文章中，咱们会谈到移动互联网和呼应式规划的联系，首先将介绍怎么奇妙的运用呼应式规划，为何功用对移动端十分主要，为何呼应式规划不能作为你网站的方针，最终技能的功用疑问协助咱们非常好的了解这疑问。

自2000年开端，规划者和开发者就把移动设备的疑问过于简略化，以至于如今依然有人以为呼应式页面规划能处理一切疑问。

咱们有必要明白，凌驾于任何方针，移动网络领会有必要和闪电一样快。敏捷、有用、兼容的领会对一切移动设备都是应战。当你运用呼应式规划时，这些应战都存在。从一开端就注重功用会让进程简略些。

呼应式规划是很棒，但不是万能钥匙。假如你在移动设备上一味坚持，在变换率后就也许隐藏着功用疑问。大约有11%的网站是呼应式，这个数字每月都在增加，所以如今是议论这个疑问的机遇了。

据Guy Podjarny研讨，72%的呼应式网站不分屏幕巨细都供给一样的字节，尽管这会下降移动网络连接。不是一切用户都有耐性等着网站加载。

对呼应式规划存在的疑问有了根本认识，咱们就能减低它带来的丢失。

移动网站来自过去

我不是说你不应当选用呼应式规划或许去用m.*的子域名。事实上，如今社会分享无处不在，不分设备，分配给给文档一个URL，这是聪明的做法。但这并不意味着一个单独URL应当供给一样的文档或每一个设备都应当下载一样的资本。

征引Ethan Marcotte的话，他发明了“呼应式页面规划”这个术语。

最主要的是，呼应式页面规划的初衷不是要替代移动页面。——Ethan Marcotte

交互、移动、疾速

假如咱们能运用一些别的的技能，就能够完成取得呼应式规划优点的一起，不影响移动设备的功用。呼应式规划历来不是意味着要处理“功用”，这也是为何咱们不能因此责备它的因素。可是，信任它能处理你一切疑问，这大错特错。

规划呼应式很主要，因为咱们需求处理跨桌面和移动端视窗巨细规模的疑问。可是只考虑屏幕巨细就轻视了移动设备。桌面和移动端的边界正在变得含糊，依据不一样的设备对咱们而言依然有多种也许性。可是咱们还不能经过媒体查询来决议呼应式规划的功用。一些评论家称之为“牢靠的呼应式页面规划”，可是另一些人则以为它是伴随现代视觉的呼应式页面规划。在没有了解其根本语义的状况下，咱们需求搞清楚这个疑问。

尽管没有可运用于各类文档的万全之策，可是能够运用一些窍门来改进现有呼应式的处理办法，并且力求功用最大化。

完成每一个文档对一切的设备都运用一样的URL和一样的内容，结构不必要一样。

当从零开端，遵从“移动先行”的办法。

在一个实在设备上测验当资本加载和显现会发作啥。不要依靠调整你的桌面浏览器。

运用优化东西丈量和提高功用。

经过JavaScript传输呼应图片，尽管咱们更期盼着浏览器供应商（例如srcset）能处理这个疑问

当你需求当时设备具有加载条件时，只加载JavaScript，这会在onload事情之后发作。

对移动设备，内联文档的初始视图，或许发送一屏显现内容。

运用下面一种或几种技能运用智能呼应式的处理方案：条件加载、按组呼应、效劳器端层（如习惯性办法）。

条件加载

不要总是在CSS中依靠media queries，因为浏览器将会为一切设备加载和解析一切挑选器和款式 （后边详细评论）。这就意味着手机为了一个大屏要下载和解析CSS。因为CSS块的呈现，你要糟蹋一些时刻等候联接成功。

在设备上用JavaScript的matchMedia查询来替代CSS media queries，你知道这些内容是不会改动的。例如，咱们都知道iPhone不能动态的变换成iPad的标准，所以咱们只在正在需求CSS时才用。

能够用特征检查，例如 Modernizr，对UI和功用性做出更明智的决议而不是只是依据屏幕尺度。

按组呼应

在处理简略文档、为台式电脑和智能手机供给一样的HTML时，尽管为咱们能够让一切屏幕依靠一个单一的HTML根底和呼应式规划，但这并不总是最佳的处理方案。为何呢？一样是因为移动设备的功用。

即便咱们在效劳器端贮存一样的文档，可是依据设备组别的不一样给用户不一样的文档。举个比如，为一个6英寸乃至更大的屏幕供给大的浮动菜单，为一个小屏幕供给汉堡菜单。在每个组群里，运用呼应时技能以习惯不一样的场景，例如肖像形式和景色形式的变换，切换iPhone（320像素宽）、5英寸Android设备（360英寸）和平板（400像素）。

效劳器端层

智能呼应战略的最终一个挑选是效劳器。

效劳器端功用检查和决议计划不是移动网络的新鲜玩意。相似 WURFL 和Device Atlas的库在商场上有很多年，呼应式规划和效劳器组件的混合也尽人皆知。有时被称为是呼应式规划和效劳器端组件（RESS）,有时又名自习惯规划，这提高了呼应式规划的速度和可用性，一起每一个效劳器端都保持一个代码库。

很惋惜的是。这些技能这几年并没有啥打破性的展开。只能在博客和杂志里看到一些开发者对“RESS”、“呼应式”、“自习惯”做对比。因素即是：咱们是前端专业人士。任何涉及到效劳器的事情看起来都是不太开心的疑问。在一些状况下，前端规划师能掌握好效劳器的脚本，另一些状况是，效劳器由长途开发团队管理，规划师不想每做一次小的UI改动就要和长途团队交流处理。我能领会这种感受。

这即是在大型项目中要花时刻考虑新架构层的因素，这样前端工程师对效劳器做决议时不会影响到后端架构。Node.js是一个极好的备选渠道，是介于当时公司后端根底和前端之间的效劳器端层。

在这个新的端层里，前端的工程师能够依据有实际的决议权，这会使得在不触及后端架构的状况下，让一切设备上的领会更为疾速、呼应、可用。