2013年8月1日
第11卷，第6期

移动性能优化规则

加快页面加载速度的技术概述

Tammy Everts，Radware

性能一直是网站成功的关键。越来越多的研究证明，即使页面加载时间的微小改进也能为企业带来更多的销售额、更多的广告收入、更高的用户粘性和更高的客户满意度，这些企业范围从小型电子商务商店到沃尔玛等大型连锁企业。

多年来，Web开发者可以依靠硬件和带宽的稳步提升来帮助提供最佳的用户体验。然而，近年来，移动Web浏览的爆炸式增长扭转了这一局面。移动设备较低的带宽、较高的延迟、较小的内存和较低的处理能力，使得前端性能优化变得更加迫切，以满足用户期望。

本文总结了前端优化的必要性，并概述了加速页面加载的策略和技巧，重点是解决移动性能问题。

为什么性能至关重要

无论您的网页多么有趣、美观或巧妙地互动，如果它们需要两到三秒以上的时间来渲染，无论是在桌面设备还是移动设备上，用户都会很快变得不耐烦。他们从浏览到购买的转化率会明显降低，甚至可能在页面加载完成之前就点击后退按钮或关闭浏览器。

即使不到一秒的延迟也会显著影响收入。2006年，时任谷歌的玛丽莎·梅耶尔回忆说，在用户表示他们希望每页看到超过10个搜索结果后，谷歌尝试显示30个结果。令谷歌惊讶的是，这项实验导致流量和收入下降了20%，显然是因为显示更多结果的页面加载时间只多用了半秒钟。⁵

从那时起，用户期望只增不减。Forrester Research 在 2009 年代表 Akamai 进行的一项研究表明，两秒是可接受的网页响应时间的阈值，并发现 40% 的消费者会放弃加载时间超过三秒的页面。仅仅一年后，另一项为 Akamai 进行的研究发现，三秒后放弃页面的用户数量已上升至 57%。^1,7

此外，移动设备用户期望性能至少与他们在台式机上体验到的性能一样好，甚至更好。Harris Interactive 2011 年移动交易调查（由 Tealeaf Technology（现为 IBM 的一部分）委托进行）报告称，85% 的成年人在前一年进行过移动交易，他们期望移动体验与使用笔记本电脑或台式电脑在线购物的体验相同或更好，63% 的人表示，如果他们在手机上进行交易时遇到问题，他们将来通过其他渠道从同一家公司购买的可能性会降低。¹⁰ 换句话说，糟糕的移动性能会损害公司在所有其他平台上的业务，包括实体店。

移动流量正在迅速扩张。对于许多消费者来说，他们的手机或平板电脑已成为他们访问互联网的主要入口，但性能却未达到预期。Equation Research 代表 Compuware 于 2011 年 2 月发布的一项研究发现，几乎一半（46%）的移动用户表示，网站在手机上的加载速度比预期的要慢。近 60% 的人期望页面在三秒或更短的时间内加载完成，74% 的人表示，如果单个页面加载时间超过五秒，他们就会离开该网站。Strangeloop Networks（现为 Radware 的一部分）在 2012 年对 200 个领先的电子商务网站进行的一项研究发现，3G 网络上的中位加载时间为 11.8 秒（图 1）；LTE 网络上的性能仅略好，为 8.5 秒。⁸

Median Load Times for Desktop and Mobile Devices

移动性能的三个限制因素

如前所述，移动设备具有固有的性能限制：较低的带宽、较小的内存和较低的处理能力。这些挑战因外部问题而加剧，尤其是

网页比以往任何时候都更大。 根据 HTTP Archive 的数据，平均网页的有效负载超过 1 MB，并且包含至少 80 个资源，例如图像、JavaScript、CSS（层叠样式表）文件等。这对桌面性能产生了重大影响。它对移动性能，尤其是 3G 性能的影响更为显著。未来三年，这种影响将更加明显。按照目前的增长速度，到 2015 年，平均页面大小可能会超过 2 MB。

