我有一个在 Ruby on Rails 上运行的大部分静态站点，它使用 Varnish 反向代理缓存来节省对 Rails 后端的点击。
问题是用户可以登录网站，当他们登录时，我们使用 ESI（边缘侧包含）向用户显示页面的特定部分。
使用 ESI 意味着我们必须在 Rails 后端（使用 Nginx+passenger）禁用 Gzip 压缩，否则 varnish 无法解析从后端返回的数据以运行 ESI 处理。
我的问题是，使用反向代理缓存的好处是否大于对所有内容进行 gzip 压缩的好处？或者我应该尝试完全摆脱 ESI 并兼顾两全其美？
答案1
如果你按照如下方式安排，你就可以两全其美：
用户 -> nginx -> Varnish -> Rails
从 nginx 到用户启用 gzip 压缩。这是最慢的部分，也是最昂贵的部分。我假设您的 nginx、Varnish 和 Rails 实例彼此本地。您的本地带宽应该足够了。此外，仅使用 gzip 进行解压缩以组装 ESI 也没有太大意义。
答案2
如果带宽不是问题，并且不使用 gzip 的加载时间也可以接受，那么您绝对应该关闭 gzip。
Gzip 压缩会占用大量 CPU 资源。因此，如果您更关心 CPU 而不是带宽，如果网站加载速度足够快，并且 ESI 对您有很大帮助，那么反向代理缓存系统肯定比 gzip 压缩 http 响应更有优势。
在其他情况下，当带宽至关重要时，gzip 可能更为重要，但在这里似乎并非如此。
最后，一些反向代理可以进行 gzip 压缩。这是非常有可能的，因为反向代理通常不会使用太多 CPU（如果它们位于单独的服务器上）。这为后端节省了大量 CPU 周期，也节省了带宽，但目前，如果我没记错的话，Varnish 不支持 gzip 压缩。