本文概述
最近, 我遇到了很多响应网站, 但都存在很多性能问题。在大多数情况下, 这些问题是如此明显, 以至于除了最新一代的智能手机以外, 它们几乎对其他任何东西都毫无用处。考虑到响应性作为一个概念旨在吸引更广泛的受众这一事实, 这似乎适得其反。
导致此问题的最大因素是仍然流行的桌面优先设计范例。从移动优先的角度思考似乎可以解决该问题, 但是仅凭这一点并不能保证令人满意的性能。我们大家似乎都过于依赖或多或少的优雅降级。我们依靠垫片和填充材料来实现缺少的功能。当浏览器兼容性成为问题时, 我们依靠库来实现快速开发并获得支持。
手机上的杀手ers散, 伪装成响应式网站。
“为什么要担心？”你可能会问。 “我们的大多数访客都具有运行最新操作系统版本的高性能智能手机。他们可以处理我们的网站。分析告诉我们。”
我对稻草人的论点感到抱歉, 但我认为值得大声说出来, 可以使用你网站的人将是你的大多数用户。如果你在分析中没有看到Android 2.3, 是否意味着没有用户使用这些设备？还是这意味着你的网站无法为这些用户提供服务？考虑到这一代的许多设备仍在货架上, 甚至在今天仍是全新的。你不应该将其视为过去的技术而一视同仁。
因此, 我想谈谈Web开发的理想案例和实际目标。关于使我们更接近那些目标的实践和范式。
砖优先设计范式
功能手机仍然占据了年度手机销量的很大一部分。人口的更大比例不是每年购买电话, 而是拥有一些具有网络功能的设备。除了仍在使用的上一代智能手机之外, 还增加了kindle和其他支持Web的半设备(WAP设备, 电视, 烤面包机, T恤和砖头)。将它们全部加起来, 你可能会得到惊人的总和。
除非它在那里工作, 否则你不会在分析中看到它们。
鸣叫
考虑此受众的用例。他们不会在他们的设备上阅读长篇文章, 浏览和研究。但是他们可能会经历恐怖的尝试, 试图在数字键盘上输入URL, 然后使用方向键导航页面以获取电话号码或即时检查地址。
那么, 对于我们来说, 实施子移动优先布局将仅向功能和性能低于特定阈值的设备提供该信息有多么困难？
优雅的改进
我们将渐进式降级作为最低的最佳实践, 从而创建了一个万能的原则, 在一定程度上阻碍了超越该原则的思考。适当降级到位后, 我们可以肯定地说我们的工作已经完成, 并且做得很好。越来越多的我们甚至不必考虑它, 因为它已经被所使用的各种框架和库所涵盖。最后, 在某些情况下, polyfills和shimm完全消除了功能退化的需要。
随着该功能变得越来越容易获得, 对它的思考(更不用说超越它)的需求变得越来越远。
从本文的角度来看, 它可以像这样分解：
不当降级：如果某个功能不容易获得, 则实现会以无法使用或无法使用的方式失败。
正常降级：如果某个功能不可用, 则它会以仍然可以接受的可用性的方式发生故障。
不当的改进：如果无法立即使用该功能, 则可以通过polyfill或shim对其进行仿真。
在那里, 问题解决了。
好吧, 除非你考虑那些相同的低端设备的性能。
缺乏年轻同胞的处理能力和数据功能, 他们被要求承担更大的负担。将polyfills作为解决方案会产生一种幻觉, 即所有设备现在都可以使用所有现代功能, 并且无需担心即可使用。
因此, 你实施了modernizr并填充了所有内容, 以防万一。最不称职的设备最终将加载最大数量的数据, 并执行最大数量的处理。从而确保”最佳”最终用户体验。
湿润, 填充和填充？谢天谢地, 大多数智能手机都不支持Flash！
鸣叫
适度改进的想法将通过从最低的功能要求开始并加载升级, 直到基于设备功能使性能-可用性平衡达到最佳, 从而颠覆了这一概念。因此, 数据流量和处理要求将移至最适合处理它们的设备。
当然, 此概念目前过于复杂：大多数框架和库都未提供支持, 大多数情况下也没有讨论过, 并且此类实践的参考文献很少, 相距甚远且仅限于微功能。但是在某些时候, 所有概念和功能都是这样。
可以, 但是必须吗？
Web开发的另一个最佳实践是在激活某个功能之前先检查该功能是否在设备上可用。
但是, 请考虑到你可以在使用了多年的Android手机上安装最新版本的Google Chrome, 并且会声称它可以运行CSS动画, WebGL, 背景视差效果和许多其他功能。但这真的, 真的, 不能。如此之多以至于浏览器将崩溃, 并且整个设备将无法响应, 必须重新启动设备才能重新获得控制权。
从用户角度来看, 这个问题最近已开始对Android应用程序产生重大影响。从这个意义上说, 最明显的降级之一影响了Google Talk / Hangouts应用程序升级, 由于旧设备的性能问题, 该服务已将其服务从最轻便的聊天应用程序变为几乎不可用的应用程序。 (再次强调这一点：这里的”较旧”意味着你仍然可以在几乎所有商店中购买到全新的现成商品)。同样的问题影响了YouTube应用程序和Twitter应用程序(以我的经验), 显然还有很多其他问题。
因此, 请在计划阶段的某个时间花点时间来评估高性能核心功能的价值, 而不是尖端的化妆。或至少以某种形式将旧版应用程序/服务/内容留给旧用户使用。说到…
让用户退出出血边缘
你是否曾经尝试过通过旧设备或连接不良使用Gmail？该”加载基本HTML”链接肯定派上用场。
为什么你的尖端, 响应式, 动画化, 面向触摸的在线店面没有该功能？
考虑一下：你要求它具有响应能力, 以便可以吸引更多潜在客户。你将其置于最前沿, 以留下最佳的第一印象。因此, 潜在客户较少, 甚至可以获取有关你和你的服务的基本信息。如果优雅的改进对你来说太昂贵了, 那么, 如果” WOW”版本对他们的设备而言太大了, 你为什么不至少让访问者选择访问内容的纯文本版本呢？
你真的需要整个图书馆吗？
最后, 我想看到的超出标准的最后一个最佳实践是”使用它或失去它”。跟踪哪些库和模块实际在使用中, 仅包括它们有时是很麻烦的, 但是将整个工具集保留在每个页面上只是草率的。
21世纪的普遍谎言：仅剩几秒钟。
鸣叫
最近, 我开始跟踪包含库后实际使用的功能。我最常使用的工具是jQuery。我经常发现我只使用了一种或两种功能(例如$ .extend或$ .ready), 甚至更糟的是, 我只是用它来按类或ID获取元素。有时, 我会像这样保留它, 而其他时候, 我会遍历代码以删除或分离依赖关系。
如果你可以自动分析库的最终用途和数量, 并根据结果进行权衡, 那会不会很整齐？
许多库和应用程序都提供了在开始使用前自定义加载的选项。但是我一直觉得, 在我们的库中标准化自动化的”使用或丢失它”构建体系结构, 应该不会太遥远。
我对”包括一切”的方法过敏。但是, 将其与此类功能结合使用可能会使方法类似于原型开发板：一种过于灵活的开发工具, 不仅在语法上, 而且在实际功能本身上都将其最小化。
所需要的是该库的仅开发版本, 该版本将通过对依赖功能的单元测试来实现对所使用功能的跟踪, 并输出最小依赖关系或至少利用率等级(例如询问我是否已将jQuery包含8％)或功能的80％)。然后, 依赖项输出可用于挑选, 汇总和最小化用于生产的输出。
但是我该怎么办？
首先, 解决这个问题。考虑一下, 与你的同行讨论, 并尝试在现实世界中发现问题。
试试看。挖出你藏在抽屉中某个地方的上一代手机。尝试在你自己的网站上使用它, 然后检查内容是否可以远程使用。去拜访该国一些落后的亲戚, 并尝试成为他们的技术传播者。看看可访问性问题是否真正助长了他们在技术采用方面的滞后。
如果你是委托某网站的买家, 请确保(至少)要求对此问题提供低水平的支持。请记住：目标不是为低级设备创建所有功能的完整端口。所要问的是, 这些用户可以获得你的联系信息, 而不是设备崩溃。
为此, 请预留实际资源：最简单的解决方案应该不超过一两天, 并且需要一些前瞻性思考。首先要牢记制作网站的最基本原因(更不用说制作响应式网站了)。
如果你是使用库, 框架, 捆绑软件或任何其他嵌入式软件的软件包开发人员, 那么你将在这里发挥最大的作用。如果你可以促进或将这些概念整合到平台中, 则将影响Web开发的整个格局。如果你确实将其纳入包装设计中, 请告诉我, 我会为你进行传播。
最后, **如果你是开发人员或设计师**, 请不要仅仅停留在最佳做法上。始终尝试在该范围内稍微看一下。为了你的客户和用户的利益, 艰巨的工作是要推动那些尚未有人要求的, 未被支持和未记录的概念。
最终, 如果你想听听某人进行数小时的讨论并发现自己在萨格勒布附近, 请告诉我。我们可以去喝杯咖啡。
