响应式设计还不够，我们需要响应式性能

最近，我遇到了很多响应式网站，它们存在很多性能问题。 在他们中的大多数人身上，问题是如此明显，以至于除了最新一代的智能手机之外，它们几乎毫无用处。 考虑到响应性作为一个概念旨在覆盖更广泛的受众这一事实，这似乎适得其反。

这个问题的最大贡献者是仍然流行的桌面优先设计范式。 从移动优先的角度思考似乎可以解决问题，但仅凭这一点并不能保证令人满意的性能。 我们似乎都过于依赖或多或少的优雅退化。 我们依靠 shims 和 polyfill 来启用缺失的功能。 我们依靠库来实现快速开发，并在浏览器兼容性成为问题时提供支持。

“为什么要担心？” 你可能会问。 “我们的大多数访客都拥有运行最新操作系统版本的高性能智能手机。 他们可以处理我们的网站。 分析告诉我们。”

对于稻草人的论点，我很抱歉，但我认为值得大声说，可以使用您网站的人将是您的大多数用户。 如果您在分析中没有看到 Android 2.3，这是否意味着没有使用这些设备的用户？ 或者这是否意味着您的网站无法为这些用户提供任何东西？ 考虑到那一代的许多设备仍在货架上，即使在今天也被全新购买。 您不应该将其完全视为过去的技术而忽略。

因此，我想谈谈Web开发的理想案例和实际目标。 以及让我们更接近这些目标的实践和范式。

砖头设计范式

年度手机销量的很大一部分仍由功能手机占据。 更大一部分的人口不是每年都购买手机，但他们仍然拥有一些支持网络的设备。 再加上仍在使用的上一代智能手机，再加上 Kindle 和其他半功能网络设备（WAP 设备、电视、烤面包机、T 恤和积木）。 将它们全部加起来，您可能会达到惊人的总和。

考虑此受众的用例。 他们不会在设备上阅读长篇文章、浏览和研究。 但他们可能会经历尝试在数字键盘上输入 URL 并使用方向键导航页面以获取电话号码或即时仔细检查地址的恐惧。

那么对于我们来说，实现一个仅向低于特定功能和性能阈值的设备提供该信息的次移动优先布局有多难？

优雅的改进

将优雅降级作为最低限度的最佳实践，我们创建了一个包罗万象的原则，（在某种程度上）阻碍了超越它的思考。 一旦优雅的降级到位，我们可以肯定地说我们的工作已经完成，并且做得很好。 越来越多的时候，我们甚至不必考虑它，因为它已经被正在使用的各种框架和库所涵盖。 最后，在某些情况下，polyfills 和 shims 完全消除了功能退化的需要。

随着这个功能变得越来越容易获得，考虑它（更不用说超越它）的需求变得越来越遥远。

从这篇文章的角度来看，它可以这样分解：

不优雅的降级：如果一个特性不是很容易获得的，那么实现就会失败，以至于它变得不可用或以极其不切实际的方式可用。

优雅降级：如果一个特性不是现成的，它会以某种方式失败，但仍然可以实现可接受的可用性。

不优雅的改进：如果该功能不是现成的可用，它由 polyfill 或 shim 模拟。

到了，问题解决了。

好吧，除非您考虑那些相同的低端设备的性能。

由于缺乏弟弟妹妹的处理能力和数据能力，他们被要求承担更大的负载。 将 polyfills 作为解决方案会产生一种错觉，即所有现代功能现在都可以在所有设备上使用，并且可以毫无顾虑地使用。

所以你实现了modernizr和polyfill一切以防万一。 最不称职的设备最终会加载最多的数据，并执行最多的处理。 从而确保“最佳”最终用户体验。

优雅改进的想法将扭转这一概念，从最低的功能要求开始并加载升级，直到基于设备功能的性能-可用性平衡达到最佳状态。 因此，数据流量和处理要求将转移到最适合处理它们的设备上。

当然，目前这个概念非常复杂：大多数框架和库都不支持它，几乎没有讨论过，对此类实践的引用很少，相距甚远，并且仅限于微功能。 但在某些时候，所有概念和功能都是如此。

它可以，但它必须吗？

Web 开发的另一个最佳实践是在激活之前检查设备上的功能是否可用。

但是，考虑到您可以在旧的 Android 手机上安装最新版本的 Google Chrome，它会声称它可以运行 CSS 动画、WebGL、背景视差效果和许多其他功能。 但它真的，真的，不能。 以至于浏览器会崩溃，整个设备将变得无响应，以至于必须重新启动才能重新获得控制权。

