CSS/JS 文件未获得 GZIPed [Amazon CloudFront] - 启用“自动压缩对象”

Posted 2023-03-27

【中文标题】CSS/JS 文件未获得 GZIPed [Amazon CloudFront] - 启用“自动压缩对象”

【英文标题】：CSS/JS files are not getting GZIPed [Amazon CloudFront] - "Compress Objects Automatically" enabled

【发布时间】：2017-09-19 23:35:30

【问题描述】：

我启用了 Amazon CloudFront gzip 功能：“Compress Objects Automatically”。

这发生在我的 CloudFront 中的所有文件上，而其他 CSS/JS 文件作为 gzip 加载（仔细检查我的服务器请求标头是否接受 gzip 文件Accept-Encoding: gzip）。

我真的很想弄清楚这一点，因为所有教程和谷歌搜索结果都对如何检查单选按钮“自动压缩对象”给出了相同的解释——这显然没有帮助。

我想也许我不能 gzip 文件，因为它们太小而无法压缩 - 但是遵循 google speed test 明确表示我可以使用 gzip 压缩这些文件。

Compressing https://Cloudfront.cloudfront.net/live/static/rcss/bootstrap.min.css could save 100.3KiB (83% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/rcss/style.css could save 60.5KiB (80% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/shop/css/jquery.range.css could save 4.6KiB (83% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/rcss/font-awesome.min.css could save 21.9KiB (77% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/rcss/responsive.css could save 20KiB (80% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/general.min.js?ver=9.70 could save 232.9KiB (72% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/rcss/magnific-popup.css could save 5.7KiB (75% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/bootstrap.min.js could save 26.4KiB (73% reduction).
Compressing https://Cloudfront.cloudfront.net/…ve/static/plugins/jquery.validate.min.js could save 14KiB (67% reduction).
Compressing https://Cloudfront.cloudfront.net/…tic/plugins/jquery.magnific-popup.min.js could save 13.2KiB (63% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/plugins/jquery.range.min.js could save 3.9KiB (66% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/voting/jquery.cookie.js could save 1.2KiB (53% reduction).

我缺少哪些部分可以帮助我使用 Cloudfront 压缩文件？

这是我的响应标头的样子：

Accept-Ranges:bytes
Cache-Control:max-age=0
Connection:keep-alive
Content-Length:122540
Content-Type:text/css
Date:Sun, 23 Apr 2017 13:14:07 GMT
ETag:"2cb56af0a65d6ac432b906d085183457"
Last-Modified:Tue, 02 Aug 2016 08:49:54 GMT
Server:AmazonS3
Via:1.1 2cb56af0a65d6ac432b906d085183457.cloudfront.net (CloudFront)
X-Amz-Cf-Id:eCPcSDedADnqDZMlMbFjj08asdBSn7_lfR0imlXAT181Y8qRMtSZASDF27AiSTK8PDQ==
x-amz-meta-s3cmd-attrs:uid:123/gname:ubuntu/uname:ubuntu/gid:666/mode:666/mtime:666/atime:666/md5:2cb56af0a65d6ac432b906d085183457/ctime:666
X-Cache:RefreshHit from cloudfront

编辑：

我理解在 200 和 304 上返回的概念 - 当删除浏览器缓存时，它总是显示 200 响应。

所以 Cloudfront 有一些缓存？我将 bootstrap3.min.css 文件添加到“无效”表中 - 没有用。

确保文件设置为压缩。

将此添加到我的 website.com.conf 文件以启用 gzip 并显示 content-length 标头：

DeflateBufferSize 8096
SetOutputFilter DEFLATE
DeflateCompressionLevel 9

尝试从我的 .conf 文件中删除 DeflateBufferSize 8096 并将 <AllowedHeader>Content-Length</AllowedHeader> 添加到“CORS 配置”中 - 我确实得到了 Content-Length 正确 - 但仍然没有 GZIPed。 （关注CloudFront with S3 website as origin is not serving gzipped files）

这是我目前得到的：

Request URL:https://abc.cloudfront.net/live/static/rcss/bootstrap3.min.css
Request Method:GET
Status Code:200 OK
Remote Address:77.77.77.77:443
Referrer Policy:no-referrer-when-downgrade

Response Headers
Accept-Ranges:bytes
Age:1479
Connection:keep-alive
Content-Length:122555
Content-Type:text/css
Date:Wed, 26 Apr 2017 08:48:34 GMT
ETag:"83527e410cd3fff5bd1e4aab253910b2"
Last-Modified:Wed, 26 Apr 2017 08:43:05 GMT
Server:AmazonS3
Via:1.1 5fc044210ebc4ac6efddab8b0bf5a686.cloudfront.net (CloudFront)
X-Amz-Cf-Id:3ZBgDY0c1WV_Pc0o_Bjwa5cQ9D9T-Cr30QDxd_GvD30iQ8W1ImReQIH==
X-Cache:Hit from cloudfront