延迟可能差异很大。 LTE 的延迟可能低至 34 毫秒，而 3G 的延迟可能高达 350 毫秒或更高。即使在同一地点测量，移动延迟也只在其不一致性方面保持一致。这是由于许多变量造成的，而不仅仅是通过基站的数据量。天气，甚至用户面对的方向等因素都会产生重大影响。

下载速度也可能差异很大。 速度范围从 3G 网络上的 1 Mbps 到 LTE 网络上的 31 Mbps 不等。有趣的是，将其与美国平均 15 Mbps 的宽带速度进行比较，并注意到 3G 可能比宽带慢 15 倍，而 LTE 可能比宽带快两倍。

m.sites 并非解决移动性能问题的万能药

许多网站所有者试图通过开发更小、更快、精简的 m.sites 来应对用户需求高、网页大和连接速度慢的组合；然而，这些尝试并非完全有效，因为多达 35% 的移动用户在可以选择的情况下会选择查看完整网站。

这些完整网站的访问者比 m.site 的访问者更有可能消费。一项研究发现，在移动设备产生的每 7.00 美元的收入中，有 5.50 美元是通过完整网站产生的。只有 1.00 美元来自 m.sites，0.50 美元来自应用程序。⁹

解决问题

随着使用场景从桌面设备迁移到移动电话和平板电脑，改进网站性能的主要策略没有改变，尽管出现了一些新的策略。

无论是在桌面浏览器还是移动浏览器中，显示典型网页所需的时间中，只有 20% 用于加载网页的 HTML。剩下的 80% 用于加载渲染页面所需的其他资源（包括样式表、脚本文件和图像）以及执行客户端处理。

改进性能的三个主要策略是

减少获取每个页面资源所需的 HTTP 请求数量。
减少满足每个请求所需的有效负载大小。
优化客户端处理优先级和脚本执行效率。

由于移动网络通常比桌面设备可用的网络慢，因此减少请求和有效负载变得非常重要。移动浏览器解析 HTML 和执行 JavaScript 的速度较慢，因此优化客户端处理至关重要。此外，移动浏览器缓存比桌面浏览器小得多，这需要新的方法来利用可重用资源的本地存储。

本文的其余部分总结了您可以使用的一些策略来应对这些挑战。虽然大多数实践都有自动化工具可用，但许多实践也可以手动实现（由经验丰富的前端开发人员实现）。需要注意的是，手动实施许多这些技术的一个主要挑战是对资源的控制。通常在 CMS（内容管理系统）或其他 Web 应用程序中，页面可能包含 HTML 代码片段、CSS 和 JavaScript 文件，这些文件要么是生成的，要么是托管在外部站点的，这意味着开发人员无权对其进行优化。

减少请求

性能的最大损耗通常是需要完成数十次网络往返以检索资源，例如样式表、脚本和图像。对于带宽相对较低且延迟较高的移动连接来说尤其如此。CDN（内容分发网络）可以通过将内容在地理位置上更靠近用户来提供一些帮助，但是请求的数量对页面加载时间的影响远大于这些请求传输的距离。此外，最近的研究结果表明，CDN 对于移动用户的有效性有限。³

以下各节讨论了减少 HTTP 请求的几种方法。

合并资源

现在，开发人员将 JavaScript 代码和 CSS 样式合并到可在多个页面之间共享的公共文件中已成为标准做法。此技术简化了代码维护并提高了客户端缓存的效率。

在 JavaScript 文件中，请确保同一页面不会多次下载相同的脚本。当大型团队或多个团队协作进行页面开发时，尤其容易出现冗余脚本下载。您可能会惊讶于这种情况发生的频率。

雪碧图 是一种用于合并图像的 CSS 技术。雪碧图只是将多个图像组合成一个大图像中的矩形网格。页面一次性将大图像作为单个 CSS 背景图像获取，然后使用 CSS 背景定位在页面上根据需要显示各个组件图像。这可以将多个请求减少为一个，从而显着提高性能。

易于实施程度：中等，但需要有权访问资源。根据开发人员对网站的控制级别，某些资源可能无法合并（例如，如果它们是由 CMS 生成的）。此外，某些资源可能位于外部域上，这可能会导致合并问题。还需要注意的是，对于移动浏览器而言，资源合并可能是一把双刃剑。第一次减少请求可以提高性能，但较大的合并资源可能无法有效地缓存，因此请注意将合并技术与其他技术结合使用以优化localStorage.

