如何从 Amazon S3 的外部文件中获得更好的压缩性能？

Question

以下 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%

Answer 1

是的，这是一个很常见的问题。如果您从传统的 HTTP 守护程序（如 Apache）提供静态文件，内容实际上是通过 mod_deflate 即时压缩的——它透明地 gzip 文件并设置适当的 Content-Encoding 标头。

如果您想在 S3 之外执行此操作，则必须在上传文件之前手动 gzip 文件（通常命名为 cool-stylesheet.gz.css），然后在 S3 对象上设置自定义 Content-Encoding 属性，如下所示：

手动执行此操作可能很乏味，因此我们实际上将其作为持续集成构建过程的一部分自动执行。我们的源代码控制中的一个提交后挂钩会触发，执行几个构建步骤（包括这个），然后将生成的文件部署到适当的环境中。

编辑：

您似乎是要描述 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 服务器，则可以使用源存储库中的提交挂钩来执行此操作。