移动性能的优化规则

文章转自http://queue.acm.org/detail.cfm?id=2510122 用谷歌翻译的，可能会拗口，但是很有用！！

技术，以加快页面加载的概述

塔米动态，RADWARE

性能一直是网站成功的关键。越来越多的研究已经证明，即使是很小的改善页面加载时间，导致更多的销售，更多的广告收入，更多的粘性，范围从小型电子商务商店如沃尔玛等megachains的企业和更多的客户满意度。

多年来，Web开发人员可以依靠稳定在硬件和带宽的改善，以帮助实现最佳的用户体验。然而，近年来，移动Web浏览爆炸逆转。低带宽，高等待时间，更小的存储器和更低的处理能力的移动设备的实施更加迫切的需求，为了满足用户的期望，在其前端，以优化性能。

本文总结了前端优化的情况，并提供了一个概述的战略和战术，加快您的网页，并着重于解决移动性能问题。

为什么性能事项

无论多么有趣的，美丽的，或巧妙的互动网页，如果他们需要超过两个或三个秒呈现，无论是在台式机或移动设备，用户很快就会不耐烦。他们是可测量的可能性较小，从浏览到购买的转换，甚至可能打到“后退”按钮或关闭浏览器，页面之前曾经负载。

即使不到一秒钟的延迟显着影响的收入。在2006年，谷歌的时候，梅丽莎·梅耶（Marissa Mayer）讲述后，用户表示，他们希望看到超过10每页搜索结果，谷歌尝试，而不是显示30。谷歌的惊喜，流量和收入下降了20％，在这个实验中，这显然是因为更多的网页了只是一个额外的半秒加载。

自此只升级用户的期望。由Forrester研究公司Akamai的代表2009年的一项研究发现可接受的Web页面响应时间的门槛，两秒钟发现，40％的消费者放弃一个页面，需要更长的时间超过三秒钟加载。仅仅一年后，做了Akamai的另一项研究发现，三秒钟后放弃一个页面的用户数已经上升到57％。1,7

此外，移动设备上的用户期望的性能至少是一样好，如果不是更好的比他们的经验他们的桌面上。哈里斯互动2011移动交易的调查，委托茶叶的技术（现在是IBM的一部分），报告，85％的成年人谁在过去一年进行移动交易预计移动体验等于或优于网上购物使用笔记本电脑或台式电脑，63％的受访者表示，他们将不太可能通过其他渠道购买来自同一家公司，如果他们经历了一个问题，他们的手机上进行交易。10换句话说，移动性能较差伤害公司所有其他平台上，包括砖和砂浆。

移动流量正在迅速扩大。对于很多消费者来说，他们的手机或平板电脑已成为他们主要的互联网门户网站，但性能逊于预期。方程研究代表Compuware公司于2011年2月发表的一项研究发现，几乎一半（46％）的手机用户说网站加载较预期缓慢自己的手机上。近60％的受访者预计在3秒或更少的页面加载，74％报告说，他们会留下一个单页网站，如果花了五秒钟或更长时间来加载。200领先的电子商务网站还是Strangeloop网络（现在Radware的一部分）2012年的一项研究发现，平均负载时间为11.8秒在3G（图1），在LTE的性能表现稍微好一点，在8.5秒。

三个手机性能的限制因素

正如已经提到的，移动设备具有固有的性能的限制：较低的带宽，更小的存储器和处理能力较低。这些挑战更加复杂的外部性问题，特别是：

Web页面是比以往更大。根据HTTP过刊，平均网页携带超过1百万字节的有效载荷，包含至少80个资源（如图片，JavaScript，CSS（层叠样式表）文件，等等），这有一个台式机性能的显着影响。其移动性能的影响，特别是3G的性能要明显得多。这种影响将在未来三年更敏锐地感觉到。在目前的增长速度，平均页面大小可能超过2015年2 MB的。