使用浏览器缓存和 localStorage

所有现代浏览器都使用本地内存来缓存已标记 Cache-Control 或 Expires 标头的资源，这些标头指示项目可以缓存多长时间。此外，ETag（实体标记）和 Last-Modified 标头指示在资源过期后应如何在缓存中重新填充资源。浏览器尽可能在本地获取缓存的项目，避免不必要的服务器请求，并在缓存空间不足时刷新已过期或最近未使用的项目。浏览器对象缓存中存储的资源通常包括图像、CSS 和 JavaScript 代码，缓存对于可接受的网站性能至关重要。（单独的缓存保存整个渲染的页面，以支持使用后退和前进按钮。）

然而，移动浏览器缓存通常比桌面设备上的缓存小得多，导致项目被快速刷新。HTML5 Web 存储规范提供了一个很好的替代方案，可以替代仅依赖浏览器缓存。HTML5localStorageJavaScript 对象已在所有主要的桌面和移动浏览器中实现。脚本代码可以轻松检查对 HTML5 的支持localStorage然后使用它（如果可用）来保存和读取键/值数据，通常每个域 5 MB。此功能使localStorage非常适合客户端缓存，尽管不同移动浏览器的读/写速度确实有所不同。从localStorage中检索资源通常比从服务器请求资源快得多，并且它比仅依赖缓存标头和大多数移动设备上可用的有限浏览器缓存存储更灵活、更可靠。此外，这是移动浏览器目前在效率方面领先于桌面浏览器的一个领域——localStorage性能在桌面实现中一直滞后，在桌面实现中，使用标准浏览器缓存可能仍然是最佳选择。

易于实施程度：高级。虽然localStorage机制可能易于使用，但在其周围构建缓存确实会带来一些复杂性。您需要考虑缓存为您处理的所有问题，例如缓存过期（何时删除项目？）、缓存未命中（如果您期望某些内容在localStorage中但它不在？），以及当缓存已满时该怎么办。

将资源嵌入 HTML 以供首次使用

HTML 中的标准模式是包含指向外部资源的链接。这使得将这些资源作为服务器（或 CDN）上的文件进行维护，并在源头而不是在许多页面中的每一个页面中更新它们变得更容易。如前所述，这种模式还通过允许从缓存而不是从服务器自动获取缓存的资源来支持浏览器缓存。

对于尚未在浏览器或localStorage中的资源，但是，这种链接到外部资源的模式会对性能产生负面影响。一个典型的页面可能需要数十个单独的请求才能收集渲染页面所需的资源。因此，从性能的角度来看，如果资源不太可能已被缓存，则最好将该资源嵌入到页面的 HTML 中（称为内联），而不是将其外部存储并链接到它。HTML 中支持脚本和样式标签以用于内联这些资源，但图像和其他二进制资源也可以通过使用包含资源的 base64 编码文本版本的数据 URI 进行内联。

内联的缺点是页面大小可能会变得非常大，因此对于使用此策略的 Web 应用程序来说，能够跟踪何时需要资源以及资源何时已缓存在客户端至关重要。此外，应用程序必须生成代码以在第一次内联发送资源后将其存储在客户端上。因此，使用 HTML5localStorage在移动设备上是内联的好搭档。

易于实施程度：中等。此技术要求站点具有一种机制，可以根据用户之前是否访问过该页面来生成不同版本的页面。

使用 HTML5 服务器发送事件

Web 应用程序已使用各种轮询技术，通过从服务器请求新数据来不断更新页面。HTML5EventSource对象和服务器发送事件使浏览器中的 JavaScript 代码能够打开从服务器到浏览器的效率更高的单向通道。然后，服务器可以使用此通道在数据可用时发送数据，从而消除创建多个轮询请求的 HTTP 开销。这也比 HTML5 WebSockets 更有效，后者是一种更丰富的协议，用于在需要大量客户端-服务器交互时（例如在消息传递或游戏）在全双工连接上创建双向通道。

