我在Ruby on Rails上运行了大多数静态站点，它使用Varnish反向代理caching来保存命中Rails后端。
问题是，用户可以login到网站，当他们这样做，我们使用ESI（边缘包括）来显示用户特定的页面部分。
使用ESI意味着我们必须在Rails后端禁用Gzip压缩（使用Nginx + passenger），否则varnish不能parsing从后端返回的数据以运行ESI处理。
我的问题是，使用反向代理caching的好处是否超过了gzip所有内容的好处？ 还是应该尝试摆脱ESI完整，并有两全其美？
如果你安排这样的事情，你可以得到两全其美：
用户 – > nginx – > Varnish – > Rails
将gzip压缩从nginx转换为用户。 这是最慢的部分，也是最昂贵的。 我假设你的nginx，Varnish和Rails实例是彼此本地的。 您的本地带宽应该绰绰有余。 除了解压缩来组装ESI之外，没有太多的意义。
如果带宽不是问题，并且没有gzip的情况下加载时间是可以接受的，那么你一定要把gzip关掉。
Gzipping需要大量的CPU资源。 所以，如果你更关心CPU而不是带宽，如果站点加载速度够快，并且ESI对你有很大的帮助，那么反向代理caching系统肯定比gzipping http响应更有好处。
在其他情况下，带宽至关重要，gzip可能更重要，但在这里似乎并不是这样。
最后，gzip可以通过一些反向代理来完成。 这是一个很大的可能性，因为反向代理通常不会使用太多的CPU（如果他们在一个单独的服务器上）。 这为后端节省了大量的CPU周期，并节省了带宽，但目前，如果我没有记错的话，Varnish不支持gzip。