ACM通信

实践

移动设备性能优化规则

由Tammy翻转
ACM通信，2013年8月，第56卷第8期，52-59页
10.1145/2492007.2492024
评论

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

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

本文总结了前端优化的案例，并概述了加速页面的策略和战术，重点是解决移动性能问题。

无论您的Web页面多么有趣、漂亮或具有巧妙的交互性，如果它们在桌面或移动设备上的渲染时间超过两到三秒，用户很快就会失去耐心。他们从浏览转变为购买的可能性明显降低，甚至可能在页面加载之前就按下返回键或关闭浏览器。

即使是少于一秒钟的延迟也会显著影响收益。2006年，当时谷歌的玛丽莎•梅耶尔(Marissa Mayer)回忆说，在用户表示希望每页显示超过10个搜索结果后，谷歌尝试显示30个结果。让谷歌惊讶的是，在这个实验中，流量和收入下降了20%，显然是因为有更多结果的页面只多花了半秒的时间来加载。⁵

从那以后，用户的期望一直在上升。2009年，Forrester Research代表Akamai进行的一项研究发现，2秒是可接受的网页响应时间的阈值，并且发现40%的消费者会放弃加载时间超过3秒的网页。仅仅一年后，另一项为Akamai所做的研究发现，用户在3秒后退出页面的比例上升到了57%。^1,7

此外，移动设备上的用户希望性能至少与他们在台式电脑上体验的一样好，如果不是更好的话。由Tealeaf Technology(现为IBM)委托开展的哈里斯互动2011年移动交易调查报告显示，在前一年进行过移动交易的成年人中，85%的人预期移动交易体验与使用笔记本电脑或台式电脑在线购物的体验持平或更好，63%的人表示，如果在手机上进行交易时遇到问题，他们将不太可能通过其他渠道从同一家公司购买商品。¹⁰换句话说，糟糕的移动业务表现伤害了包括实体店在内的所有其他平台的公司。

移动通信正在迅速扩张。对于许多消费者来说，他们的手机或平板电脑已经成为他们上网的主要门户，但性能却达不到预期。2011年2月，由Equation Research代表Compuware发布的一项研究发现，近一半(46%)的手机用户表示，他们手机上的网站加载速度比预期的要慢。近60%的人希望页面在3秒或更短时间内加载，74%的人表示，如果一个页面需要5秒或更长时间加载，他们就会离开网站。2012年，Strangeloop Networks(现为Radware)对200家领先电子商务网站的研究发现，3G网络的加载时间中值为11.8秒图1);在LTE上的表现仅略好，为8.5秒。⁸

手机性能的三个限制因素．正如前面提到的，移动设备有固有的性能限制:更低的带宽、更小的内存和更低的处理能力。外部问题加剧了这些挑战，特别是:

网页比以前更大了．根据HTTP Archive，平均每个Web页面承载超过1MB的负载，并包含至少80个资源，如图像、Java Script、CSS(级联样式表)文件等。这对桌面性能有重大影响。它对移动性能，尤其是3G性能的影响要显著得多。这种影响在未来三年将会更加强烈。按照目前的增长速度，到2015年页面可能超过2MB。

延迟可能变化很大．它的范围从LTE的34毫秒到3G的350毫秒或更多。移动延迟的一致性只体现在它的不一致性上，即使是在相同的位置进行测量。这是由于除了通过塔的数据量之外还有许多变量。天气、甚至用户面对的方向等因素都可能产生重大影响。

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

网站并不是解决手机性能问题的万灵药．许多网站所有者试图通过开发更小、更快、精简的m.o.site来应对高用户需求、大网页和较差的连接速度;然而，这些尝试并不是完全有效的，因为高达35%的手机用户会选择查看完整的网站。

这些全网站访问者比m.d eite访问者更有可能在网站上消费。一项研究发现，每7美元的移动创收中，有5.5美元是通过完整网站创收的。只有1美元来自m.site, 0.5美元来自app。⁹

解决这个问题．改进网站性能的主要策略并没有随着用户从桌面迁移到手机和平板电脑而改变，尽管出现了一些新的策略。

在桌面或移动浏览器中显示一个典型的Web页面所需的时间中，只有20%用于加载页面的HTML。剩下的80%用于加载渲染页面所需的额外资源，包括样式表、脚本文件和图像，以及执行客户端处理。

提高绩效的三个主要策略是:

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

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

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

