2、使用CDN

用户与Web服务器的距离也会影响到响应时间。从用户的角度上看，把内容部署到多个、地理上分散的服务器中，也有助于加速网页的装载。但是，应该从哪里开始着手呢？

从地理上分散内容的第一步，不是以运行于分布式架构为目标重新设计Web应用程序。根据应用程序的复杂程度，架构的变动可能会涉及到极大的困难，比如：同步会话状态和在多服务器间复制数据库事务等等。由于涉及到架构问题，因此以这种方式缩短用户与内容之间距离的尝试可能会被拖延，甚至永远得不到批准。

别忘了终端用户响应时间的80～90%都花在了下载页面中的组件上：图像、样式表、脚本、Flash等等。而且，这也是我们在“前台性能的重要性”一节中强调的“性能黄金定律”。因此，完全可以避开重新设计应用程序架构的难题，将焦点放在分散静态内容上。虽然这样做不会带来较大的时间节约，但借助于内容分发网络却很容易实现。

所谓内容分发网络（Content Delivery Netword，CDN），就是一组Web服务器的集合，其中的服务器分布于不同的地点，能够将内容更有效地分发给用户。最终确定的将内容分发给用户的服务器，通常是基于对网络邻近情况进行测量的结果。比如说，某台服务器对用户来说只需最少的跃点，或者该服务器对用户的响应时间最短。

某些大型的Internet公司都拥有自己的CDN。不过，使用CND服务器提供商的产品往往更划算一些。常见的CND服务商包括：Akamai Technologies、Mirror Image Internet和Limelight Networks。对于创业型公司或者个人网站而言，通常不必考虑使用CND。但是，随着目标用户群逐渐增大而且越来越全球化，CDN对于加快响应时间的作用也会日益突显。在Yahoo!，通过从应用程序中分离出静态内容并转移到CDN上面，大约可以为终端用户节省20%以上的响应时间。将静态内容转存到CDN只需较少的代码改动，但却能收到显著提高网站速度的奇效。

1、减少HTTP请求

80%的终端用户响应时间花在了前台。其中，大部分时间都用于下载页面中的各种组件——图像、样式表、脚本、Flash等等。因此，减少组件的数量就能够减少呈现页面所需的HTTP请求数量。这正是加速网页显示的关键所在。

减少页面中组件的一种思路是简化页面的设计。然而，是否存在一种既能使页面内容丰富，又可以加速响应时间的方案呢？以下就是一些既能够减少HTTP请求数量，又可以确保页面内容丰富的技术。

通过图像地图将多幅图像组合为一幅图像。这样一来，虽然整体尺寸相同，但可以减少HTTP请求，进而加速页面显示。不过，图像地图只适用于页面中连续的图像，比如导航条。而且，定义图像地图中的坐标值通常会令人头疼，也容易出错。

• 未使用图像地图的例子：http://stevesouders.com/hpws/imagemap-no.php
• 使用了图像地图的例子：http://stevesouders.com/hpws/imagemap.php

• 推荐的一个精彩的例子：http://www.bookofjavascript.com/Websites/Salon/frame.html

“CSS精灵”是减少图像请求次数的首选方法。所谓“CSS精灵”，就是将页面中要用到的所有图像都组合到一幅图像中，然后通过CSS中的background-image和background-position属性，按照需要显示这幅图像中的不同部分。 查看全文 »

原文： Exceptional Performance : Best Practices for Speeding Up Your Web Site

非同凡响的性能：加速网站的最佳实践
——构建高性能网站的14条法则

作者：Steve Souders

1、减少HTTP请求
2、使用CDN（Content Delivery Network，内容分发网络）
3、添加到期头部信息
4、以gzip方式压缩组件
5、把样式表放在顶部
6、把脚本放在底部
7、避免使用CSS表达式
8、JavaScript和CSS外部化
9、减少DNS查询
10、控制JavaScript代码量
11、避免重定向操作
12、去掉多余的脚本
13、配置ETag
14、开启Ajax的缓存

前台性能的重要性

2004年，我在Yahoo!创建了Exceptional Performance小组。这是一个经过特别许可的个小团队，它的任务是度量和改进Yahoo!产品的性能。作为在职业生涯中的大部分时间内一直从事后台开发的工程师来说，我提议建立这个小组是因为过去的一个代码优化项目——通过了解Web性能可以识别出最容易改进的机会。因为我们的目标是改善最终用户的体验，所以我在各种带宽条件下观测了浏览器的响应时间。结果，我们绘制出了一幅针对http://www.yahoo.com中HTTP通信量的图表。

在上面这幅图中，第一个名为“html”的橫条表示对HTML文档的初始请求。这里，终端用户只有5%的时间花在了取得HTML文档上面。同样的结果差不多对所有的网站也都适用。在作为样本的美国前10大网站中，除了一个网站之外，取得HTML文档所用时间均不到总响应时间的20%。另外80%多的时间则花在了处理HTML文档（也就是前台）的内容上面。这也就是我们把加速网站的重点放在改进前台性能之上的原因。

以前台性能作为出发点的原因主要有三个：
1、前台具有更多的改进潜力。节省一半前台处理时间可以节约响应时间的40%，而节省一半后台处理时间只会节约不到10%的响应时间。
2、改进前台通常比改进后台需要投入的时间和资源更少。因为改进后台涉及到重新设计应用程序架构和代码、查找和优化关键代码路径、添加或升级硬件、分布数据库等等。
3、调整前台性能已经证明是可行的。通过遵循我们提出的性能最佳实践，Yahoo!中50多个团队服务的终端用户响应时间都节省了25%以上。
我们提出的性能黄金定律是：先从优化前台性能着手，因为前台处理要占用80%甚至更多的终端用户响应时间。