共计 2399 个字符，预计需要花费 6 分钟才能阅读完成。
在这篇文章中，我们会谈到移动互联网和响应式设计的关系，首先将介绍如何巧妙的运用响应式设计，为什么性能对移动端非常重要，为什么响应式设计不能作为你网站的目标，最后技术的性能问题帮助我们更好的理解这问题。,
在这篇文章中，我们会谈到移动互联网和响应式设计的关系，首先将介绍如何巧妙的运用响应式设计，为什么性能对移动端非常重要，为什么响应式设计不能作为你网站的目标，最后技术的性能问题帮助我们更好的理解这问题。
自 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 是一个极好的备选平台，是介于当前企业后端基础和前端之间的服务器端层。
在这个新的端层里，前端的工程师可以根据有现实的决定权，这会使得在不触及后端架构的情况下，让所有设备上的体验更为快速、响应、可用。
丸趣 TV 网 – 提供最优质的资源集合！