回到顶部

减少请求

对性能的最大消耗通常是需要完成数十次网络往返以检索样式表、脚本和图像等资源。对于相对较低的带宽和较高的延迟的移动连接来说，尤其如此。cdn(内容传递网络)可以通过将内容从地理位置上靠近用户来有所帮助，但请求的数量对页面加载时间的影响要比请求传输的距离大得多。此外，最近的研究结果表明，cdn对移动用户的效果有限。^3.

在这里，我将讨论几种最小化HTTP请求的方法。

整合资源．到目前为止，开发人员的标准做法是将JavaScript代码和CSS样式合并到可以跨多个页面共享的公共文件中。这种技术简化了代码维护并提高了客户端缓存的效率。

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

雪碧是一种用于巩固图像的CSS技术。精灵只是将多个图像组合成一个大型图像中的直线网格。页面一次性获取大图像作为单个CSS背景图像，然后使用CSS背景定位在页面上根据需要显示单个组件图像。这将多个请求减少到一个，显著提高了性能。

易于实现:适中，但需要有资源。根据开发人员对网站的控制级别，有些资源可能无法合并(例如，如果它们是由CMS生成的)。另外，一些资源可能位于外部域上，这可能会导致合并问题。还需要注意的是，资源整合对于移动浏览器来说可能是一把双刃剑。减少第一次请求可以提高性能，但是更大的合并资源可能无法有效地缓存，因此要注意将合并技术与其他技术结合起来进行优化localStorage．

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

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

易于实现:先进。而localStorage机制使用起来可能很简单，但围绕它构建缓存确实会产生一些复杂性。您将需要考虑缓存为您处理的所有问题，例如缓存过期(何时删除项?)、缓存丢失(如果您期望在缓存中有什么内容怎么办?localStorage它不是吗?)，以及当缓存满时该怎么办。

在首次使用的HTML中嵌入资源．HTML中的标准模式是包含到外部资源的链接。这使得将这些资源作为服务器上(或CDN中)的文件进行维护更容易，并且可以在源上更新它们，而不是在多个页面中的每个页面中更新它们。该模式还支持浏览器缓存，允许从缓存自动获取缓存资源，而不是像前面讨论的那样从服务器获取缓存资源。

中尚未缓存的资源localStorage但是，这种连接到外部资源的模式对性能有负面影响。一个典型的页面可能需要几十个单独的请求，以便收集呈现页面所需的资源。因此，从性能的角度来看，如果资源不太可能已经被缓存，那么通常最好将该资源嵌入到页面的HTML(称为内联)而不是将其存储在外部并链接到它。HTML中支持脚本和样式标记来内联这些资源，但是图像和其他二进制资源也可以通过使用包含base64编码的资源文本版本的数据uri来内联。

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

易于实现:温和。这种技术要求站点具有一种机制，根据用户以前是否访问过该页面来生成不同版本的页面。

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

易于实现:先进。这种技术非常具体于实现。如果您的站点目前正在使用其他AJAX或Comet技术进行轮询，那么转换为使用Server-Sent事件可能需要对站点的JavaScript进行大量重新编码。

消除重定向．当用户试图从移动设备导航到标准桌面站点时，Web应用程序通常会读取用户代理HTTP头，以检测请求来自移动设备。然后，应用程序可以发送一个HTTP 301(或302)响应，其中包含一个空主体和一个Location头，根据需要将用户重定向到站点的移动版本。然而，在移动网络上，从客户端到移动站点的额外往返通常会消耗几百毫秒。相反，直接交付移动Web页面以响应原始请求比交付重定向消息然后请求移动页面更快。

为了方便那些更喜欢在移动设备上查看桌面站点的用户，您可以在移动站点上提供一个链接，向您的应用程序发出信号，以抑制这种行为。

易于实现．虽然这种技术在理论上很容易，但不一定能付诸实践。许多网站为它们的m.s sites重定向到不同的服务器，因为这些服务器可能驻留在其他地方。其他网站发送带有重定向的cookie，以便在重定向后告诉Web应用程序它们是移动的。这可能更难以控制，具体取决于Web应用程序。

回到顶部

减少负载

规模很重要。更小的页面呈现得更快，更小的资源获取得更快。减少每个服务器响应的大小通常不会像减少每个页面所需的响应数量那样有助于提高性能。然而，有几种技术确实能带来性能上的净收益，特别是在必须明智地管理带宽和处理能力的移动设备上。

