【感谢@jianfengye110 的热心翻译。如果其他朋友也有不错的原创或译文，可以尝试推荐给伯乐在线。】
性能一直是网站成功的关键。越来越多的研究已经证明，不管是小型电商，还是像沃尔玛那样的连锁店，即使是页面加载时间方面的细微改善，都可以带来更多的业务，更多的广告收入，更多的用户粘性和更多的客户满意度。
在过去几年，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/.
Google Dremel 原理 – 如何能3秒分析1PB
简介
Dremel 是Google 的“交互式”数据分析系统。可以组建成规模上千的集群，处理PB级别的数据。MapReduce处理一个数据，需要分钟级的时间。作为MapReduce的发起人，Google开发了Dremel将处理时间缩短到秒级，作为MapReduce的有力补充。Dremel作为Google BigQuery的report引擎，获得了很大的成功。最近Apache计划推出Dremel的开源实现Drill，将Dremel的技术又推到了浪尖上。
Google Dremel设计
根据Google公开的论文《Dremel: Interactive Analysis of WebScaleDatasets》可以看到Dremel的设计原理。还有一些测试报告。论文写于2006年，公开于2010年，Google在处理大数据方面，果真有得天独厚的优势。下面的内容，很大部分来自这篇论文。
随着Hadoop的流行，大规模的数据分析系统已经越来越普及。数据分析师需要一个能将数据“玩转”的交互式系统。如此，就可以非常方便快捷的浏览数据，建立分析模型。Dremel系统有下面几个主要的特点：
1, Dremel是一个大规模系统。在一个PB级别的数据集上面，将任务缩短到秒级，无疑需要大量的并发。磁盘的顺序读速度在100MB/S上下，那么在1S内处理1TB数据，意味着至少需要有1万个磁盘的并发读! Google一向是用廉价机器办大事的好手。但是机器越多，出问题概率越大，如此大的集群规模，需要有足够的容错考虑，保证整个分析的速度不被集群中的个别慢(坏)节点影响。
2, Dremel是MR交互式查询能力不足的补充。和MapReduce一样，Dremel也需要和数据运行在一起，将计算移动到数据上面。所以它需要GFS这样的文件系统作为存储层。在设计之初，Dremel并非是MapReduce的替代品，它只是可以执行非常快的分析，在使用的时候，常常用它来处理MapReduce的结果集或者用来建立分析原型。
3, Dremel的数据模型是嵌套(nested)的。互联网数据常常是非关系型的。Dremel还需要有一个灵活的数据模型，这个数据模型至关重要。Dremel支持一个嵌套(nested)的数据模型，类似于Json。而传统的关系模型，由于不可避免的有大量的Join操作，在处理如此大规模的数据的时候，往往是有心无力的。
4, Dremel中的数据是用列式存储的。使用列式存储，分析的时候，可以只扫描需要的那部分数据的时候，减少CPU和磁盘的访问量。同时列式存储是压缩友好的，使用压缩，可以综合CPU和磁盘，发挥最大的效能。对于关系型数据，如果使用列式存储，我们都很有经验。但是对于嵌套(nested)的结构，Dremel也可以用列存储，非常值得我们学习。
5, Dremel结合了Web搜索 和并行DBMS的技术。首先，他借鉴了Web搜索中的“查询树”的概念，将一个相对巨大复杂的查询，分割成较小较简单的查询。大事化小，小事化了，能并发的在大量节点上跑。其次，和并行DBMS类似，Dremel可以提供了一个SQL-like的接口，就像Hive和Pig那样。
Google Dremel应用场景
设想一个使用场景。我们的美女数据分析师，她有一个新的想法要验证。要验证她的想法，需要在一个上亿条数据上面，跑一个查询，看看结果和她的想法是不是一样，她可不希望等太长时间，最好几秒钟结果就出来。当然她的想法不一定完善，还需要不断调整语句。然后她验证了想法，发现了数据中的价值。最后，她可以将这个语句完善成一个长期运行的任务。
对于Google,数据一开始是放在GFS上的。可以通过MapReduce将数据导入到Dremel中去，在这些MapReduce中还可以做一些处理。然后分析师使用Dremel，轻松愉悦的分析数据，建立模型。最后可以编制成一个长期运行的MapReduce任务。
这种处理方式，让笔者联想到Greenplum的Chorus. Chorus也可以为分析师提供快速的数据查询，不过解决方案是通过预处理，导入部分数据，减少数据集的大小。用的是三十六计，走为上计，避开的瞬时分析大数据的难题。Chorus最近即将开源，可以关注下。
还有一点特别的就是按列存储的嵌套数据格式。如图所示，在按记录存储的模式中，一个记录的多列是连续的写在一起的。在按列存储中，可以将数据按列分开。也就是说，可以仅仅扫描A.B.C而不去读A.E或者A.B.C。难点在于，我们如何能同时高效地扫描若干列，并做一些分析。
Google Dremel数据模型
在Google, 用Protocol Buffer常常作为序列化的方案。其数据模型可以用数学方法严格的表示如下：
其中t可以是一个基本类型或者组合类型。其中基本类型可以是integer,float和string。组合类型可以是若干个基本类型拼凑。星号(*)指的是任何类型都可以重复，就是数组一样。问号(?)指的是任意类型都是可以是可选的。简单来说，除了没有Map外，和一个Json几乎没有区别。
下图是例子，Schema定义了一个组合类型Document.有一个必选列DocId，可选列Links，还有一个数组列Name。可以用Name.Language.Code来表示Code列。
这种数据格式是语言无关，平台无关的。可以使用Java来写MR程序来生成这个格式，然后用C++来读取。在这种列式存储中，能够快速通用处理也是非常的重要的。
上图，是一个示例数据的抽象的模型；下图是这份数据在Dremel实际的存储的格式。
如果是关系型数据，而不是嵌套的结构。存储的时候，我们可以将每一列的值直接排列下来，不用引入其他的概念，也不会丢失数据。对于嵌套的结构，我们还需要两个变量R (Repetition Level) ,D (Definition Level) 才能存储其完整的信息。
Repetition Level是记录该列的值是在哪一个级别上重复的。举个例子说明：对于Name.Language.Code 我们一共有三条非Null的记录。
1, 第一个是”en-us”，出现在第一个Name的第一个Lanuage的第一个Code里面。在此之前，这三个元素是没有重复过的，都是第一个。所以其R为0。
2, 第二个是”en”，出现在下一个Lanuage里面。也就是说Lanague是重复的元素。Name.Language.Code中Lanague排第二个，所以其R为2.
3,第三个是”en-gb”，出现在下一个Name中，Name是重复元素，排第一个，所以其R为1。
我们可以想象，将所有的没有值的列，设值为NULL。如果是数组列，我们也想象有一个NULL值。有了Repetition Level，我们就可以很好的用列表示嵌套的结构了。但是还有一点不足。就是还需要表示一个数组是不是我们想象出来的。
Definition Level 是定义的深度，用来记录该列是否是”想象”出来的。所以对于非NULL的记录，是没有意义的，其值必然为相同。同样举个例子。例如Name.Language.Country,
· 第一个”us”是在R1里面，其中Name,Language,Country是有定义的。所以D为3。
· 第二个”NULL”也是在R1的里面，其中Name,Language是有定义的,其他是想象的。所以D为2。
· 第三个”NULL”还是在R1的里面，其中Name是有定义的,其他是想象的。所以D为1。
· 第四个”gb”是在R1里面，其中Name,Language,Country是有定义的。所以D为3。
就是这样，如果路径中有required，可以将其减去，因为required必然会define，记录其数量没有意义。
理解了如何存储这种嵌套结构。写没有难度。读的时候，我们只读其中部分字段，来构建部分的数据模型。例如，只读取DocID和Name.Language.Country。我们可以同时扫描两个字段，先扫描DocID。记录下第一个，然后发现下一个DocID的R是0；于是该读Name.Language.Country，如果下一个R是1或者2就继续读，如果是0就开始读下一个DocID。
下图展示了一个更为复杂的读取的状态机示例。在读取过程中使用了Definition Level来快速Jump,提升性能。
到此为止，我们已经知道了Dremel的数据结构。就像其他数据分析系统一样，数据结构确定下来，功能就决定了一大半。对于Dremel的数据查询，必然是“全表扫描”，但由于其巧妙的列存储设计，良好的数据模型设计可以回避掉大部分Join需求和扫描最少的列。
Google Dremel查询方式
Dremel可以使用一种SQL-like的语法查询嵌套数据。由于Dremel的数据是只读的，并且会密集的发起多次类似的请求。所以可以保留上次请求的信息，还优化下次请求的explain过程。那又是如何explain的呢？
这是一个树状架构。当Client发其一个请求，根节点受到请求，根据metadata，将其分解到枝叶，直到到位于数据上面的叶子Server。他们扫描处理数据，又不断汇总到根节点。
举个例子：对于请求：
|
1
|
SELECT
A,
COUNT
(B)
FROM
T
GROUP
BY
A
|
根节点收到请求，会根据数据的分区请求，将请求变成可以拆分的样子。原来的请求会变为：
|
1
|
SELECT
A,
SUM
(c)
FROM
(R1
UNION
ALL
... Rn)
GROUP
BY
A
|
R1,…RN是T的分区计算出的结果集。越大的表有越多的分区，越多的分区可以越好的支持并发。
然后再将请求切分，发送到每个分区的叶子Server上面去,对于每个Server
|
1
|
Ri =
SELECT
A,
COUNT
(B)
AS
c
FROM
Ti
GROUP
BY
A
|
结构集一定会比原始数据小很多，处理起来也更快。根服务器可以很快的将数据汇总。具体的聚合方式，可以使用现有的并行数据库技术。
Dremel是一个多用户的系统。切割分配任务的时候，还需要考虑用户优先级和负载均衡。对于大型系统，还需要考虑容错，如果一个叶子Server出现故障或变慢，不能让整个查询也受到明显影响。
通常情况下，每个计算节点，执行多个任务。例如，技巧中有3000个叶子Server，每个Server使用8个线程，有可以有24000个计算单元。如果一张表可以划分为100000个区，就意味着大约每个计算单元需要计算5个区。这执行的过程中，如果某一个计算单元太忙，就会另外启一个来计算。这个过程是动态分配的。
对于GFS这样的存储，一份数据一般有3份拷贝，计算单元很容易就能分配到数据所在的节点上，典型的情况可以到达95%的命中率。
Dremel还有一个配置，就是在执行查询的时候，可以指定扫描部分分区，比如可以扫描30%的分区，在使用的时候，相当于随机抽样，加快查询。
Google Dremel测试实验
实验的数据源如下表示。大部分数据复制了3次，也有一个两次。每个表会有若干分区，每个分区的大小在100K到800K之间。如果压缩率是25%，并且计入复制3份的事实的话。T1的大小已经达到PB级别。这么小且巨量的分区，对于GFS的要求很高，现在的Hdfs稳定版恐怕受不了。接下来的测试会逐步揭示其是如何超过MR，并对性能作出分析。
| 表名 | 记录数 | 大小(已压缩) | 列数 | 数据中心 | 复制数量 |
| T1 | 85 billion | 87 TB | 270 | A | 3× |
| T2 | 24 billion | 13 TB | 530 | A | 3× |
| T3 | 4 billion | 70 TB | 1200 | A | 3× |
| T4 | 1+ trillion | 105 TB | 50 | B | 2× |
| T5 | 1+ trillion | 20 TB | 30 | B | 3× |
列存测试
首先，我们测试看看列存的效果。对于T1表，1GB的数据大约有300K行，使用列存的话压缩后大约在375MB。这台机器磁盘的吞吐在70MB/s左右。这1GB的数据，就是我们的现在的测试数据源，测试环境是单机。
见上图。
· 曲线A，是用列存读取数据并解压的耗时。
· 曲线B是一条一条记录挨个读的时间。
· 曲线C是在B的基础上，加上了反序列化的时间。
· 曲线d，是按行存读并解压的耗时。
· 曲线e加上了反序列化的时间。因为列很多，反序列化耗时超过了读并解压的50%。
从图上可以看出。如果需要读的列很少的话，列存的优势就会特别的明显。对于列的增加，产生的耗时也几乎是线性的。而一条一条该个读和反序列化的开销是很大的，几乎都在原来基础上增加了一倍。而按行读，列数的增加没有影响，因为一次性读了全部列。
Dremel和MapReduce的对比测试
MR和Dremel最大的区别在于行存和列存。如果不能击败MapReduce，Remel就没有意义了。使用最常见的WordCount测试，计算这个数据中Word的个数。
|
1
|
Q1:
SELECT
SUM
(CountWords(txtField)) /
COUNT
(*)
FROM
T1
|
上图是测试的结果。使用了两个MR任务。这两个任务和Dremel一样都运行在3000个节点上面。如果使用列存，Dremel的按列读的MR只需要读0.5TB的数据，而按行存需要读87TB。 MR提供了一个方便有效的途经来讲按行数据转换成按列的数据。Dremel可以方便的导入MapReduce的处理结果。
树状计算Server测试
接下来我们要对比在T2表示使用两个不同的Group BY查询。T2表有24 billion 行的记录。每个记录有一个 item列表，每一item有一个amount 字段。总共有40 billion个item.amount。这两个Query分别是。
|
1
2
3
|
Q2:
SELECT
country,
SUM
(item.amount)
FROM
T2
GROUP
BY
country
Q3:
SELECT
domain,
SUM
(item.amount)
FROM
T2
WHERE
domain
CONTAINS
’.net’
GROUP
BY
domain
|
Q2需要扫描60GB的压缩数据，Q3需要扫描180GB，同时还要过滤一个条件。
上图是这两个Query在不同的server拓扑下的性能。每个测试都是有2900个叶子Server。在2级拓扑中，根server直接和叶子Server通信。在3级拓扑中，各个级别的比例是1:100:2900，增加了100个中间Server。在4级拓扑中，比例为1:10:100:2900.
Q2可以在3级拓扑下3秒内执行完毕，但是为他提供更高的拓扑级别，对性能提升没有裨益。相比之下，为Q3提供更高的拓扑级别，性能可以有效提升。这个测试体现了树状拓扑对性能提升的作用。
每个分区的执行情况
对于刚刚的两个查询，具体的每个分区的执行情况是这样的。
可以看到99%的分区都在1s内完成了。Dremel会自动调度，使用新的Server计算拖后腿的任务。
记录内聚合
由于Demel支持List的数据类型，有的时候，我们需要计算每个记录里面的各个List的聚合。如
|
1
2
3
4
5
6
7
|
Q4 :
SELECT
COUNT
(c1 > c2)
FROM
(
SELECT
SUM
(a.b.c.d) WITHIN RECORD
AS
c1,
SUM
(a.b.p.q.r) WITHIN RECORD
AS
c2
FROM
T3)
|
我们需要count所有sum(a.b.c.d)比sum(a.b.p.q.r)，执行这条语句实际只需要扫描13GB的数据，耗时15s，而整张表有70TB。如果没有这样的嵌套数据结构，这样的查询会很复杂。
扩展性测试
Dremel有良好的扩展性，可以通过增加机器来缩短查询的时间。并且可以处理数以万亿计的记录。
对于查询：
|
1
|
Q5:
SELECT
TOP
(aid, 20),
COUNT
(*)
FROM
T4
WHERE
bid = fvalue1g
AND
cid = fvalue2g
|
使用不同的叶子Server数目来进行测试。
可以发现CPU的耗时总数是基本不变的，在30万秒左右。但是随着节点数的增加，执行时间也会相应缩短。几乎呈线性递减。如果我们使用通过CPU时间计费的“云计算”机器，每个租户的查询都可以很快，成本也会非常低廉。
容错测试
一个大团队里面，总有几个拖油瓶。对于有万亿条记录的T5，我们执行下面的语句。
|
1
|
Q6:
SELECT
COUNT
(
DISTINCT
a)
FROM
T5
|
值得注意的是T5的数据只有两份拷贝，所以有更高的概率出现坏节点和拖油瓶。这个查询需要扫描大约1TB的压缩数据，使用2500个节点。
可以看到99%的分区都在5S内完成的。不幸的是，有一些分区需要较长的时间来处理。尽管通过动态调度可以加快一些，但在如此大规模的计算上面，很难完全不出问题。如果不在意太精确的结果，完全可以小小减少覆盖的比例，大大提升相应速度。
Google Dremel 的影响
Google Dremel的能在如此短的时间内处理这么大的数据，的确是十分惊艳的。有个伯克利分校的教授Armando Fox说过一句话“如果你曾事先告诉我Dremel声称其将可做些什么，那么我不会相信你能开发出这种工具”。这么给力的技术，必然对业界造成巨大的影响。第一个被波及到的必然是Hadoop。
Dremel与Hadoop
Dremel的公开论文里面已经说的很明白，Dremel不是用来替代MapReduce，而是和其更好的结合。Hadoop的Hive，Pig无法提供及时的查询，而Dremel的快速查询技术可以给Hadoop提供有力的补充。同时Dremel可以用来分析MapReduce的结果集，只需要将MapReduce的OutputFormat修改为Dremel的格式，就可以几乎不引入额外开销，将数据导入Dremel。使用Dremel来开发数据分析模型，MapReduce来执行数据分析模型。
Hadoop的Hive,Pig现在也有了列存的模式，架构上和Dremel也接近。但是无论存储结构还是计算方式都没有Dremel精致。对Hadoop实时性的改进也一直是个热点话题。要想在Hadoop中山寨一个Dremel，并且相对现有解决方案有突破，笔者觉得Hadoop自身需要一些改进。一个是HDFS需要对并发细碎的数据读性能有大的改进，HDFS需要更加的低延迟。再者是Hadoop需要不仅仅支持MapReduce这一种计算框架。其他部分,Hadoop都有对应的开源组件，万事俱备只欠东风。
Dremel的开源实现
Dremel现在还没有一个可以运行的开源实现，不过我们看到很多努力。一个是Apache的Drill，一个是OpenDremel/Dazo。
OpenDremel/Dazo
OpenDremel是一个开源项目，最近改名为Dazo。可以在GoogleCode上找到http://code.google.com/p/dremel/。目前还没有发布。作者声称他已经完成了一个通用执行引擎和OpenStack Swift的集成。笔者感觉其越走越歪，离Dremel越来越远了。
Apache Drill
Drill 是Hadoop的赞助商之一MapR发起的。Drill作为一个Dremel的山寨项目，有和Dremel相似的架构和能力。他们希望Drill最终会想Hive,Pig一样成为Hadoop上的重要组成部分。为Hadoop提供快速查询的能力。和Dremel有一点不同，在数据模型上，开源的项目需要支持更标准的数据结构。比如CSV和JSON。同时Drill还有更大的灵活性，支持多重查询语言，多种接口。
现在Drill的目标是完成初始的需求，架构。完成一个初始的实现。这个实现包括一个执行引擎和DrQL。DrQL是一个基于列的格式，类似于Dremel。目前，Drill已经完成的需求和架构设计。总共分为了四个组件
· Query language:类似Google BigQuery的查询语言，支持嵌套模型，名为DrQL.
· Low-lantency distribute execution engine:执行引擎，可以支持大规模扩展和容错。可以运行在上万台机器上计算数以PB的数据。
· Nested data format:嵌套数据模型，和Dremel类似。也支持CSV,JSON,YAML类似的模型。这样执行引擎就可以支持更多的数据类型。
· Scalable data source: 支持多种数据源，现阶段以Hadoop为数据源。
目前这四个组件在分别积极的推进，Drill也非常希望有社区其他公司来加入。Drill希望加入到Hadoop生态系统中去。
最后的话
本文介绍了Google Dremel的使用场景，设计实现，测试实验，和对开源世界的影响。相信不久的将来，Dremel的技术会得到广泛的应用。
原文链接： Tammy Everts 翻译： 伯乐在线 - 伯乐在线读者
译文链接： http://blog.jobbole.com/46599/
[ 转载必须在正文中标注并保留原文链接、译文链接和译者等信息。]