易于实施程度：高级。此技术非常特定于实现。如果您的站点当前正在使用其他 AJAX 或 Comet 技术进行轮询，则转换为使用服务器发送事件可能需要对站点的 JavaScript 进行大量重写。

消除重定向

当用户尝试从移动设备导航到标准桌面站点时，Web 应用程序通常会读取 user-agent HTTP 标头以检测请求是否来自移动设备。然后，应用程序可以发送一个 HTTP 301（或 302）响应，其中包含空主体和一个 Location 标头，根据需要将用户重定向到站点的移动版本。但是，在移动网络上，额外的客户端往返于移动站点通常会消耗数百毫秒。相反，直接响应原始请求来传递移动网页，而不是传递重定向消息，然后再请求移动网页，这样速度更快。

为了方便喜欢即使在移动设备上也查看桌面站点的用户，您可以在移动站点上提供一个链接，以指示您的应用程序抑制此行为。

易于实施程度：虽然从理论上讲，此技术很容易，但实际应用可能并非总是可行。许多站点将其 m.sites 重定向到不同的服务器，因为这些站点可能托管在其他地方。其他站点在重定向时发送 cookie，以告知 Web 应用程序它们是移动设备。根据 Web 应用程序的不同，这可能更难控制。

减少有效负载

大小很重要。页面越小，渲染速度越快，资源越小，获取速度越快。减少每个服务器响应的大小通常不如减少每个页面所需的响应数量对性能的帮助大。然而，有几种技术确实对性能产生了净收益，尤其是在必须明智地管理带宽和处理能力的移动设备上。

压缩文本和图像

诸如 gzip 之类的压缩技术可以减少有效负载，但代价是增加了在服务器上压缩和在浏览器中解压缩的处理步骤。然而，这些操作经过高度优化，测试表明，总体效果是性能的净提升。基于文本的响应，包括 HTML、XML、JSON（JavaScript 对象表示法）、JavaScript 和 CSS，其大小都可以减少多达 70%。

浏览器在 Accept-Encoding 请求标头中声明其解压缩能力，并且当服务器在 Content-Encoding 响应标头中指示响应已压缩时，它们会自动执行解压缩。

易于实施程度：简单。如果设置正确，所有现代 Web 服务器都将支持压缩响应。但是，仍然有一些桌面安全工具会从请求中删除 Accept-Encoding 标头，这将阻止用户获得压缩响应，即使他们的浏览器支持压缩响应也是如此。

缩小代码

缩小通常仅应用于脚本和样式表，它可以消除不必要的字符，例如空格、换行符和注释。未公开的名称（例如变量名）可以缩短为一到两个字符。正确缩小化的资源在客户端上使用，无需任何特殊处理，文件大小平均减少约 20%。HTML 页面中的脚本和样式块也可以缩小化。有许多优秀的库可用于执行缩小化，通常还提供将多个文件合并为一个文件的服务，这还可以减少请求。

缩小不仅可以减少带宽消耗和延迟，而且还可能意味着可缓存对象与对于特定移动设备上的缓存来说过大的对象之间的区别。Gzip 压缩在这方面没有帮助，因为对象在被解压缩后会被浏览器缓存。

易于实施程度：简单。谷歌的 Closure Compiler 在理解和缩小 JavaScript 方面做得非常出色。CSS 缩小化有点麻烦，因为针对不同浏览器的 CSS hack 太多了，这些 hack 很容易使缩小器混淆，或者在缩小化后不再正常工作。另请注意，有已发布的报告称缩小化会破坏页面，即使删除的字符不应该是必要的。因此，请务必对应用此技术的任何页面执行功能测试。

调整图像大小

图像通常消耗加载网页所需的大部分网络资源，以及缓存页面资源所需的大部分空间。小屏幕移动设备通过调整图像大小为加速传输和渲染提供了机会。如果用户只在小型移动浏览器窗口中查看图像，则高分辨率图像会浪费带宽、处理时间和缓存空间。

为了加快页面渲染速度并减少带宽和内存消耗，请在您的应用程序中动态调整图像大小，或为移动站点替换为较小版本的图像。不要浪费带宽来依赖浏览器将高分辨率图像缩放到较小的宽度和高度。