Request Headers
Accept:text/css,*/*;q=0.1
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:keep-alive
Host:abc.cloudfront.net
Pragma:no-cache
Referer:https://example.com/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (Khtml, like Gecko) Chrome/58.0.3029.81 Safari/537.36

编辑#2：

关注：http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html

如果您将 CloudFront 配置为压缩内容，CloudFront 会从它压缩的文件中删除 ETag 响应标头。当 ETag 标头存在时，CloudFront 和您的源可以使用它来确定 CloudFront 边缘缓存中的文件版本是否与源服务器上的版本相同。但是，压缩后两个版本不再相同。

我得到相同的 Etag 含义 - 提供的 css 文件没有经过任何压缩。 想也许我没有为这个特定文件设置正确的压缩 - 现在设置为 */bootstrap3.min.css（因为它在目录中）。 我之前有这套 bootstrap3.min.css 两者都不起作用。

我的网址是：https://abc.cloudfront.net/live/static/rcss/bootstrap3.min.css 在此之后，我将我的失效部分编辑为：

/live/static/rcss/bootstrap3.min.css
/static/rcss/bootstrap3.min.css
/rcss/bootstrap3.min.css
/bootstrap3.min.css

这可能是我的实际问题吗？

【问题讨论】：

我启用了 Amazon S3 gzip 功能：“自动压缩对象”。 嗯……不，你没有……因为 S3 没有这样的选项。这是 CloudFront 的功能，而不是 S3。请提供一个无法按预期工作的 URL 的真实示例，因为显然“s3.cloudfront.net”没有意义。

@Michael-sqlbot 对不起！我的意思是 CloudFront！ （现在好累）我跟着这个教程：deliciousbrains.com/wp-offload-s3/doc/…

P.S：我不喜欢展示真实 URL 的实际示例。 @Michael-sqlbot

@Michael-sqlbot 可能设置DeflateBufferSize 8096 是我的问题？我添加了这个以获得Content-Length，因为我没有得到它。我应该遵循这个吗？ ***.com/questions/35590622/…

我确实将Content-Length 行添加到了CORS 文件中，并从我的my-website.conf 文件中删除了DeflateBufferSize 8096。它确实显示了Content-Length，但仍然不起作用。

【参考方案1】：

X-Cache: RefreshHit from cloudfront

这意味着 CloudFront 使用 If-Modified-Since 等条件请求检查了源，响应为 304 Not Modified，表明源服务器 (S3) 上的内容与 CloudFront 最初缓存资源时的内容相比没有变化，因此它提供了服务缓存中的副本。

...可能在您启用“自动压缩对象”之前已缓存。

如果您考虑一下，CloudFront 只在对象从源端进入时压缩它们会更有效，而不是在它们离开查看器时压缩，因此它已经拥有的文件永远不会被压缩。

这是记录在案的：

CloudFront 在从您的源获取文件时会压缩每个边缘站点中的文件。当您将 CloudFront 配置为压缩您的内容时，它不会压缩边缘站点中已有的文件。此外，当文件在边缘站点中过期并且 CloudFront 将对该文件的另一个请求转发到您的源时，如果您的源返回 HTTP 状态代码 304，则 CloudFront 不会压缩文件，这意味着边缘站点已经有文件的最新版本。如果您希望 CloudFront 压缩边缘站点中已有的文件，则需要使这些文件无效。

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html

所以* 的缓存失效是为了清除未压缩的版本。

但是等等……在同一页面上，似乎有相互矛盾的信息：

注意

如果 CloudFront 在缓存中有未压缩版本的文件，它仍会将请求转发到源。

鉴于上述信息，这似乎存在差异。但是，我相信这里的问题是一些不言而喻的假设之一。此信息很可能仅适用于为响应未发送Accept-Encoding: gzip 的查看器而缓存的未压缩副本，在这种情况下，CloudFront 的正确行为是独立缓存压缩和未压缩响应，如果没有可用的对象的压缩副本并且查看器表明它可以支持使用 gzip 压缩的对象，则联系源头，无论未压缩的副本是否已作为来自未做广告的浏览器的请求而被存储gzip 支持。

或者，它可以解释为 CloudFront 确实仍然发送了一个请求，但由于响应是 304，它提供了缓存副本，尽管它是未压缩的。

Invalidate your cache，然后等待失效表明它已完成，然后重试。这应该是纠正此行为所需的全部内容。

【讨论】：

我编辑了我的主要帖子（直到我写了“编辑：”，你能不能复习一下 - 我做了你所说的一切，并给出了我的回复的完整输出。

【参考方案2】：

这可能是因为 S3 没有发送所需的 Content-Length 标头响应。

查看此答案了解更多详情：https://***.com/a/42448222/4005566