移动网站性能优化：网页加载技术概览

性能一直是网站成功的关键。愈来愈多的研究已经证实，无论是小型电商，仍是像沃尔玛那样的连锁店，即便是页面加载时间方面的细微改善，均可以带来更多的业务，更多的广告收入，更多的用户粘性和更多的客户满意度。

在过去几年，Web开发者都是基于改善硬件或者提升带宽速度来优化用户体验。可是最近几年，爆炸式的移动Web浏览器的使用打破了这个途径。低带宽，高延迟，小内存，低处理器性能的移动设备环境，迫使开发者不得不想办法经过优化前端页面的性能来知足用户的性能预期。

在强调如何解决移动端性能问题上，这篇文章总结了一些前端优化的案例，而且归纳了一些加速页面的方法和策略。

 

为何性能会影响这么多

不论你的页面设计地多么有趣、漂亮、交互性好，无论是在桌面仍是移动设备上，若是页面须要花2到3秒时间去渲染展现，那么用户都会很快变得不耐烦的。能够预期的是，在页面还在加载的时候，用户颇有可能从浏览购买的行为转变为点击回退键或者是关闭浏览器的行为。

不到1秒钟的延迟甚至也会显著地影响收入。在2006年，当时还在Google工做的Marissa Mayer说，因为用户表示但愿在一个搜索页上看到多于10个搜索结果，Google就实验性地修改成30个。可是让人吃惊的是，在这个实验里，流量和投 资都减小了20个百分点，显然是因为更多的搜索结果致使多花费了半秒时间来加载页面。^5

用户的指望老是在不断的提高。2009年，Forrester研究所的Akamai的一项研究发现代表，网页响应时间可容忍的阀值是2秒，一旦网页 相应时间超过3秒，会有40%的用户放弃浏览页面。一年以后，Akamai的另外一项研究代表，超过3秒放弃浏览页面的用户比例上升到了57%。^1,7

此外，移动端的用户但愿移动设备上的页面性能不亚于桌面PC。由Tealeaf科技（如今已经并入IBM）委托的“Harris的互动2011移动 交互调查”显示，在前一年有过移动消费经历的成年人中，有85%但愿移动设备上的体验能与手提电脑或者PC上的体验至关，甚至于更好。而且有63%的人表 示，一旦他在移动设备上的交易遇到了一个问题，他们就不会再想经过其余渠道去购买这个公司的其余产品了。^10换句话说，差劲的移动页面性能会影响到公司 其余各类平台的销售，这其中固然也包括线下的实体店。

移动流量正在迅速增加。对许多消费者而言，他们的手机或者平板设备已经成为他们浏览网络的主要入口了，可是其性能表现却差强人意。2011年2 月，Compuware公司委托Equation 研究所作的一项研究代表，几乎一半的移动用户（46%）表示他们手机上的网站加载速度过慢。60%的用户但愿页面能在3秒或者更少的时间内加载完 成，74%的用户表示，当单个页面加载时间花费5秒或者更多的时候，他们会选择离开这个页面。在2012年，由Strangeloop网络（现已并入 Redware）发起的一项针对200家领先的电子商务网站研究代表，3G网络环境下，平均加载时间为11.8秒（图1），而在LTE（4G）环境下，加 载时间只有轻微的改善，为8.5秒。^8

 

移动设备表现性能的三种影响因素

正如上文所说的，移动设备天生有下面三种性能限制：带宽低，内存小，处理器性能低。这些性能挑战又加上一些其余的问题，例如：

网页比之前更大。根据HTTP Archive网站的分析，如今平均的一个web页面须要加载超过1MB的数据，其中包含有图片，Javascript，CSS（Cascading Style Sheets）等。更大的网页会影响桌面PC的显示性能。对于移动端的性能 — 特别是3G环境下的性能 — 影响更严重。这个影响会在从此的三年更加明显。以如今的页面增加速度来讲，到2015年，平均的页面大小会达到2MB。

延迟相差巨大。对LTE来讲，延迟大概有34ms，对3G来讲，延迟大概有350毫秒甚至更多。移动端的延迟性 惟一不变的就是延迟时间永远是不定的，即便是在同一个地点，每次的延迟都是不定的。这是因为大量的数据是经过信息塔进行传输的。所以诸如天气，甚至是持有 者所面向的方向都有可能成为影响因素。

