以下 3 个条目来自 gtmetrix.com 报告。对于 Amazon S3，我应该如何处理这些文件的压缩性能？我知道如何为 S3 做 gzip。但下面的三个文件呈现出更严格的情况。
我无权访问 mailchimp 的 css 文件。在这种情况下，有没有办法获得更好的压缩性能？
我会定期更新我的论文主题，这将更改如下所示的 css.css 文件。我无法对该文件进行版本控制，因为我需要使用名称 css.css。有什么技术可以处理这种情况吗？
压缩http://www.mysite.com/wp-content/thesis/skins/classic/css.css可以节省 20.5KiB（减少 79%）
压缩http://cdn-images.mailchimp.com/embedcode/slim-041711.css可以节省 1.1KiB（减少 60%）
压缩http://www.mysite.com/wp-includes/js/comment-reply.min.js?ver=3.5.1可以节省 374B（减少 48%
是的，这是一个很常见的问题。mod_deflate如果您从传统的 HTTP 守护程序（如 Apache）提供静态文件，则内容实际上是通过--it 透明地 gzip 文件并设置适当的标头来即时压缩的Content-Encoding。
如果您想在 S3 上执行此操作，则必须在上传文件之前手动 gzip 文件（通常命名为cool-stylesheet.gz.css），然后Content-Encoding在 S3 对象上设置自定义属性，如下所示：
手动执行此操作可能很乏味，因此我们实际上将其作为持续集成构建过程的一部分自动执行。我们的源代码控制中的一个提交后挂钩会触发，执行几个构建步骤（包括这个），然后将生成的文件部署到适当的环境中。
您似乎打算描述 Cloudfront 的问题，而不是 S3。由于 Cloudfront 是一个 CDN，它会在其边缘位置缓存文件，因此您必须强制它在文件更改时重新获取文件的最新版本。有两种方法可以做到这一点：使缓存无效或使用文件名版本控制。
使缓存失效很慢并且可能会变得非常昂贵。在每月前 1,000 个无效请求之后，此后每 10 个无效文件将花费 5 美分。
更好的选择是在文件名被拉入 Cloudfront之前通过附加一个唯一标识符来对文件名进行版本控制。我们通常使用文件上次更新时的 Unix 纪元。就这样cool-stylesheet.gz.css变成了cool-stylesheet_1363872846.gz.css。然后在 HTML 文档中像往常一样引用它：<link rel="stylesheet" type="text/css" href="cool-stylesheet_1363872846.gz.css">当用户打开更新的 HTML 文档时，这将导致 Cloudfront 从您的源重新获取更新的文件。
正如我上面提到的关于 S3 的那样，手动执行这也是一件乏味的事情：您必须重命名所有文件并在源 HTML 文档中搜索/替换对它们的所有引用。将其作为 CI 构建过程的一部分更有意义。但是，如果您不使用 CI 服务器，则可以使用源存储库中的提交挂钩来执行此操作。