延迟可以有很大的不同，它可以3G LTE从34毫秒到350毫秒或以上不等。移动延时是一致的，甚至在相同的位置测量时，仅在其不一致。这是由于一些穿过塔的数据量超出了变量。因素，如天气，甚至用户正面临着方向，可以有一个显着的影响。

下载速度也相差很大。速度范围可以从一个单纯的1 Mbps的3G高达31 Mbps的LTE。这是有趣的比较，美国的平均宽带速度为15 Mbps，并指出，3G可以高达15倍的速度比宽带，而LTE最多可以快两倍。

的M.SITES不能治愈所有对于移动性能的烦恼

许多网站所有者试图回应高的用户需求，大的网页，和连接速度差通过开发更小，速度更快，简装m.sites的组合，然而，这些尝试并不完全有效，因为高达35％移动用户将选择要查看完整的网站如果提供该选项。

这些网站的访问者显著更可能花费比m.site游客。一项研究发现，每移动产生的收入7.00元，通过网站生成5.50美元。只有1.00美元，来到通过m.sites，并通过应用程序0.50美元。

解决问题

用法已经从桌面到手机和平板电脑，虽然已经出现了一些新的战术，改善网站性能的主要策略并没有改变。

所需要的时间，无论是在桌面或移动浏览器以显示一个典型的Web页面，只有20％的被消耗，通过加载页面的HTML。剩余的80％是用于加载所需的额外资源来渲染页面，包括样式表，脚本文件，图像和执行客户端处理。

提高性能的三大战略是：

需要为每个页面获取资源的HTTP请求的数量减少。

减少所需的有效载荷的大小来完成每一个请求。

优化客户端的处理优先级和脚本执行效率。

由于移动网络通常慢于那些提供给台式机，减少请求和有效载荷需要巨大的重要性。移动浏览器解析HTML和执行JavaScript的速度较慢，所以优化客户端的处理是至关重要的。此外，手机浏览器缓存远远小于那些桌面浏览器，需要新的方法来利用本地存储的可重复使用的资源。

这篇文章的其余部分总结战术，你可以用它来应对这些挑战。虽然自动化工具，可用于大多数的这些做法，很多也可以实现手动（由经验丰富的前端开发）。关键是要注意，许多这些技术的人工推行的首要挑战是对资源的控制。经常在CMS（内容管理系统）或其他Web应用程序，网页可以包含HTML片段，CSS和JavaScript文件产生或托管场外，这意味着开发人员不必访问优化。

减少请求

最大的排水性能，通常需要完成几十个网络往返检索资源，如样式表，脚本和图像。这是特别真实与相对低带宽和高延迟的移动连接。地理上更接近用户带来内容的CDN（内容分发网络）可以有点帮助，但请求的数量有更大的影响页面加载时间的距离比那些请求旅游。此外，最近的研究结果表明，CDN的效果有限3为移动用户。

下面的章节中讨论了几种方法来减少HTTP请求。

整合资源

现在是标准的做法为开发者为普通的多个页面之间共享文件，可以巩固JavaScript代码和CSS样式。这项技术简化了代码维护和客户端缓存提高了工作效率。

在JavaScript文件，确保相同的脚本是不是下载一个页面多次。冗余的脚本下载时尤其如此大型团队或多个团队协作的页面开发。如何经常发生这种情况，它可能会让你大吃一惊。

Spriting是一个CSS技术巩固图像。精灵只是结合成直线性于一体的大型图像网格的多个图像。页面抓取大型图像，一次作为一个单一的CSS背景图像，然后使用CSS背景定位来显示个别组件需要在页面上的图像。这减少了多个请求，只有一个，显着提高了性能。

易于实施：中等，但需要有对资源的访问。根据控制的水平上，开发商已经在网站上，有些资源可能不能够被合并（例如，如果它们是由一个CMS）。此外，一些资源可能位于外部域，这可能会导致整合的问题。同样重要的是要注意资源整合为移动浏览器可以是一个双刃剑。减少的要求提高性能，是第一次，但可能无法有效地缓存，所以要小心将巩固技术与其他技术相结合优化的localStorage较大的综合资源。