下载速度相差巨大。下载速度的范围从3G环境下的1Mbps到LTE环境下的31Mbps。把这个和美国平均的带宽15Mbps相比是一个颇有意思的事情，3G环境比平均带宽慢了15倍，而LTE却能达到平均带宽的2倍那么快。

 

M.SITES并不能彻底解决移动端性能的问题。

许多网站建设者尝试针对多用户访问，大网页和低流量链接的访问页面，开发出短小，快速，精简的m.sites；可是，这些尝试并无什么用，当用户有选择权的时候，高达35%的移动用户会选择浏览完整的网站。

这些选择浏览完整网站的用户显然比浏览m.sites的用户更有购买欲望。一个研究代表，移动端每$7.00的消费中，有$5.50是来自于网站的网站浏览，只有$1.00是来自于m.sites，剩下的$0.50则是来自于客户端。^9

 

解决问题

改善网站性能的主要策略并无由于从PC变成手机或者平板设备而有变化，只是会参杂一些小的策略。

不论在PC仍是在移动浏览器上，页面展现须要的时间里，只有20%是用来读取页面的HTML的。剩下的80%是用来加载额外的像样式表、脚本文件、或者图片这样的资源和执行客户端的程序。

三个主要的改善性能的策略是：

• 减小每一个页面须要获取额外资源的HTTP请求数
• 减小每一个请求加载的大小
• 优化客户端执行的优先级和脚本执行的效率

 

因为移动网络一般比桌面机器的网络慢，因此减小请求数和请求加载量是很是重要的。因为移动端的浏览器解析HTML和执行JavaScript的效率 比桌面PC低，因此优化客户端程序也是很是关键的。另外，移动端浏览器的缓存大小比桌面PC低，因此须要有方法能重复利用本地的缓存资源。

文章剩余部分总结了能解决这些问题的方法。虽然这些方法大均可以自动化解决，固然也能够由有经验的前端工程师来手动解决。关键就是要知道人工解决这 些技术的方法如何控制资源的请求。一般在CMS（内容管理系统）或者其余Web应用中，有些页面包含一些自动生成好的或者离线的HTML片断、CSS或者 Javascript文件，这样的页面开发者就不须要去优化它们了。

 

减小请求

最大的性能漏洞就是一个页面须要发起几十个网络请求来获取诸如样式表、脚本或者图片这样的资源。这个在相对低带宽和高延迟的移动设备链接上来讲影响 更严重。CDNs（内容分发网络）把资源放在离用户地理位置更近的地方对解决这个问题能起到很大做用，可是比起获取请求，大量的请求对页面加载时间的影响 更为严重。并且最近的发现代表，CDNs对移动端用户的性能影响愈来愈低。

下面的章节讨论了简化HTTP请求的几种方法。

 

整合资源

对开发者来讲，将Javascript代码和CSS样式放到公共的文件中供多个页面共享是一种标准的优化方法。这个方法能很简单的维护代码，而且提升客户端缓存的使用效率。

在Javascript文件中，要确保在一个页面中相同的脚本不会被加载屡次。当大团队或者多个团队合做开发的时候，这种冗余的脚本就很容易出现。你可能会对它的发生频率并不低感到很是吃惊。

Sprites是css中处理图片的一项技术。Sprites就是将多张图片整合到一个线性的网状的大图片中。页面就能够将这个大图片一次性获取回 来而且作为css的背景图，而后使用css的背景定位属性展现页面须要的图片部分。这种技术将多个请求整合成一个，能显著地改善性能。

实现小贴士：平稳地改进可是须要对资源有控制权限。根据开发者的网站不一样权限，一些资源并不须要被整合起来（例如，一些由CMS生成的资源）。还 有，对于一些外部域引用的资源，强行整合可能会致使问题。须要注意的是，整合资源对手机浏览器来讲是一把双刃剑。整合资源确实会在首次访问减小请求，可是 大的资源文件可能会致使缓存失效，因此，须要当心地使用各类技术整合资源，以达到优化本地存储的目的。

 

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

