减少请求最大的性能漏洞就是一个页面需要发起几十个网络请求来获取诸如样式表、脚本或者图片这样的资源。这个在相对低带宽和高延迟的移动设备连接上来说影响更严重。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头去掉，这样即使浏览器支持解压缩，用户也无法获取到压缩后的响应。 |