使用浏览器的缓存和本地存储

所有现代的浏览器使用本地内存来缓存已经标记的Cache-Control或Expires头表明多久可以缓存资源。此外，ETag的（实体标签）和资源应如何在缓存中重新填充后，他们已过期的Last-Modified头。浏览器获取本地缓存项目尽可能避免不必要的服务器请求，并刷新项目已过期或最近没有使用的缓存空间运行时短。存储在浏览器的对象缓存的资源通常包括图像，CSS和JavaScript代码，和可接受的网站性能，缓存是必不可少的。（一个单独的缓存保存整个渲染页面，以支持使用“后退”和“前进”按钮。）

然而，手机浏览器缓存，通常比台式机小得多，导致项目很快被刷新。HTML5 Web存储规范提供了一个很好的替代，仅仅依靠浏览器缓存。已经实现在所有主流桌面和移动浏览器的HTML5 的localStorage JavaScript对象。支持HTML5的localStorage的脚本代码可以很容易地检查，然后使用它，如果有的话，保存和读取的键/值数据，每个域一般为5 MB。这种能力使得localStorage的客户端缓存非常适合，虽然做不同的读/写速度为不同的移动浏览器。它通常是显着更快的从localStorage的检索资源，而不是要求它从一个服务器，它是更灵活，更可靠的比仅仅依靠缓存头和有限的大多数移动设备上的浏览器的缓存存储。此外，这是移动浏览器是目前领先的桌面效率localStorage的性能已经落后，使用标准的浏览器缓存可能仍然是最好的选择，在桌面实现的一个领域。

易于实施：先进。虽然localStorage的机制可能是简单易用，围绕它建立一个高速缓存，并创建一些复杂性。您将需要考虑到所有的缓存，为你处理的问题，如缓存届满（当你删除项目），高速缓存未命中（如果你预计什么东西在localStorage的，是不是？）和做什么，当缓存满了。

首次使用，在HTML中嵌入资源

在HTML中的标准模式，包括外部资源的链接。这使得更容易维护这些资源文件在服务器上（或在一个CDN），并更新它们上面的源，而不是在每个许多页面。这种模式也支持浏览器缓存允许缓存的资源自动获取从高速缓存中，而不是从服务器上，如前面所讨论。

然而，这种格局是不是已经缓存在浏览器中或在localStorage的资源，链接到外部资源的性能产生负面影响。一个典型的页面可能需要几十个单独的请求，以收集所需的资源来渲染页面。所以，从性能的角度来看，如果资源不具有高的可能性已经被缓存，它往往是最好的，资源嵌入在页面的HTML（内联），而不是将其存储和外部链接到它。支持HTML脚本和样式标记内联这些资源，但也可以使用数据URI包含base64编码的文本版本的资源内联图像和其他二进制资源。

内联的缺点是，页大小可以变得非常大，所以它是关键的Web应用程序，使用该策略，可以进行跟踪时，需要该资源时，以及当它已经缓存在客户端。此外，应用程序必须生成代码送内嵌在第一时间后，存储在客户端上的资源。出于这个原因，在移动设备上使用HTML5 的localStorage内联是一个伟大的同伴。

易于实施：适当。这种技术需要有一个机制，产生不同版本的页面基于用户是否之前访问该网页的网站。

使用HTML5服务器发送事件

Web应用程序已经用于各种轮询技术的不断更新页面从服务器请求新的数据。HTML5 的EventSource对象，并服务器发送事件使JavaScript代码在浏览器中打开一个更加高效的单向通道，从服务器到浏览器。然后，服务器可以使用此通道发送数据，因为它成为可用，消除创建多个投票请求的HTTP开销。这也是效率比HTML5 WebSockets的，这是创建一个双向的通道过大量的客户端-服务器交互时，被称为一个全双工的连接，如短信或玩游戏更丰富的协议。