如今全部的浏览器都会使用本地资源去缓存住那些被Cache-Control或者Expires头标记的资源，这些头能标记资源须要缓存的时间。另 外，ETag（实体标签）和Last-Modified头来标识当资源过时后是否须要从新请求。浏览器为了减小没必要要的服务器请求，尽量地从本地缓存中 获取资源，而且将那些已通过期的、或者当缓存空间减少的时候将那些好久不用的资源进行清理。浏览器缓存一般包括图片，CSS，Javascript代码， 这些缓存能合理地提升网站的性能。（好比为了支持后退和前进的按钮，使用一个单独的缓存来保存整个渲染的页面）。

移动浏览器缓存，一般是比桌面PC小的多，这就致使了缓存的数据会很常常被清理。HTML5的缓存基于浏览器缓存提供了一个很好的替换方案。 Javascript的localStorage已经在全部主流的桌面和移动端浏览器上都实现了。使用脚本代码能简便地支持HTML5的 localStorage操做，能够读写键值数据，每一个域名大概有5MB的容量。虽然不一样的移动浏览器上读写速度相差很大，可是localStorage 大容量的缓存使得它很适合做为客户端的缓存。从localStorage获取资源明显快于从服务器上获取资源，并且在大多数移动设备上也比依靠缓存头或者 浏览器的本地缓存更灵活可靠。这是移动浏览器比桌面PC更有优点的一个地方，在桌面PC上，本地缓存仍然优先使用标准的浏览器缓存，致使桌面PC本地缓存 的性能落后于移动浏览器。

实现小贴士：须要进一步考虑。虽然localStorage的机制易于实现，可是它的一些控制机制倒是很是复杂的。你须要考虑到缓存带给你的全部问题，好比缓存失效（何时须要删除缓存？），缓存丢失（当你但愿数据在缓存中的时候它并不在怎么办？），还有当缓存满的时候你怎么办？

 

首次使用的时候在HTML中嵌入资源

HTML的标准是使用连接来加载外部资源。这使得更容易在服务器上（或者在CDN上）操做更新这些资源，而不是在每一个页面上修改更新这些资源。根据上文讨论的，这种模式也使得浏览器能从本地缓存而不是服务器上获取资源。

可是对尚未缓存到浏览器localStorage的资源来讲，这种模式对网站的性能有负面的影响。通常来讲，一个页面须要几十个单独的请求来获取 资源从而渲染页面。因此说，从性能的角度来讲，若是一个资源没有很高的被缓存的概率的话，最好把它嵌入到页面的HTML中（叫inlining），而不是 使用连接外部。脚本和样式是支持内嵌到HTML中的，可是图片和其余的二进制资源其实也是能够经过内嵌包含base64编码的文原本嵌入到HTML中的。

内嵌的缺点是页面的大小会变得很是大，因此对于Web应用来讲，关键的是可以跟踪分析这个资源何时须要从服务端获取，何时已经缓存到客户端 了。另外，在第一次请求资源后必须可以使用代码在客户端缓存资源，所以，在移动设备上，使用HTML5 localStorage能很好地作到内嵌。

实现小贴士：平稳处理。因为不知道用户是否已经访问过这个页面了，因此须要网站有机制能生成不一样版本的页面。

 

使用HTML5服务端发送事件

Web应用已经使用了各类从服务器上轮询资源的方法来持续地更新页面。HTML5的EventSource对象和Server-Sent事件能经过 浏览器端的JavaScript代码打开一个服务端链接客户端的单向通道。服务端可使用这个写通道来发送数据，这样能节省了HTTP建立多个轮询请求的 消耗。这种方式比HTML的WebSocket更高效。WebSocket的使用场景是，当有许多客户端和服务端的交互的时候（好比消息或者游戏），在全 双工链接上创建一个双向通道。

实现小贴士：须要进一步考虑。这个技术是基于具体的技术实现的。若是你的网站当前是使用其余的Ajax或者Comet技术来轮询的，转变成Server-Sent 事件须要重构网站的Javascript代码。

 

消除重定向

当用户在一个移动设备上访问桌面PC网站的时候，Web网站应用一般读取HTTP的user-agent头来判断这个用户是不是来自移动设备的。然 后应用会发送带有空HTTP body和重定向HTTP地址头的HTTP 301（或者302）请求，把用户重定向到网站的移动版本上去。可是，这个额外的客户端和服务端的交互一般在移动网络上会消耗几百毫秒。所以，在原先的请 求上传递移动的web页会比传递一个重定向的信息并让客户端再请求移动页面更快。