另一种选择是最初加载非常低分辨率的图像版本，以尽快显示页面，然后在onload或在用户开始与页面交互后的 ready 事件中将其替换为更高分辨率的版本。

易于实施程度：高级，特别是对于高度动态的站点。

使用 HTML5 和 CSS 3.0 简化页面

HTML5 规范包括新的结构元素，例如header、nav、article、和footer。与使用通用的嵌套div和span标签相比，使用这些语义元素可以生成更简单、解析效率更高的页面。更简单的页面更小、加载速度更快，更简单的 DOM（文档对象模型）意味着更快的 JavaScript 执行速度。新标签正在新浏览器版本（包括移动浏览器）中迅速被采用，并且 HTML5 被设计为在尚不支持它的浏览器中优雅地降级。

表单中的 HTML5 输入元素支持许多新属性，这些属性使声明式 HTML 代码能够实现以前需要 JavaScript 才能实现的功能。例如，新的 placeholder 属性可以指定在用户进行输入之前出现的说明性文本，而新的 autofocus 属性可以指定哪个输入应自动获得初始焦点。

还有几种新的输入元素类型，它们可以在没有 JavaScript 的情况下自动实现常用的功能。新类型包括电子邮件、URL、数字、范围、日期和时间，它们被有效地渲染为具有友好的用户界面和验证的复杂控件。在移动浏览器中，当需要文本输入时，弹出键盘通常会自动提供适合指定输入类型的击键选择。不支持指定输入类型的浏览器将仅显示一个文本框。

此外，新的 CSS 3.0 功能可以通过提供对渐变、圆角边框、阴影、动画、过渡和其他以前需要加载图像的图形效果的内置支持，来帮助创建轻量级页面。这些新功能可以加快页面渲染速度。

许多网站定期更新列表，显示哪些桌面和移动浏览器支持哪些功能（例如，https://caniuse.cn/ 和 mobilehtml5.org

易于实施程度：高级。手动进行这些更改非常复杂且耗时，即使不是不可能。如果您使用 CMS，它可能会生成大量您无法控制的 HTML 和 CSS。

优化客户端处理

浏览器执行构建页面所需的各个步骤的顺序可能会对性能产生重大影响，页面的复杂性和 JavaScript 技术的选择也是如此。这在移动设备上尤其如此，在移动设备上，客户端处理受到较慢的 CPU 和较小的内存的限制。以下各节提供了一些提高页面处理效率的策略。

延迟渲染首屏下方内容

您可以通过延迟加载和渲染最初可见区域下方的任何内容（有时称为“首屏下方”）来确保用户更快地看到页面。为了消除在页面其余部分加载后重新排列内容的需要，请最初用占位符替换图像<img>标签，这些标签指定了正确的高度和宽度。

易于实施程度：中等。一些优秀的 JavaScript 库可用于首屏下方图像的懒加载。¹²

延迟加载和执行脚本

在某些移动设备上，解析 JavaScript 可能需要每千字节代码 100 毫秒的时间。许多脚本库在页面完成渲染后才需要。下载和解析这些脚本可以安全地延迟到onload事件之后。例如，支持交互式用户行为（例如拖放）的脚本不可能在用户甚至看到页面之前被调用。相同的逻辑适用于脚本执行。尽可能延迟到onload之后，而不是不必要地延迟页面上重要的可见内容的初始渲染。

要延迟的脚本可能是您自己的脚本，或者更重要的是，来自第三方的脚本。用于广告、社交媒体小部件或分析支持的优化不良的脚本可能会阻止页面渲染，有时会使加载时间增加宝贵的几秒钟。此外，请仔细评估在移动站点上使用大型脚本框架（例如 jQuery）的情况，特别是当您仅使用框架中的几个对象时。

易于实施程度：中等。许多第三方框架现在提供其 API 的延迟或异步版本。开发人员只需切换到这些新版本即可。某些 JavaScript 可能更难延迟，因为在onload之后运行脚本有很多注意事项（例如，如果您的脚本想要附加到onload事件怎么办？如果您将其延迟到onload之后，它就错过了机会）。

