我最初是为网络性能日历网站写这篇文章的，这是一个很棒的专家意见资源，让你的网站尽可能快。我们认为CloudFlare用户会感兴趣，所以我们在这里转载了它。享受吧！高效压缩动态生成的web内容随着高带宽互联网连接在家庭、办公室和移动设备上的广泛采用，下载网页的可用带宽限制已基本消除。同时，延迟仍然是一个主要问题。根据Google最近的一个演示，光纤技术的宽带互联网延迟为18ms，基于电缆的服务为26ms，DSL为43ms，移动设备为150ms-400ms。最终，带宽可以用新技术大大扩展，但是延迟受到光速的限制。互联网连接的延迟直接影响网页的下载速度。延迟问题的发生是因为TCP协议要求往返来确认接收到的信息（因为数据包在穿越互联网时可能会丢失，并且确实会丢失），为了防止互联网拥塞，TCP有机制限制每次往返发送的数据量，直到它知道它可以发送多少而不会造成拥塞。光速和TCP协议之间的冲突变得更加严重，因为网站所有者可能会选择最便宜的主机，而不考虑其物理位置。事实上，向"云"的转移鼓励了这样一种想法，即网站只是"在外面"，而没有考虑到终端用户的web浏览器和服务器之间的距离所带来的真正的延迟问题。例如，在美国，针对英国消费者的网站并不少见。伦敦的一个网络用户正在访问一个。联合王国由于经过的距离，实际托管在芝加哥的站点需要额外的60毫秒往返时间。处理光速引起的延迟需要将web内容移近正在浏览的用户，或者使web内容更小，从而减少所需的往返（或两者兼而有之）。缓存挑战缓存技术和内容交付服务意味着静态内容（如图像、CSS、JavaScript）可以在接近最终用户的地方进行缓存，从而减少加载时的延迟。CloudFlare平均认为大约65%的web内容是可缓存的。但是网页最关键的部分，实际的HTML内容通常是动态生成的，不能被缓存。因为缓存中相对快速的加载内容都不能在HTML之前加载，所以web浏览器接收HTML的任何延迟都会影响整个web浏览体验。因此，即使在高延迟的环境中，能够尽快地交付页面HTML对于确保良好的浏览体验至关重要。研究表明，页面加载时间越慢，用户就越有可能放弃并转移到其他地方。谷歌最近的一项研究表明，人类对不到100毫秒的响应时间的感知是"瞬间"（人类眨眼的时间在100毫秒到400毫秒之间）；不到300毫秒，电脑就显得迟钝；超过1秒，用户的思维就会因分心或其他想法而消失。TCP的拥塞避免算法意味着在下载网页时需要多次往返。例如，仅获取CNN主页的HTML就需要大约15次往返；不难看出，在最终用户对网站失去耐心的情况下，延迟会迅速增加多长时间。不幸的是，它不可能缓存大多数网页的HTML，因为它是动态生成的。动态页面很常见，因为HTML是以编程方式生成的，而不是静态的。例如，新闻网站会随着新闻报道的变化而生成新的HTML，或者根据最终用户的地理位置显示不同的页面。许多网页也是动态生成的，因为它们是为最终用户个性化的——每个人的Facebook页面都是独一无二的。而web应用程序框架，比如WordPress，鼓励使用默认的动态生成HTML，并将内容标记为不可缓存。施压施救考虑到web页面需要动态生成，唯一可行的选择是减小页面大小，这样就需要更少的TCP往返，从而最小化延迟的影响。目前最好的选择是使用gzip编码。对于典型的网页内容，gzip编码会将页面大小减小到原始大小的20-25%。但这仍然会导致传输数千字节的页面数据，从而导致TCP拥塞避免和延迟惩罚；在上面的CNN示例中，即使页面是gzip压缩的，也有15次往返。Gzip编码是完全通用的。它不考虑压缩内容的任何特殊特性。它也是自引用的：gzip编码的页面是完全自包含的。这是有利的，因为这意味着使用gzip压缩内容的系统可以是无状态的，但这意味着在公共内容的外部字典中可以实现的更大的压缩比却不是可能。外部字典可以显著提高压缩比，因为压缩后的数据可以引用字典中的项。这些引用可以非常小（每个引用几个字节），但可以从字典扩展到非常大的内容。例如，假设有必要向用户传送詹姆士国王的圣经。古腾堡项目的纯文本版本是4452097字节，用gzip压缩后是1404452字节（大小减少到31%）。但是想象一下这样的情况：压缩器知道最终用户在有用内容的字典中有一个单独的旧约和新约的副本。他们可以传输一条格式为<；Insert Old-Testament><；Insert New-Testament>格式的指令，而不是传输一兆字节的gzip压缩内容。这个指令只有几个字节长。显然，这是一个极端和不寻常的情况，但它强调了外部共享词典的有用性，这些词典可以用来重建原始的、未压缩的文档。外部字典可以应用于动态生成的web内容，以实现超过gzip的压缩。缓存页面部件在web上，共享词典是有意义的，因为动态web内容包含大量块，对于所有用户和时间都是一样的。以BBC新闻主页为例，它大约有116KB的HTML。该页面是动态生成的，HTTP缓存头被设置为不被缓存。即使页面上的新闻故事经常更新，大量的模板HTML并没有在请求之间（甚至用户到用户）发生变化。页面的前32KB（占HTML的28%）由嵌入的JavaScript、标题、导航元素和样式组成。如果web浏览器将"header block"存储在本地字典中，那么BBC只需要发送一个小指令，说<；Insert BBC header>，而不是32KB的数据。这样可以节省多次往返。在整个BBC的新闻页面上，有一些小部分不变的内容可以从字典中引用。不难想象，对于任何一个web站点，HTML的大部分内容都是相同的，从请求到请求，从用户到用户。即使是在Facebook这样一个非常个性化的网站上，每个用户的HTML也是相似的。随着越来越多的应用程序将HTTP用于API，因此有机会通过使用JSON或XML的共享字典来提高API的性能。api通常包含比HTML更常见、重复的部分，因为它们是用于机器消费的，并且随着时间的推移变化缓慢（而页面的HTML随着设计者更新页面外观的变化会更快）。两个不同的提案试图以不同的方式解决这一问题：SDCH和ESI。它们都没有被接受为互联网标准，部分原因是部署它们的复杂性增加了。SDCH公司2008年，Google的一个小组提出了一个协商共享内容词典的协议，这样web服务器就可以在web浏览器的缓存中包含页面块的情况下压缩页面。这个建议被称为SDCH（HTTP上的共享字典压缩）。当前版本的googlechrome使用SDCH压缩Google搜索结果。这可以在googlechrome的开发工具中看到。任何搜索请求都将包含一个HTTP标头，指定浏览器接受SDCH压缩页面：接受编码：gzip、deflate、sdch如果使用了SDCH，则服务器将响应，指示所使用的字典。如有必要，Chrome将检索字典。因为字典应该不经常更改，所以它大部分时间都在本地web浏览器缓存中。例如，下面是一个示例HTTP头，在Google搜索的实际响应中可以看到：获取字典：/sdch/60W93cgP.dct公司字典文件只包含HTML（和JavaScript等），压缩页面包含对使用rfc3284中指定的VCDIFF格式的字典文件部分的引用。压缩页面主要由COPY和ADD VCDIFF函数组成。COPY x，y指令告诉浏览器从字典中的位置x复制y字节的数据（这就是从字典中压缩和扩展常见内容的方式）。ADD指令用于插入未压缩的数据（即那些不在字典中的页面部分）。在Google搜索中，字典用于本地缓存页面中不经常更改的部分（例如HTML页眉、导航元素和页脚）。由于难以生成共享词典，SDCH还没有得到广泛的接受。出现了三个问题：何时更新词典、如何更新词典以及防止隐私信息泄露。为了最大限度地提高效率，最好是