压缩文本和图像．像gzip这样的压缩技术减少了有效负载，只需要添加少量的处理步骤来在服务器上压缩和在浏览器中解压。但是，这些操作经过了高度优化，测试表明总体效果是性能的净提高。基于文本的响应，包括HTML、XML、JavaScript对象符号(JSON)、JavaScript和CSS，都可以减少70%的大小。

浏览器在Accept-Encoding请求报头中宣布了它们的解压缩功能，当服务器在Content-Encoding响应报头中发出响应被压缩的信号时，浏览器会自动执行解压缩。

易于实现:一件容易的事。如果设置正确，所有现代Web服务器都将支持压缩响应。然而，仍然有桌面安全工具会从请求中删除Accept-Encoding头，这将阻止用户获得压缩响应，即使他们的浏览器支持它。

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

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

易于实现:一件容易的事。来自谷歌的闭包编译器在理解和缩小JavaScript方面做了令人难以置信的工作。CSS的缩小有点麻烦，因为有太多的CSS hack针对不同的浏览器，很容易使缩小器混淆或缩小后不再正确工作。还需要注意的是，虽然删除的字符不应该是必要的，但已经有发表的关于缩小破坏页面的报告。因此，一定要在应用此技术的任何页面上执行功能测试。

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

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

另一种选择是首先加载一个分辨率非常低的图像版本，以尽快打开页面，然后在onload或在用户开始与页面交互后的ready事件。

易于实现:高级，特别是对于高度动态的网站。

使用HTML5和CSS 3.0简化页面．HTML5规范包含了新的结构元素，例如头,导航,文章,页脚．使用这些语义元素生成的页面比使用通用的嵌套div和span标记更简单、更有效。更简单的页面更小，加载更快，更简单的DOM(文档对象模型)意味着更快的JavaScript执行。新的标签很快被新版本的浏览器采用，包括移动浏览器，而HTML5被设计成在不支持它的浏览器中优雅地降级。

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

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

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