对于那些想要在移动设备上看桌面PC网站的用户来讲，你能够在移动web页面上提供一个连接入口，这样也能同时表示你的网站是并不提倡这种行为的。

实现小贴士：虽然这个技术在理论上是简单的，可是实际上并不易于实施。因为有些m.sites是宿主在其余地方 的，因此许多网站会选择重定向到一个不一样的服务器上。有的网站则是会在重定向请求的时候种植上Cookie告诉Web应用这个用户是在使用移动设备。这种 方法可能对web应用来讲更容易控制。

 

减小资源负载

大小问题。渲染小页面更快，获取小资源也更快。减少每一个请求的大小一般不如减小页面请求个数那么显著地提升性能。可是，有些技术在性能方面，特别是在须要对带宽和处理器性能精打细算的移动设备环境下，仍然是能带来很大利益的。

 

压缩文本和图像

诸如gzip这样的压缩技术，依靠增长服务端压缩和浏览器解压的步骤，来减小资源的负载。可是，通常来讲，这些操做都是被高度优化过了。并且测试表 明，压缩对网站仍是起到优化性能的做用的。那些基于文本的响应，包括HTML，XML，JSON（Javascript Object Notation），Javascript，和CSS能够减小大约70%的大小。

浏览器在Accept-Encoding请求头中申明它的解压缩技术，而且当它们接收到服务端返回的Content-Encoding响应头标示的时候，就会按照这个响应头自动作解压操做。

实现小贴士：易于实现。若是设置正确的话，如今全部的Web服务器都支持压缩响应。可是，也有一些桌面PC的安全工具会将请求头中的Accept-Encoding头去掉，这样即便浏览器支持解压缩，用户也没法获取到压缩后的响应。

 

代码简化

简化一般是使用在脚本和样式文件中，删除一些没必要要的字符，好比空格，换行符，或者注释等。不须要暴露给外部的命名就能够被缩短为一个或者两个字 符，好比变量名。合适的简化资源一般在客户端不须要作任何其余的处理，而且平均减小20%的资源大小。内嵌在HTML中的脚本和样式文件也是能够精简的。 有不少很好的库来作精简化的操做，这些库通常也同时会提供合并多个文件这样减小请求数的服务。

简化带来的好处并不局限于减小带宽和延迟，对于那些移动设备上缓存没法保存的过大资源来讲，也是颇有改善的。Gzip在这个方面并无任何帮助，由于资源是在被解压后才被缓存起来的。

实现小贴士：易于实现。Google的Closure Compiler已经难以置信地完成了理解和简化Javascript的工做。可是CSS的简化则没有那么容易，由于对不一样浏览器来讲有不一样的CSS技术 能迷惑CSS简化工具，而后让CSS简化后没法正常工做。必需要注意的是，已经有这样的案例了，即便只是删除了没必要要的字符，简化工做也有可能破坏页面。 因此当你应用简化技术以后，请作一下完整的功能测试工做。

 

调整图片大小

图片一般是占用了Web页面加载的大部分网络资源，也占用了页面缓存的主要空间。小屏幕的移动设备提供了经过调整图片大小来加速传输和渲染图片资源的机会。若是用户只是在小的移动浏览器窗口中看图片的话，高分辨率的图片就会浪费带宽、处理时间和缓存空间。

为了加速页面渲染速度和减小带宽及内存消耗，能够动态地调整图片大小或者将图片替换为移动设备专用的更小的版本。不要依靠浏览器来将高分辨率的图片转换成小尺寸的图片，这样会浪费带宽。

另一个方法是先尽快加载一个低分辨率的图片来渲染页面，在onload或者用户已经开始和页面交互之后将这些低分辨率的图片替换成为高分辨率的图片。

实现小贴士：特别应用在高度动态化的网站是有优点的。

 

使用HTML5和CSS 3.0来简化页面

HTML5包括了一些新的结构元素，例如header，nav，article和footer。使用这些语义化的元素比传统的使用div和span 标签能使得页面更简单和更容易解析。一个简单的页面更小加载更快，而且简单的DOM（Document Object Model）表明着更快的JavaScript执行效率。新的标签能很快地应用在包括移动端的新浏览器版本上，而且HTML5设计让那些不支持它的浏览器 能平稳过渡使用新标签。