易于实施：先进。这种技术是非常特定于实现的。如果您的网站目前正在使用其他的AJAX或彗星的技术的轮询，将使用服务器发送的事件可能需要相当多的重新编写网站的Javascript。

消除重定向

当用户试图从移动设备，浏览到一个标准的桌面站点，Web应用程序往往会读取用户代理HTTP头检测到请求是从移动设备。然后，应用程序可以发送一个HTTP 301（或302）响应一个空的身体和一个Location头，将用户重定向到网站的移动版本。然而，额外的往返到客户端并返回到移动网站往往通过移动网络消耗几百毫秒。相反，它是更快地提供移动网页直接回复到原来的请求，而不是提供一个重定向消息，然后请手机页。

作为一个礼貌谁喜欢查看桌面网站，甚至在他们的移动设备上的用户，可以提供移动网站上的链接，标志着您的应用程序来抑制这种行为。

易于实施：虽然这项技术在理论上很容易，它可能无法总是能够付诸实践。许多网站重定向到不同的服务器为他们的m.sites，因为那些可能被托管在别处。其他网站发送cookie重定向告诉Web应用程序，它们是移动的，一旦他们重定向。这可能是更严格的控制，取决于Web应用程序。

减少有效载荷

大小事宜。较小的页面渲染速度更快和更小的资源中提取更快。降低每个服务器的响应的大小通常不会帮助性能尽可能的数量减少为每个页面需要的响应。然而，一些技术，不产生净盈利性能，尤其是在移动设备上，必须明智地管理带宽和处理能力。

压缩文本和图像

如gzip压缩技术降低成本略有增加处理步骤，在服务器上压缩和解压在浏览器中的有效载荷。这些操作是高度优化的，然而，测试表明，总的效果是净的性能改善。基于文本的反应，包括HTML，XML，JSON（JavaScript对象符号），JAVASCRIPT和CSS，可以在缩小尺寸高达70％。

浏览器接受编码请求头中宣布自己的减压能力，他们自动进行解压缩，当服务器信号响应将被压缩，在内容编码的响应头。

易于实施：易。所有现代的Web服务器将支持压缩的反应，如果正确设置。不过，也有仍然桌面安全工具，将删除请求，这将阻止用户压缩反应，即使他们的浏览器都支持它接受编码头。

缩小代码

微小，通常只应用于脚本和样式表，消除无关紧要的字符，例如空格，换行符和意见。不公开的名称，如变量名，可以缩短到只有一个或两个字符。正确往上的资源是用来在客户端上没有任何特殊的处理，文件大小平均减少约20％。在HTML网页中的脚本和样式块也可以压缩。有很多很好的库可用来执行微小，往往伴随着多个文件合并成一个，这还能降低请求的服务。

微小不仅降低了带宽消耗和延迟，但也可能意味着可缓存的对象，一个是特定移动设备上的高速缓存太大的区别。Gzip压缩是在这方面没有任何帮助，因为对象是由浏览器缓存后，他们已解压缩。

易于实施：易。从谷歌的Closure编译器做一个令人难以置信的工作的理解和挡土墙的JavaScript。CSS压缩是一个比较麻烦一点，因为有这么多不同的浏览器，可以很容易混淆minifiers或不再正常工作后微小的CSS黑客。另外请注意，已经公布的微小破页的报告，即使删除的字符不应该是必不可少的。所以，要确保任何网页上应用此技术进行功能测试。

调整图像

图像往往消耗所需的网络资源来加载网页缓存页面资源所需的空间，而且其大部分的大多数。小屏幕的移动设备提供了机会，通过调整图像的超速传输和渲染。高分辨率图像浪费带宽，处理时间和缓存空间，如果用户将只能在一个小的移动浏览器窗口中查看图像。