许多网站提供定期更新的列表，显示哪些桌面和移动浏览器支持哪些功能(例如，http://caniuse.com/而且http://mobilehtml5.org/）.

易于实现:先进。手动进行这些更改是非常复杂和耗时的，如果不是不可能的话。如果使用CMS，它可能会生成大量您无法控制的HTML和CSS。

回到顶部

优化客户端处理

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

延迟渲染折叠以下的内容．您可以通过延迟加载和呈现初始可见区域(有时称为“折叠以下”)以下的任何内容来确保用户更快地看到页面。为了避免在加载页面的其余部分后重新流放内容，首先用占位符替换图像< img >指定正确高度和宽度的标记。

易于实现:温和。有一些很好的JavaScript库可以用于隐藏的延迟图像加载。¹²

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

---

浏览器执行构建页面所需的各种步骤的顺序会对性能产生重大影响，页面的复杂性和JavaScript技术的选择也是如此。

---

要延迟的脚本可以是您自己的，或者更重要的是，来自第三方的脚本。针对广告、社交媒体小部件或分析支持的优化不佳的脚本会阻碍页面的呈现，有时会增加宝贵的加载时间。此外，要仔细评估在移动站点上使用大型脚本框架(如jQuery)的情况，尤其是在框架中只使用几个对象时。

易于实现:温和。许多第三方框架现在提供了其api的延迟或异步版本。开发人员只需要切换到这些新版本。有些JavaScript延迟可能更复杂，因为有许多后续运行脚本的注意事项onload(例如，如果有一个脚本想要附加到onload事件吗?如果你推迟了onload在美国，它已经错过了机会)。

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

尽管这个名字,XMLHttpRequest并不要求您只使用XML。你可以叫它overrideMimeType方法指定“application/json”，并使用json而不是XML。使用JSON.parse是不是比普通的快两倍，更安全eval ()函数。

另外，请记住AJAX响应将受益于许多推荐用于标准响应的优化技术。一定要对AJAX响应应用缓存头、缩小、gzip压缩、资源整合等。

易于实现:很难量化，因为这种技术是非常具体的应用。由于存在跨域问题，您将需要使用XHR2，并控制外部域来发出跨域XHR请求。

适应网络连接．特别是对于使用更多带宽可能会额外收费的移动网络，只有在与代码结合使用时才应该使用某些技术来检测连接类型。例如，预加载资源以预测未来的请求通常是明智的，但如果用户的带宽是计量的，其中一些资源可能永远都不需要，那么这可能不是一个负责任的策略。

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

易于实现:先进。网络信息API最近发生了变化。¹¹它不再将网络定义为Wi-Fi、3G等，而是给出了关于带宽的信息，例如“非常慢、很慢、很快和非常快”。有一个属性试图告诉估计的MB/s，还有一个布尔“度量”度量，它尽最大努力保持正确，但这对浏览器来说是非常困难的。在某个地方进行测量并进行调整可能仍然是最好的想法，但这相当具有挑战性。

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

---

AJAX使页面能够在页面的某一部分中显示更新的数据，而无需重新构造整个页面。

---

对于提高移动站点的性能，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事件不会在用户点击屏幕时立即触发。相反，该设备最多等待半秒(大多数设备为300毫秒)，让用户有机会发起其他手势，而不是点击。然而，这种延迟会严重阻碍用户期望的响应性能。要修复此问题，请使用touchend事件。当用户点击屏幕时，该事件立即触发。

为确保用户不会遇到意外行为，您可能还需要使用touchstart而且touchmove事件。例如，不要认为按钮上的touchend是点击的意思，除非还有一个touchstart事件，如果用户在结束触摸之前触摸其他地方并拖动到按钮。你可以用一个touchmove事件后touchstart防止治疗下列疾病touchend作为一个点击，假设移动的手势不打算是一个点击。

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

易于实现:先进。这种技术需要做更多的工作来在页面上添加和维护链接。触摸事件的代码测试必须对可能发生的手势(而不是点击)具有弹性，例如缩放或滑动。

支持SPDY协议．一些困扰网站的性能瓶颈，无论是桌面还是移动端，都是由于应用程序层HTTP和HTTPS协议的低效造成的。2009年，谷歌开始研究一个名为SPDY(发音为“speedy”)的替代协议，以解决其中一些限制。我们的目标是使它成为一个由多个浏览器和Web服务器实现的开源项目，但最初它只在谷歌的Chrome浏览器(版本10或更高)和谷歌网站上得到支持。随着实现SPDY的Web服务器的发布，站点将能够为任何浏览器支持该协议的用户使用该协议。在对排名前100的25个网站的代表性组实施SPDY的测试中，谷歌观察到速度从27%提高到60%。²

SPDY对所有内容自动使用gzip压缩，与HTTP不同的是，它也对头数据使用gzip压缩。SPDY采用多路复用技术，支持通过单个TCP连接发送多个请求和响应流。此外，SPDY允许对请求进行优先级排序，例如，在页面内容中处于中心位置的视频可以被赋予比页边空白处的广告更高的优先级。

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

尽管SPDY不是专门针对移动平台的，但是移动网络上可用的有限带宽意味着SPDY优化在支持移动站点时将特别有用。

易于实现:一般到高级，取决于站点和服务器环境。谷歌为Apache 2.2mod_spdy提供了一个免费的SPDY模块;然而，mod_spdy有线程模型问题，默认情况下不能很好地与mod_php一起使用，因此需要额外注意，以确保它在您的站点上正确运行。⁶

回到顶部

不要忘记测试!

关于性能优化的讨论如果不提醒我们持续和仔细的测试是必不可少的，那就不完整。对系统的每一个更改都只是一个理论，直到根据基线进行测试为止。猜测性能瓶颈发生在哪里是没有意义的，除非基于真实的测试数据。

有很多开源和商业工具可以提供合成测试，包括地理分布和带宽/延迟限制。此外，真实用户监视(RUM)工具将测试带出实验室，进入不可预测的用户行为领域。

寻找支持移动和桌面场景的测试选项。如果您选择一个自动化的解决方案，请确保选择一个持续测试和改进它所应用的优化的解决方案。

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

相关文章
在queue.acm.org

移动应用程序开发:Web vs.本机
安德烈·查兰和布莱恩·勒鲁
http://queue.acm.org/detaiL.cfm?id=1968203

移动设备Web开发的发展
尼古拉斯·c·Zakas
http://queue.acm.org/detail.cfm?id=2441756

让移动网络更快
凯特Matsudaira
http://queue.acm.org/detail.cfm?id=2434256

回到顶部

回到顶部

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2013 ACM, Inc.

---

没有发现记录