HTML5的一些表单元素提供了许多新属性来完成本来须要javascript来完成的功能。例如，新的placeholder属性用于显示在用户输入进入输入框以前显示的介绍性文字，autofocus属性用于标示哪一个输入框应当被自动定位。

也有一些新的输入框元素能不用依靠Javascript就能够完成一些通用的需求。这些新的输入框类型包括像e-mail，URL，数字，范围，日 期和时间这样须要复杂的用户交互和输入验证的元素。在移动浏览器上，当须要输入文本的时候，弹出的键盘一般是由特定的输入框类型来作选择的。不支持指定的 输入类型的浏览器就会只显示一个文本框。

另外，只要浏览器支持内建的层次，圆角，阴影，动画，过渡和其余的图片效果，CSS 3.0就能帮助你建立轻便简易的页面了，而这些图片效果原先是须要加载图片才能完成的。这样，这些新特性就能加速页面渲染了。

有不少Web站点都提供哪些移动或者桌面浏览器支持哪项性能的更新说明。（例如：http://caniuse.com/ 和 mobilehtml5.org）。

实现小贴士：须要进一步考虑。人工地作这些改动是很是复杂和耗时的。若是你使用CMS，它能够帮你生成许多你不须要控制的HTML和CSS。

 

优化客户端的程序处理

浏览器按照什么顺序来执行代码生成一个页面，和页面复杂性及JavaScript的技术选择，都对性能有很大的影响。特别在客户端相对较慢的CPUs和少内存的移动端中尤其明显。下面的章节提供一些策略来提高页面处理的性能。

 

延迟渲染”BELOW-THE-FOLD”内容

能够肯定的是若是咱们将不可见区域的内容延迟加载，那么页面就会更快地展示在用户面前，这个区域叫作”below the fold”。为了减小页面加载后须要从新访问的内容，能够将图片替换为正确的高宽所标记的<img>标签。

实现小贴士：平稳处理。一些好的Javascript库能够用来处理这些below-the-fold 延迟加载的图像。^12

 

延迟读取和执行的脚本

在一些移动设备上，解析Javascript代码的速度能达到100毫秒每千字节。许多脚本的库直到页面被渲染之后都是不须要的加载的。下载和解析 这些脚本能够很安全地被推迟到onload事件以后来作。例如，一些须要用户交互的行为，好比托和拽，都不大可能在用户看到页面以前被调用。相同的逻辑也 能够应用在脚本执行上面。尽可能将脚本的执行延迟到onload事件以后，而不是在初始化页面中重要的可被用户看到的内容的时候执行。

这些延迟的脚本多是你本身写的，更重要的是，也有多是第三方的。对广告、社交媒体部件、或者分析的差劲的脚本优化会致使阻塞页面的渲染，会增长 珍贵的加载时间。固然，你须要当心地评估诸如jquery这样为移动网站设计的大型脚本框架，特别当你仅仅只是使用这些框架中的一些对象的时候更要当心评 估。

实现小贴士：平稳处理。许多第三方的框架如今提供延迟加载的异步版本的API。开发者只须要将原先的逻辑转化到 这个异步版本。一些JavaScript要作延迟加载会有些复杂，由于在onload以后执行这些脚本须要注意不少注意事项。（例如，你有个脚本须要绑定 到onload事件上，你须要作什么？若是你将脚本延迟到onload事件以后，就必定就会失去不少执行的时机。）

 

使用Ajax来加强进程

Ajax（Asynchronous JavaScript and XML）是一项使用XHR（XMLHttpRequest）对象来从Web服务器上获取数据的技术，它并不须要更新正在运行的页面。Ajax能更新页面上 的某个部分而不须要从新构建整个页面。它一般用来提交用户的交互相应，可是也能够用来先加载页面的框架部分，而后当用户准备好浏览网页的时候再填充详细的 内容。

尽管是这个名字，可是XMLHttpRequest并不强制要求你只能使用XML。你能够经过调用overrideMineType方法来制 定”application/json”类型来使用json替换XML。使用JSON.parse会比使用原生的eval()函数快了几乎两倍，而且更为 安全。