使用 Ajax 进行渐进增强

AJAX（异步 JavaScript 和 XML）是一种使用 XHR (XMLHttpRequest) 对象从 Web 服务器获取数据，而无需刷新代码正在运行的页面。AJAX 使页面能够在页面的某个部分显示更新的数据，而无需重建整个页面。这通常用于响应用户交互，但它也可以使您的应用程序快速加载页面的基本版本，然后在用户已经查看页面时填充更详细的内容。

尽管名称如此，XMLHttpRequest并不限制您仅使用 XML。您可以调用其overrideMimeType方法来指定 "application/json" 并使用 JSON 而不是 XML。使用JSON.parse比使用通用的eval()函数快两倍，并且更安全。

另外，请记住，AJAX 响应将受益于为标准响应推荐的许多相同的优化技术。请务必将缓存标头、缩小化、gzip 压缩、资源合并等应用于您的 AJAX 响应。

易于实施程度：难以量化，因为此技术非常特定于应用程序。由于跨域问题，您需要使用 XHR2，并控制外部域以进行跨域 XHR 请求。

适应网络连接

尤其是在移动网络可能会因使用更多带宽而收取额外费用的情况下，某些技术应仅在与检测连接类型的代码结合使用时才使用。例如，预加载资源以 anticipation 未来的请求通常是明智的，但如果用户的带宽是计量计费的，并且某些资源可能永远不需要，则这可能不是负责任的策略。

在 Android 2.2+ 上，navigator.connection.type 属性返回的值允许您区分 Wi-Fi 与 2G/3G/4G 连接。在 Blackberry 上，blackberry.network 提供类似的信息。此外，服务器端检测 User-Agent 标头数据或嵌入在请求中的其他信息可以提醒您的应用程序正在使用的连接质量。

易于实施程度：高级。网络信息 API 最近已更改。¹¹ 它不再将网络定义为 Wi-Fi、3G 等，而是提供有关带宽的信息，建议值例如“非常慢、慢、快和非常快”。有一个属性试图告知估计的 MB/s，以及一个布尔值“计量”测量，它尽力做到正确，但这对于浏览器来说非常难以确定。在某处进行测量并适应可能仍然是最好的主意，但非常具有挑战性。

使用 HTML5 Web Worker 规范进行多线程处理

HTML5 中的 Web Worker 规范将多线程并发执行引入了 JavaScript 编程世界。此外，这种多线程的特定实现消除了困扰在其他平台上使用多线程的开发人员的问题——特别是，当一个线程修改另一个线程也在使用的资源时发生的问题。在 Web Worker 代码中，派生的线程无法访问主用户界面 (UI) 线程的资源。

为了提高移动站点的性能，Web Worker 代码对于预加载用户可能需要完成未来操作的资源非常有用，尤其是在用户的带宽不是计量计费的情况下。由于移动设备的处理器能力有限，大量的预加载可能会干扰当前页面中的 UI 响应能力。使用采用 Web Worker 对象（以及可能的localStorage来缓存数据）的多线程代码，预加载资源的操作可以在单独的线程上执行，而不会影响当前的 UI 性能。

请注意，Web Worker 规范虽然自 2.0 起已在 Android 中实现，但在 iOS 5 之前在 iPhone 上不受支持。在桌面上，Internet Explorer 是落后者，仅在 IE 10 中添加了对 Web Worker 的支持。

易于实施程度：中等。虽然此技术并非难以置信地难以实现，但 Web Worker 有一些限制，使其难以找到应用的地方。它们无权访问页面的 DOM，也无法修改页面上的任何内容。要使这种做法奏效，需要一种非常特定类型的后台计算或进程，该进程非常适合作为后台 Web Worker。

用触摸事件替换点击事件

在触摸屏设备上，onclick当用户点击屏幕时，event 事件不会立即触发。相反，设备会等待最多半秒（在大多数设备上为 300 毫秒），让用户有机会发起一些其他手势，而不是点击。然而，这种延迟会显著影响用户期望的响应性能。为了解决这个问题，请使用touchend事件。该事件会在用户点击屏幕时立即触发。