要加快页面渲染和减少带宽和内存消耗，动态调整图像在你的应用程序或更换图像的较小版本的移动网站。不要浪费带宽依靠在浏览器上的高清晰度的图像缩放到一个较小的宽度和高度。

另一种选择是最初的图像获取页面尽快然后将其更换为更高分辨率的版本上的onload事件或准备开始后，用户与页面交互加载一个低分辨率版本。

易于实施：高级，尤其是对于高度动态的网站。

HTML5和CSS 3.0简化页面

HTML5规范包括新的结构元素，如头，导航，文章和页脚。使用这些语义元素产生一个更简单，更有效地解析比使用通用嵌套的div和跨度标签页。一个简单的页面体积更小，加载速度更快和更简单的DOM（文档对象模型）意味着更快的JavaScript执行。在新的浏览器版本，包括移动浏览器，很快被采纳新的标签和HTML5的浏览器还不支持它被设计为优雅降级。

HTML5表单中的input元素支持很多新的属性，使声明的HTML代码来实现，以前需要的JavaScript功能。例如，可以指定新的占位符属性说明文字出现，直到用户创建一个条目，新的自动对焦特性可以指定哪些输入应自动获得最初的重点。

也有一些新的输入元素的类型，它可以自动执行通常需要的功能不支持JavaScript。新的类型包括电子邮件，网址，数量，范围，日期和时间，这是有效地呈现为复杂的控制与友好的用户界面和验证。在移动浏览器，在弹出的键盘往往自动提供适当的按键选择到指定的输入类型时，需要输入文字。浏览器不支持指定的输入类型只会显示一个文本框。

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

一些网站提供定期更新的名单显示支持哪些功能通过桌面和移动浏览器（例如，http://caniuse.com/ mobilehtml5.org

易于实施：先进。手动进行这些更改是极其复杂和耗时的，如果不是不可能的。如果你使用一个CMS，它可能会产生一个很大的HTML和CSS，你有没有控制权。

优化客户端的处理

需要构建一个页面浏览器中执行的各个步骤的顺序可以有一个主要对性能的影响，因为这样做的页面的复杂性和JavaScript技术的选择。这是特别真实移动设备上的客户端处理受制于较慢的CPU和较少的内存。以下各节提供了一些战术，增加页面处理的效率。

延迟呈现以下折叠内容

你可以向用户看到的页面更快，延迟加载和呈现的任何内容，如果在最初的可见区域，有时被称为“低于倍以下。” 为了消除需要回流内容后，剩下的页面加载，图像取代最初与的占位符<IMG>标签指定了正确的高度和宽度。

易于实施：适当。一些很好的JavaScript库，可用于12倍低于懒图像加载。

延迟加载和执行脚本

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

推迟的脚本可能是你自己的，往往更重要的是，从第三方的脚本。优化不良广告，社交媒体的小部件，或分析支持的脚本可以阻止网页渲染，有时还加入了宝贵秒加载时间。此外，请仔细评估使用大型脚本框架，如jQuery移动网站，特别是如果你使用的是一对夫妇只对象的框架。

易于实施：适当。现在，许多第三方框架提供了他们的API的递延或异步版本。开发商只是切换到这些新版本。推迟可能会更复杂一些JavaScript onload事件后运行脚本（例如，你会怎么做，如果你有一个脚本，要附加到的onload事件？如果推迟，直到onload事件后的注意事项有很多，它已经错过了的机会）。

使用AJAX的逐步增强

AJAX（异步JavaScript和XML）是一种技术，使用的XHR（XMLHttpRequest的）的对象，从一个Web服务器取数据，而无需刷新页面的代码运行。AJAX使更新的数据在一节一个页面一个页面来显示，而不重建整个页面。这通常是用来响应用户交互，但它也可以使你的应用程序来加载一个页面快速裸机版本，然后填写更详细的内容，而用户已经观看的页面。

尽管名称，XMLHttpRequest的不配合你只使用XML。您可以拨打其与JSON而不是XML overrideMimeType “应用程序/ json”和工作方法来指定。使用JSON.parse是快速和更安全的两倍，比使用通用的eval（）函数。