同时，切记Ajax的返回响应也会得益于那些应用在普通的返回响应的优化技术上面。确保对你的Ajax返回响应使用了缓存头，简化，gzip压缩，资源合并等技术。

实现小贴士：因为这个技术是根据具体应用不一样而不一样的，因此很难量化。或许因为跨域问题，你须要使用XHR2，这个技术能使用外部域的资源，从而能进行跨域的XHR请求。

 

根据网络情况进行适配处理

因为使用更多带宽会使用更多移动网络的费用，因此只有能检测网络的类型才能使用针对特定网络的优化技术。例如，预加载将来使用到的请求是很是聪明的作法，可是若是用户的带宽很稀有，而且加载的有些资源是永远不会用到的话，这个技术就是不合理的了。

在Android 2.2+，navigator.connection.type属性的返回值能让你区分Wifi和2G/3G/4G网络。在Blackberry 上，blackberry.network也能提供类似的信息。另外，服务端经过检测请求中的User-Agent头或者其余的嵌入到请求中的信息能让你 的应用检测到网络情况。

实现小贴士：须要进一步考虑。检测网络信息的API最近已经有所变化了。^11 接口如今不是直接定义Wi-Fi，3G等网络情况，而是给出了带宽信息和诸如“很是慢，慢，快和很是快”这样的建议。有个属性能给出估计的MB/s值和一 个“meterd”的Boolean值来表示它的可信度，可是对浏览器来讲，很难根据这个来判断环境。判断当前网络环境而后适配仍然是一种最好的方法，但 是这种方法正在被考虑被替换。

 

对多线程来讲尽可能使用HTML5的WEB WORKER特性

HTML5中的Web Worker是使用多个线程并发执行Javascript程序。另外，这种特别的多线程实现能减小困惑开发者多年的，在其余平台上遇到的问题。例如，当一 个线程须要改变一个正在被其余线程使用的资源该如何处理。在Web Worker中，子线程不能修改主用户界面（UI）线程使用的资源。

对提升移动站点的性能来讲，Web Worker中的代码很适合用来预处理用户完成进一步操做所须要的资源的，特别是在用户的带宽资源不紧缺的状况下。在低处理器性能的移动设备上，过多的预 加载可能会干扰当前页面的UI响应。使用多线程代码，让Web Worker对象（而且尽量使用localStorage来缓存数据）在另一个线程中操做预加载资源，这样就能不影响当前的UI表现了。

要特别说明的是，Web Worker只在Android 2.0以上的版本实现，并且iphone上的ios5以前的版本也不支持。在桌面PC上，老是落后的IE只在IE 10才支持Web Worker。

实现小贴士：平稳过渡。虽然这项技术并非很是难实现，可是对Web Workers来讲，有一些限制须要强制遵照。Web Workers不能进入到页面的DOM，也不能改变页面上的任何东西。Web Worker很适合那种须要后台计算和处理的工做。

 

将CLICK事件替换成TOUCH事件

在触摸屏设备上，当一个用户触碰屏幕的时候，onclick事件并无当即触发。设备会使用大约半秒（大多数设备差很少都是300毫秒）来让用户确 定是手势操做仍是点击操做。这个延迟会很明显地影响用户指望的响应性能。要使用touchend事件来替换才能解决。当用户触碰屏幕的时候，这个事件会立 即触发。

为了要确保不会产生用户不指望的行为，你应该也要使用touchstart和touchmove事件。例如，除非同时有个touchstart事件 在button上，不然不要判断touchend事件在button上就意味着点击行为 — 由于用户有可能从其余地方触碰开始，而后拖拽到button上触碰结束的。你也能够在touchstart事件以后使用touchmove事件来避免将 touchend事件误判为点击，固然前提是须要假设拖拽的手势并非预期产生点击行为。

另外，你也须要去处理onclick事件来让浏览器改变button的外观从而标识为已点击的状态，同时你也须要处理那些不支持touch事件的浏 览器。为了不代码在touchend和onclick代码中重复执行，你须要在确保用户触碰事件已经在touchend执行了以后，在click事件中 调用preventDefault和stopPropagation方法。^4

实现小贴士：须要进一步考虑。这种技术须要更多工做才能在一个页面中增长和维护连接。touch事件的代码必须考虑其余手势，由于替换click的还有多是缩放或者敲击动做。

 

支持SPDY协议

