HTTP 1.0的优化策略非常简单，就一句话：升级到HTTP 1.1。完了！
改进HTTP的性能是HTTP 1.1工作组的一个重要目标，后来这个版本也引入了大量增强性能的重要特性，其中一些大家比较熟知的有：
持久化连接以支持连接重用；
分块传输编码以支持流式响应；
请求管道以支持并行请求处理；
字节服务以支持基于范围的资源请求；
改进的更好的缓存机制。
当然，这些只是其中一部分，要全面讨论HTTP 1.1的所有增强特性，非得用一本书不可。同样，推荐大家买一本《HTTP权威指南》（David Gourley和Brian Totty合著）放在手边。另外，提到好的参考书，Steve Souder的《高性能网站建设指南》中概括了14条规则，有一半针对网络优化：
减少DNS查询每次域名解析都需要一次网络往返，增加请求的延迟，在查询期间会阻塞请求。
减少HTTP请求任何请求都不如没有请求更快，因此要去掉页面上没有必要的资源。
使用CDN从地理上把数据放到接近客户端的地方，可以显著减少每次TCP连接的网络延迟，增加吞吐量。
添加Expires首部并配置ETag标签相关资源应该缓存，以避免重复请求每个页面中相同的资源。Expires首部可用于指定缓存时间，在这个时间内可以直接从缓存取得资源，完全避免HTTP请求。ETag及Last-Modified首部提供了一个与缓存相关的机制，相当于最后一次更新的指纹或时间戳。
Gzip资源所有文本资源都应该使用Gzip压缩，然后再在客户端与服务器间传输。一般来说，Gzip可以减少 60%～80% 的文件大小，也是一个相对简单（只要在服务器上配置一个选项），但优化效果较好的举措。
避免HTTP重定向HTTP重定向极其耗时，特别是把客户端定向到一个完全不同的域名的情况下，还会导致额外的DNS查询、TCP连接延迟，等等。
上面每一条建议都经受了时间检验，无论是该书出版的2007年还是今天，都是适用的。这并不是巧合，而是因为所有这些建议都反映了两个根本方面：消除和减少不必要的网络延迟，把传输的字节数降到最少。这两个根本问题永远是优化的核心，对任何应用都有效。
可是，对所有HTTP 1.1的特性和最佳实践，我们就不能这么说了。因为有些HTTP 1.1特性，比如请求管道，由于缺乏支持而流产，而其他协议限制，比如队首响应阻塞，则导致了更多问题。为此，Web开发社区（一直都最有创造性），创造和推行了很多自造的优化手段：域名分区、连接文件、拼合图标、嵌入代码，等等，不下数十种。
对多数Web开发者而言，所有这些都是切实可行的优化手段：熟悉、必要，而且通用。可是，现实当中，我们应该对这些技术有正确的认识：它们都是些针对当前HTTP 1.1协议的局限性而采用的权宜之计。我们本来不应该操心去连接文件、拼合图标、分割域名或嵌入资源。但遗憾的是，“不应该”并不是务实的态度：这些优化手段之所以存在，都是有原因的，在背后的问题被HTTP的下一个版本解决之前，必须得依靠它们。
持久连接的优点HTTP 1.1的一个主要改进就是引入了持久HTTP连接 。现在我们再演示一下为什么这个特性对我们的优化策略如此重要。
为简单起见，我们限定最多只有一个TCP连接，并且只取得两个小文件（每个<4 KB）：一个HTML文档，一个CSS文件，服务器响应需要不同的时间（分别为40 ms和20 ms）。
假设从纽约到伦敦的单向光纤延迟都是28 ms
每个TCP连接开始都有三次握手，要经历一次客户端与服务器间完整的往返。此后，会因为HTTP请求和响应的两次通信而至少引发另一次往返。最后，还要加上服务器处理时间，才能得到每次请求的总时间。
服务器处理时间无法预测，因为这个时间因资源和后端硬件而异。不过，这里的重点其实是由一个新TCP连接发送的HTTP请求所花的总时间，最少等于两次网络往返的时间：一次用于握手，一次用于请求和响应。这是所有非持久HTTP会话都要付出的固定时间成本。
服务器处理速度越快，固定延迟对每个网络请求总时间的影响就越大！要验证这一点，可以改一改前面例子中的往返时间和服务器处理时间。”
实际上，这时候最简单的优化就是重用底层的连接！添加对HTTP持久连接的支持，就可以避免第二次TCP连接时的三次握手、消除另一次TCP慢启动的往返，节约整整一次网络延迟。