为了确保用户不会遇到意外的行为，您可能还需要使用touchstart和touchmove事件。例如，不要假设touchend在一个按钮上意味着点击，除非也有一个touchstart事件在按钮上——而不是如果用户触摸了其他地方并拖动到按钮上才结束触摸。您可以使用一个touchmove事件在touchstart之后，以防止将随后的touchend视为点击，假设移动手势并非旨在作为点击。

此外，您可能仍然希望处理onclick事件，以确保浏览器更改按钮的外观以显示点击状态，并支持不处理触摸事件的浏览器。为了避免在touchend和onclick代码触发时重复执行代码，请添加一个点击事件处理程序，该处理程序调用preventDefault和stopPropagation如果点击是用户点击的结果，并且该点击已被touchend.⁴

易于实现程度： 高级。这项技术需要更多的工作来添加和维护页面上的链接。测试触摸事件的代码必须能够应对可能发生的代替点击的手势，例如缩放或滑动。

支持 SPDY 协议

无论是桌面网站还是移动网站，Web 网站遇到的一些性能瓶颈都源于应用层 HTTP 和 HTTPS 协议的低效率。2009 年，Google 开始着手开发一种名为 SPDY（发音为“speedy”）的替代协议，以解决其中一些限制。目标是将其打造为一个开源项目，由多家浏览器和 Web 服务器实施，但最初仅在 Google 的 Chrome 浏览器（版本 10 或更高版本）和 Google 网站上受支持。随着实施 SPDY 的 Web 服务器的发布，网站将能够为任何使用支持该协议的浏览器的用户使用此协议。在一项针对 100 个顶级互联网网站中具有代表性的 25 个网站实施 SPDY 的测试中，Google 观察到速度提升幅度在 27% 到 60% 之间。²

SPDY 自动对所有内容使用 gzip 压缩，并且与 HTTP 不同，它还对标头数据使用 gzip。SPDY 采用多路复用技术，以允许通过单个 TCP 连接发送多个请求或响应流。此外，SPDY 允许请求被赋予优先级，因此，例如，对于页面内容至关重要的视频可以被赋予比边距中的广告更高的优先级。

SPDY 中最具革命性的创新或许是流可以是双向的，并且可以由客户端或服务器发起，从而允许将内容推送到客户端，而无需先请求。例如，当用户首次访问网站，因此尚未缓存任何网站内容时，服务器可以推送所有必需的资源以响应第一个页面请求，而不是等待单独请求每个资源。作为替代方案，服务器可以向客户端发送提示，建议将需要的资源，但仍然允许客户端发起请求。这仍然比等待客户端解析站点页面并自行发现资源需求要快。

尽管 SPDY 并非专门针对移动平台，但移动网络上可用的带宽有限意味着，当支持 SPDY 优化时，它在减少移动网站的延迟方面将尤其有用。

易于实现程度： 中等到高级，具体取决于站点和服务器环境。Google 有一个用于 Apache 2.2 的 SPDY 模块——mod_spdy——可免费使用；然而，mod_spdy存在线程模型问题，并且默认情况下与mod_php不兼容，因此这需要额外的关注，以确保它在您的网站上正确运行。⁶

不要忘记测试！

如果不提醒持续和仔细的测试至关重要，那么关于性能优化的讨论将是不完整的。在针对基准进行测试之前，对系统的每一项更改都只是一种理论。除非基于真实的测试数据，否则猜测性能瓶颈发生在哪里毫无意义。

有许多出色的开源和商业工具可用于提供综合测试，包括地理分布和带宽/延迟限制。此外，RUM（真实用户监控）工具将测试从实验室带到不可预测的用户行为领域。

寻找支持移动和桌面场景的测试选项。如果您选择自动化解决方案，请务必选择持续测试和改进其应用的优化的解决方案。

如果性能优化仅仅是线性开发过程中的一个步骤，那么它就不可能有效。相反，它必须成为持续改进的持续循环的一部分。

参考文献

1. Bustos, L. 2009. 每秒都很重要；网站性能如何影响购物者行为。GetElastic; http://www.getelastic.com/performance/.

2. Chromium Projects. SPDY：用于更快 Web 的实验性协议； https://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper.