应用层HTTP和HTTPS协议致使的一些性能瓶颈，使得不管是桌面仍是移动端的网站都很是难受。在2009年，谷歌开始研发一种叫作SPDY（谐 意是”speedy”）的协议来替换已有的协议，这种协议宣称能突破这些限制。这个协议的目标是让多种浏览器和多种Web服务都能支持，因此这个协议是开 源的，可是初步地，只有Google的Chrome浏览器（在版本10及以后的）和google的站点支持。一旦一个Web服务支持SPDY，那么它上面 的全部站点均可以和支持这个协议的浏览器使用SPDY进行交互。将SPDY应用在25个top100的Internet网站上，Google收集到的数据 是网站的速度会改善27%到60%不等。^2

SPDY自动使用gzip压缩全部内容，和HTTP不一样的是，它连header的数据也使用gzip压缩。SPDY使用多线程技术让多个请求流或者响应流能共用一个TCP链接。另外SPDY容许请求设置优先级，好比，页面中心的视频会比边框的广告拥有更高的优先级。

或许SPDY中最变革性的发明就是流是双向的，而且能够由客户端或者服务端发起，这样能使得信息能推送到客户端，而不用由客户端发起第一次请求。例 如，当一个用户第一次浏览一个站点，尚未任何站点的缓存，这个时候服务端就能够在响应中推送全部的请求资源，而不用等候每一个资源被再次独立请求了。做为 替换协议，服务端能够发送暗示给客户端，提示页面须要哪些资源，同时也容许由客户端来初始化请求。即便是使用后一种这样的方式也比让客户端解析页面而后自 己发现有哪些资源须要被请求来得快。

虽然SPDY并无对移动端有什么特别的设置，可是移动端有限的带宽就使得若是支持SPDY的话，SPDY在减小移动网站的延迟是很是有用的。

实现小贴士：依据网站和服务的环境来进行平稳操做或进一步考虑。Google有一个SPDY模块支持 Apache2.2 – mod_spdy – 这个模块是免费的；可是mod_spy有线程上的问题，而且和mod_php协做并非很好，因此要求你使用这个技术的时候要确保你的网站的正常运行。 ^6

 

永远别忘记测试！

若是缺乏了持续和仔细的测试提醒，性能的优化就只是讨论而已，是没法完成的。若是没有指定基准作比较，你系统上的任何改动都仅仅是理论而已。若是没有真实的测试数据，猜想性能的瓶颈是毫无心义的。

有不少开源和通用的工具能进行集成测试，而且能进行不一样地域和带宽/延迟的测试。另外，RUM（real user monitoring）工具能将测试环境从实验室变成不可预测的真实用户行为。

观察移动设备的测试选择和桌面场景同样。若是你在选择一个自动化的解决方案，请确保使用一个能持续测试，而且能区分出应用优化方法先后的变化的解决方案。

若是性能优化若是只是在发展过程当中的一个步骤而已，它不会有什么效果的。它必须成为一个持续改善网站的一部分。

 

参考：

1. Bustos, L. 2009. Every second counts; how website performance impacts shopper behavior. GetElastic;http://www.getelastic.com/performance/.

2. Chromium Projects. SPDY: an experimental protocol for a faster Web;https://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper.

3. Everts, T. 2013. Case study: how effective are CDNs for mobile visitors. Web Performance Today;http://www.Webperformancetoday.com/2013/05/09/case-study-cdn-content-delivery-network-mobile-3g/.

4. Fioravanti, R. 2011. Creating fast buttons for mobile Web applications. Google Developers;http://code.google.com/mobile/articles/fast_buttons.html.

5. Linden, G. 2006. Marissa Mayer at 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 study on travel site performance;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. Case studies from the mobile frontier: the relationship between faster mobile sites and business KPIS; http://www.strangeloopnetworks.com/resources/research/state-of-mobile-ecommerce-performance/.

9. Bixby, J. 2012. 2012 state of mobile e-commerce performance;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. Report on the Mobile Customer Experience. Based on the Harris Interactive 2011 Mobile Transactions Survey.

11. W3C. 2012. Network Information API; http://www.w3.org/TR/netinfo-api/.

12. YUI. ImageLoader. Yahoo! User Interface Library; http://yuilibrary.com/yui/docs/imageloader/.