这个问题最近开始在很大程度上影响 Android 应用程序（从用户的角度来看）。 从这个意义上说，最明显的退化之一影响了 Google Talk/Hangouts 应用程序升级，由于旧设备上的性能问题，他们的服务从可用的最轻量级的聊天应用程序变成了几乎无法使用的应用程序。 （再次强调这一点：这里的“旧”意味着您仍然可以在几乎任何商店购买现成的、全新的）。 同样的问题影响了 YouTube 应用程序和 Twitter 应用程序（根据我的经验），显然还有许多其他应用程序。

因此，在计划阶段的某个时间点花点时间评估高性能核心功能相对于尖端化妆的价值。 或者至少让您的上一代应用/服务/内容以某种形式提供给旧用户。 说到这个……

让用户选择退出前沿

您是否曾发现自己试图通过旧设备或连接不佳的设备使用 Gmail？ “加载基本 HTML”链接肯定会派上用场。

为什么您的尖端、响应式、动画、面向触摸的在线店面没有该功能？

想一想：您要求它具有响应性，以便您可以接触到更多潜在客户。 你让它最前沿，留下最好的第一印象。 结果，更少的潜在客户甚至可以获取有关您和您的服务的基本信息。 如果优雅的改进对您来说成本太高，那么如果“WOW”版本对他们的设备来说太多了，您为什么不至少为您的访问者提供访问纯文本版本内容的选项。

你真的需要整个图书馆吗？

最后，我希望看到的最后一个超出标准的最佳实践是“使用它或失去它”。 跟踪实际使用的库和模块并仅包含它们有时很乏味，但将整个工具集保存在每个页面上只是草率。

最近，我开始跟踪我在包含库后实际使用了多少功能。 而我最常使用的工具是 jQuery。 我经常发现我只使用了一个或两个功能（例如 $.extend 或 $.ready），或者更糟糕的是，我只使用它来按类或 ID 获取元素。 有时我会这样，有时我会返回代码以删除或解耦依赖项。

如果您可以根据结果自动分析最终使用了哪些库以及使用了多少库并减轻了体重，那不是很好吗？

许多库和应用程序提供了在开始使用之前自定义加载的选项。 但我一直有这种感觉，在我们的库中标准化自动化的“使用它或失去它”构建架构应该不会太远。

我对“包罗万象”的方法过敏。 但是将它与这样的功能结合使用可能会将方法转变为类似于原型板的方法：一种过于灵活的开发工具，不仅在语法上，而且在实际功能本身上都被缩小了。

需要的是库的仅开发版本，通过对依赖功能的单元测试，可以跟踪使用的功能并输出最小的依赖或至少使用规模（例如询问我是否包含 8% 的 jQuery其功能或 80%）。 然后可以使用依赖项输出来挑选、聚合和最小化生产的输出。

但我能做些什么呢？

首先，解决问题。 想一想，与您的同行讨论，并尝试在现实世界的场景中发现问题。

试试看。 把你藏在某个抽屉里的上一代手机挖出来。 尝试在您自己的网站上使用它，并检查内容是否甚至可以远程使用。 去国外拜访一些落后时代的亲戚，并尝试成为他们的技术布道者。 看看他们在技术采用方面的滞后是否实际上是由可访问性问题促成的。

如果您是委托网站的买家，请确保在此问题上要求（至少）低级别的支持。 请记住：目标不是为低级设备创建所有功能的完整端口。 所要求的只是这些用户获取您的联系信息，而不是他们的设备崩溃。

为此留出实际资源：该问题的最简单解决方案不应超过一两天和一些前瞻性思考。 请记住首先制作网站的最基本原因（更不用说制作响应式网站了）。

如果您是开发库、框架、捆绑软件或任何其他可嵌入软件的软件包开发人员：您就是能够在这里发挥最大作用的人。 如果您可以促进或将这些概念整合到您的平台中，您将影响 Web 开发的整个领域。 如果您确实将它纳入您的包装设计，请告诉我，我会为您传福音。

最后，**如果您是开发人员或设计师**，不要只停留在最佳实践。 总是试着在那个地平线上看一点点。 为了您的客户和用户的利益，您需要努力推动这些尚未有人要求的概念，这些概念不受支持且未记录在案。

最终，如果您想听有人持续数小时并发现自己在萨格勒布附近，请告诉我。 我们可以去喝杯咖啡。