3. Everts, T. 2013. 案例研究：CDN 对移动访问者有多有效。Web Performance Today; http://www.Webperformancetoday.com/2013/05/09/case-study-cdn-content-delivery-network-mobile-3g/.

4. Fioravanti, R. 2011. 为移动 Web 应用程序创建快速按钮。Google Developers; http://code.google.com/mobile/articles/fast_buttons.html.

5. Linden, G. 2006. Marissa Mayer 在 Web 2.0 大会上。Geeking with Greg; http://glinden.blogspot.com/2006/11/marissa-mayer-at-Web-20.html.

6. mod-spdy; http://code.google.com/p/mod-spdy/.

7. PhoCusWright. 2010. PhoCusWright/Akamai 旅行网站性能研究； http://connect.phocuswright.com/2010/06/phocuswrightakamai-study-on-travel-site-performance/; http://www.akamai.com/dl/whitepapers/Akamai_PCW_Travel_Perf_Whitepaper.pdf.

8. Radware. 2011. 来自移动前沿的案例研究：更快的移动网站与业务 KPI 之间的关系； http://www.strangeloopnetworks.com/resources/research/state-of-mobile-ecommerce-performance/.

9. Bixby, J. 2012. 2012 年移动电子商务性能状况； http://www.strangeloopnetworks.com/resources/videos/case-studies-from-the-mobile-frontier-the-relationship-between-faster-mobile-sites-and-business-kpis-video/.

10. Tealeaf. 2011. 移动客户体验报告。基于 Harris Interactive 2011 年移动交易调查。

11. W3C. 2012. 网络信息 API； http://www.w3.org/TR/netinfo-api/.

12. YUI. ImageLoader。Yahoo! 用户界面库； http://yuilibrary.com/yui/docs/imageloader/.

喜欢或讨厌它？请告诉我们
[email protected]

Tammy Everts 自 1997 年以来一直从事用户体验和 Web 性能方面的工作。她目前在 Radware 工作，在公司内外宣传性能。此前，她曾在 Strangeloop Networks 担任研究主管，在 Habanero Consulting 担任用户体验总监。她在 http://webperformancetoday.com 博客上撰写有关性能问题、研究和趋势的文章

最初发表于 Queue vol. 11, no. 6—
在数字图书馆中评论本文

更多相关文章

Shylaja Nukala, Vivek Rau - 为什么 SRE 文档很重要
SRE（站点可靠性工程）是一种职位职能、一种思维模式以及一组工程方法，用于使 Web 产品和服务可靠地运行。SRE 在软件开发和系统工程的交叉点运作，以解决运营问题并设计解决方案，从而可扩展、可靠且高效地设计、构建和运行大规模分布式系统。成熟的 SRE 团队可能拥有与许多 SRE 职能相关的完善的文档体系。

Taylor Savage - 组件化 Web
在当今的软件工程中，没有哪项任务能像 Web 开发那样艰巨。一个典型的 Web 应用程序规范可能如下：该应用程序必须在各种浏览器中工作。它必须以 60 fps 的速度运行动画。它必须立即响应触摸。它必须符合一组特定的设计原则和规范。它必须在几乎所有可以想象的屏幕尺寸上工作，从电视和 30 英寸显示器到手机和手表表面。它必须在长期内得到良好的工程设计和可维护性。

Arie van Deursen - 超越页面对象：使用状态对象测试 Web 应用程序
Web 应用程序的端到端测试通常涉及通过诸如 Selenium WebDriver 之类的框架与 Web 页面进行棘手的交互。隐藏此类 Web 页面复杂性的推荐方法是使用页面对象，但是首先要回答一些问题：在测试 Web 应用程序时，应该创建哪些页面对象？页面对象中应包含哪些操作？给定页面对象，应该指定哪些测试场景？

Rich Harris - 消除入门障碍
一场战争正在 Web 开发领域打响。一方是工具制造商和工具用户的先锋，他们以摧毁糟糕的旧观念（在这个领域，“旧”意味着任何在一个多月前在 Hacker News 上首次亮相的东西）以及关于转译器等的热烈辩论而蓬勃发展。