コンテンツのgzip圧縮バージョンのみを提供する場合、さまざまな受け入れエンコーディングヘッダーを追加する必要がありますか?


11

静的サイトをVPSからAmazon S3に移動しました。S3はWebサーバーではないため、ヘッダーに基づくロジックを使用できないため、ページのgzip圧縮バージョンのみを提供することにしました。CloudfrontをCDNとしても使用しています。

http://gtmetrix.com/で自分のページをテストしていましたが、を追加していないため、悪いメモを受け取りましたvary accept encoding header。だから私はこれが何であるかを確認しました、そして私が理解している限り、私たちが圧縮バージョンと非圧縮バージョンの両方を提供するときに理にかなっています。

ですから、これを明確にする手助けをしてください。追加しますか?ありがとう:)

回答:


7

ページのgzip圧縮されたバージョンのみを提供することにしました

gzipを使用して圧縮したファイルのみを提供する場合、HTTPリクエストでVary: Accept-Encoding送信しないクライアントに提供するためにファイルの非圧縮コピーがないため、使用してもメリットはありません。最近のほとんどのクライアントはこれを送信するので、大丈夫です。Accept-Encoding: gzip

オンラインのWebサイトのパフォーマンステストでは、圧縮ファイルのみを提供していることはわかりません。また、フールプルーフでもありません。たとえば、使用したサービスでは、これらの列がのラベルが付いた列にリストされているRECOMMENDATIONため、このような提案を(実際に行ったように)気を付けて実装しようとする前に、何らかの事実調査を行うことをお勧めします。


私が付け加えたいのは、私の疑問がこの投稿から来たことです:maxcdn.com/blog/accept-encoding-its-vary-important
Kev

大丈夫だよ。その記事ではVary: Accept-Encoding、CDN を使用したオリジンサーバーでの使用について説明しています。あなたが指摘したように、あなたのオリジンサーバはこれを提供しません、それはグーグルによるので、もはや本当に必要だ、ここでAll modern browsers support and automatically negotiate gzip compression for all HTTP requests.そこで彼らは、使用することをお勧めしGZIPを、すべてのサイトで。その記事(2013年These days you're unlikely to have clients without compression, but why risk cache mixups?
ダン

1
ただし、圧縮ファイルのみを提供しているため、「キャッシュミックスアップ」(つまり、同じファイルの非圧縮バージョンからのもの)は状況に適用されません。
ダン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.