此外，请记住AJAX响应将受益于很多相同的优化技术建议标准响应。可以肯定的缓存头，微小，gzip压缩的，资源整合，等你的AJAX响应。

易于实施：很难量化，因为这个技术是非常特定应用。由于跨域问题，你会需要使用XHR2，以及控制外部域进行跨域XHR请求。

适应网络连接

特别是随着移动网络可能会收取额外使用更多的带宽，某些技术应该被使用，只有当代码来检测连接的类型相结合。例如，预加载资源预期将来的请求通常是智能的，但它可能不是一个负责任的策略，如果用户的带宽计量那些资源中的一些可能永远不会被需要。

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

易于实施：先进。网络信息API最近发生了变化，11而不是定义如Wi-Fi，3G等网络，它现在给的带宽的信息，如“非常慢，慢，快，非常快的建议值。 “ 这里有一个属性，试图告诉估计MB / s的，和一个布尔“咪表”的测量，它是正确的，但浏览器来确定，这是非常困难的。测量的地方，并适应可能是最好的主意，但仍然是相当具有挑战性的。

使用HTML5的WEB工人规格的多线程

在HTML5规范的Web工作者引入了多线程的并发执行JavaScript编程世界。此外，这个特殊的实现多线程消除了一直困扰的问题，与其他平台具体地说，发生的问题，当一个线程也被使用，另一个线程修改资源上的多个线程的开发工作。在Web工作代码，生成的线程不能访问的主要用户界面（UI）线程的资源。

为了提高移动站点的性能，Web工作者代码可以是有价值的资源预压，用户可能需要完成未来的行动，特别是当用户的带宽计量。随着移动设备的处理器能力有限，大量的预压可以干扰在当前页面中的UI响应。使用多线程的代码，采用Web工作对象（和可能的localStorage来缓存数据），预紧力资源的操作，可以在一个单独的线程中执行，而不影响当前的UI性能。

请注意，的Web工人规格，同时实现在Android 2.0以来，不支持，直到iOS 5的iPhone上。在桌面上，IE浏览器是落后的，增加10只在IE Web工作的支持。

易于实施：适当。虽然这项技术是不是非常难以实现，网络工作者有一些限制，使他们很难找到的地方。他们没有访问页面的DOM，并不能修改任何页面上。这种做法的工作需要一种非常特殊的后台计算或过程，非常适合作为背景的Web工作者。

更换点击触摸事件的事件

在触摸屏设备上，在onclick事件不立即开火，当用户点击屏幕。相反，设备最多等待半秒（300毫秒在大多数设备上），让用户有机会启动一些其他的手势，而不是点击。然而，这种延迟，可以显着阻碍用户期望的响应性能。为了解决这个问题，使用touchEnd事件。这一事件立即触发的，当用户点击屏幕。

为了确保用户不会遇到意外的行为，你可能也想使用的的touchstart和touchmove事件。例如，不要以为，touchend一个按钮意味着点击除非也有一个touchstart事件的按钮，而不是如果用户触摸别处，并拖累结束前触摸按钮。touchstart后预防治疗点击以下touchend，假设移动手势的目的不是为了成为一个点击，你可以使用一个touchmove事件。

此外，您可能还是要处理的onclick事件，以确保浏览器改变了外观的按钮，点击状态显示，并支持浏览器不处理触摸事件。为了避免重复的代码执行时，touchend和火的onclick代码，添加一个click事件处理程序调用的preventDefault和stopPropagation如果点击touchend已经处理用户抽头的结果。

易于实施：先进。这种技术需要做更多的工作页面上的链接添加和维护。对可能发生的事情，而不是一上一下，如缩放或轻扫的手势，触摸事件的代码测试必须是有弹性。

支持SPDY协议

