在HTTP上，缓存是在文件级完成的。浏览器将在页面上缓存JPEG、CSS和Javascript文件。然而，大多数页面的HTML是动态生成的。因此，页面无法缓存。这是不幸的，因为即使是高度动态页面的HTML变化也很少超过10%。从一个请求到下一个请求的90%相同的HTML被不必要地传输。在web上，压缩等于性能。如果你能将一个响应压缩50%，你的网络性能大概会翻倍。考虑到90%以上的HTML不需要通过网络传输，如果您只能传输内容的实际动态部分，那么您的性能将得到极大的提高。上一代解决方案：边侧包括认识到这一机会，传统的内容交付网络（CDN）供应商创建了Edge Side Include（ESI）协议。该协议作为官方标准提交给了万维网联盟（W3C），但从未被接受。今天，有一些老式的cdn支持ESI，尽管它的采用进展缓慢。

ESI的工作原理如下：当您创建一个web页面时，您可以确定哪些部分是静态的和动态的。将静态部分实现为上载到CDN的文件。在该文件中，包含引用内容动态部分的标记，以及从何处获取动态部分的URL。CDN获取这些动态资源中的每一个，并将它们与静态部分组合，以便在页面通过网络发送回浏览器之前呈现HTML。如果这听起来很容易实现，那么您可能没有做太多的web开发。要了解复杂性，请查看这106页的ESI开发人员指南。虽然ESI理论上可以带来显著的性能优势，但实际开发ESI的痛苦是巨大的。而且，一旦你为它做了开发，就会有一个重要的过程锁定：祝你好运永远离开。我们认为你不应该学习一种新的编程语言或改变一行代码只是为了让你的网站更快。如果你把时间花在修改HTML上，这样CDN就可以更好地服务于它，那么你就不会把时间花在开发实际的web站点上了。下一代：更快，更容易，更好昨天，我们发布了Railgun以及它如何让你缓存以前无法缓存的内容。对Railgun的一种思考方式是，它就像自动ESI支持而不需要工作。Railgun不必标记自己的内容来标记静态和动态内容，Railgun自动确定HTML的静态部分并在边缘缓存。HTML的动态部分总是从源代码获取的，而不需要更改一行代码。

此外，缓存逻辑对页面上实际发生的事情做出响应。如果页面上的不同元素以不同的速率变化，那么Railgun的缓存将以最佳方式提供它们，而不会浪费一个原本不需要传输的字节。而且，由于您不需要更改编写代码的方式来支持Railgun，所以如果您决定关闭该服务，就不会有进程锁定。当你如果没有CloudFlare，Railgun将无法获得好处，您不需要完全重写代码。事实上，你不需要改变什么。CloudFlare：我们为出版商而战我们与许多网络出版商交谈，我们经常听到的一句话是，他们可用的性能和安全工具过于昂贵和复杂。我们已经有近50万个网站注册了CloudFlare，这主要是因为我们专注于这两个问题。Railgun采用了另一种技术ESI，以前只为那些预算巨大的站点和专门的CDN管理团队保留，并以一种负担得起且易于实施的方式提供ESI。

由于Railgun要求在原始服务器上安装软件，因此我们限制了其对业务和企业客户的可用性。但是，如果CloudFlare的免费和专业级客户托管在CloudFlare优化的托管合作伙伴上，我们的计划是将其推广到CloudFlare的免费和专业级客户。如果您对Railgun感兴趣，可以升级到CloudFlare Business或Enterprise。或者，ping您的主机提供商，让他们知道他们应该成为CloudFlare优化的主机。它对主人是免费的，如果他们告诉我们你是说服他们注册的人，我们会寄给你一件T恤衫，并确保你是第一批获得Railgun服务的主机客户之一。