在过去的博客文章中，我曾描述过CloudFlare的Railgun技术，该技术旨在极大地加快非缓存页面的交付。尽管CloudFlare缓存了组成页面所需的约65%的资源，但大约35%的资源无法缓存，因为它们是动态生成的或标记为"不缓存"。而这35%通常是网页的初始HTML，必须先下载。

为了解决这个问题，CloudFlare提出了一种delta压缩技术，这种技术可以识别即使是动态生成的或个性化的页面，也只会随着时间的推移或用户之间的变化很小。Railgun使用这种压缩技术大大减少了通过互联网从后端web服务器发送到CloudFlare数据中心的数据量。其结果是更快地交付关键的HTML，浏览器必须接收这些HTML才能下载页面的其余部分。用Railgun进行的测试表明，非常大的压缩比是可能的，并且它们导致了页面交付的大幅加速。但仍然有两个问题："在现实世界中会产生什么影响？"以及"这对页面加载时间有多大影响？"。我们现在可以回答这些问题了。第一个推出Railgun的托管合作伙伴是位于蒙特利尔的Vexxhost。他们给了我们51个网站的样本，他们已经启用了Railgun，并允许我们运行性能测试，看看Railgun有什么不同。我们决定测量三个指标：HTML的传输速度有多快，压缩比是多少，页面加载时间有多大的变化。为了得到有用的数字，我们决定多次加载页面（每个页面在使用和不使用Railgun的情况下加载20次，总共下载40次），并使用中值。测试是通过从英国伦敦的一台机器上下载这些页面来完成的。最近的CloudFlare数据中心（Railgun正在运行）和原始web服务器之间的往返时间中位数为78ms。HTML传输加速、第一字节时间和压缩比在Vexxhost提供的51个站点中，我们看到下载HTML的平均速度为1.43x。换言之，这意味着下载网页HTML的中间时间减少到没有Railgun时的70%。在51个网站中，有11个网站的加速速度超过2倍（即下载网页HTML的时间减少了一半以上），其中8个网站的加速速度超过3倍（即网页HTML下载时间缩短到原来的三分之一）。

Railgun实现的中值压缩比为0.65%（即页面缩小到其大小的0.65%）。在51个站点中，只有9个站点的压缩比大于3%（也就是说，大多数页面都缩小到了原来大小的一小部分）。正是这种巨大的压缩使Railgun能够显著地加速HTML的交付。

另一个要考虑的度量是到第一个字节的时间（页面的第一个字节传递到浏览器需要多长时间）。这是从开始到服务器的TCP连接到从服务器接收到第一个字节的时间。轨道炮对TTFB也有影响。TTFB的中值改善是将其降低到非轨道炮加速值的90%。

但是HTML交付是一回事，真正的最终用户可见效果是什么？i、 这如何转化为页面加载时间的差异。页面加载时间Railgun对页面加载时间产生了影响，因为它加快了初始HTML的下载，而这必须在页面的其余部分下载之前进行。更快地下载HTML有助于更快地下载整个页面。下面是一个Railgun在CloudFlare计划页面上的效果示例。这个小测试是在伦敦的同一台机器上进行的。首先，这是没有启用Railgun的页面的瀑布图。

页面加载时间是1.83s。现在启用Railgun后，页面加载时间下降到1.15s，因为下载初始HTML的时间减少了。

当然，这只是一个测试。在使用和不使用轨道炮的情况下重复测试10次，使用轨道炮和无轨道炮时的平均页面加载时间分别为1.59s和2.59s（使轨道炮加速时间为非加速页面加载时间的61%）。CloudFlare主页的类似测试显示，Railgun加速页面加载时间的中值为2.56s，而没有Railgun的页面加载时间为3.2s（即Railgun使页面加载时间下降到原来的83%）。为了测量Vexxhost提供的51个站点的页面加载时间，我们在与上述测量相同的机器上设置了PhantomJS（一种使用WebKit作为引擎的无头浏览器）。一个小脚本使我们能够生成下载整个网页（包括JavaScript、CSS、HTML和图像）的HAR文件，并提取页面加载时间（我们使用"onload"时间）。这些页面加载时间包括未被CloudFlare或Railgun加速的资产，因此它们显示了Railgun如何提供帮助的真实数据。然而，Railgun在Vexxhost选择的站点上提供了帮助，页面加载时间的中值减少到原始时间的89%。平均页面加载时间的最佳增加是56%。少数站点没有看到页面加载时间的改进（它们对应的站点没有得到显著的Railgun加速，因为它们通常只有少量的HTML）。在这两张图片中可以看到通过Railgun下载的同一个网站和not网站的对比。页面加载时间的减少是由于获取初始HTML的时间减少。以下是不带轨道炮的页面加载：