有些折磨网站的性能瓶颈，无论是台式机或移动，结果在应用层的HTTP和HTTPS协议的低效率。在2009年，谷歌开始工作名为SPDY（发音为“迅速”），解决了一些这些限制的替代协议。我们的目标是使这是一个开源项目，将实施多个浏览器和Web服务器，但最初只支持谷歌的Chrome浏览器（版本10或更高版本）和谷歌网站上。由于Web服务器被释放，实现SPDY，网站将能够使用此协议的任何用户的浏览器支持。在测试执行一组有代表性的前100名互联网网站25 SPDY，谷歌观察速度的提高，从27％至60％不等。

SPDY自动使用gzip压缩的所有内容，并与HTTP不同，它也使用gzip的头数据。SPDY采用复用的技术，使在一个TCP连接发送多个数据流请求或响应。此外，SPDY允许请求的优先次序，所以，例如，一个视频，是中央的页面的内容可以被给予更高的优先级比在广告中显示的边缘。

SPDY最革命性创新可能的是，数据流可以是双向的，不论是由客户机或服务器可以启动，允许推到客户端的内容，而不用首先被请求的。例如，当用户第一次访问一个网站，并因此不尚未有任何缓存的内容的网站上，该服务器可以将响应第一个页面请求，而不是等待要单独提出的每个资源的所有必需的资源。作为一种替代方法，则服务器可以向客户端发送的提示，提示，将需要的资源，但仍然允许在客户端发起的请求。这仍然是速度不是等待客户端来解析在网站页面上，并发现自身的资源需求。

虽然SPDY是不特定的移动平台，通过移动网络的可用带宽有限意味着SPDY优化移动网站支持时，在降低延迟将是特别有用的。

实施的难易程度：中度到重度，取决于在网站上和服务器环境。谷歌已经为Apache 2.2- mod_spdy提供免费的SPDY模块，然而，mod_spdy线程模型问题，并没有发挥好mod_php，并且默认情况下，所以这需要额外的注意，以确保其正常运行您的网站。

不要忘了测试！

提醒人们，连续和仔细的测试是必不可少的，没有讨论将是不完整的性能优化。每次改变，你的系统仅仅是一个理论，直到它的测试是针对一个基线。猜测出现性能瓶颈的地方是没有意义的，除非根据实际测试数据。

伟大的开源和商业工具可以提供综合测试，完整的地理分布和带宽/延迟节流。此外，朗姆酒（真实用户监测）工具测试实验室，进入不可预测的用户行为的领域。

支持移动，以及桌面场景的测试选项。如果您选择的自动化解决方案，一定要选择一个不断测试和完善它适用的优化。

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

参考文献

1。2009年，L.布斯托斯。分秒必争;网站性能如何影响购物者的行为。GetElastic;http://www.getelastic.com/performance/的。

2。铬项目。SPDY：更快的网络; https://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper一个试验性协议。

3。动态，T. 2013。案例分析：如何有效的CDN移动游客。Web性能

4。菲奥拉万蒂，R. 2011。快速创建移动Web应用程序的按钮。谷歌开发http://code.google.com/mobile/articles/fast_buttons.html。

5。2006年，G.林登。在Web 2.0玛丽莎梅耶。Geeking与格雷格http://glinden.blogspot.com/2006/11/marissa-mayer-at-Web-20.html的。

6。国防部SPDY http://code.google.com/p/mod-spdy/的。

7。PhoCusWright的。2010。PhoCusWright的旅游网站/ Akamai的研究

8。RADWARE。2011年 从移动前沿案例研究：更快的移动网站和业务KPI之间的关系;的http://www.strangeloopnetworks.com/resources/research/state-of-mobile-ecommerce-performance/。

9。比克斯比，J. 2012。2012年国家移动电子商务

10。TEALEAF。2011年 在移动客户体验报告。根据哈里斯互动2011年移动交易调查。

11。W3C。2012年 网络信息的API; http://www.w3.org/TR/netinfo-api/。

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