6
Amazon CloudFrontからS3経由でgzip圧縮されたCSSおよびJavaScriptを提供する
私は自分のサイトの読み込みを速くする方法を探していましたが、探求したい1つの方法はCloudfrontをより活用することです。 CloudfrontはもともとカスタムオリジンCDNとして設計されておらず、gzip圧縮をサポートしていなかったため、これまでのところ、私のサイトコードでCloudfront cnameによって参照され、farで最適化されたすべての画像をホストしています。 -futuresヘッダー。 一方、CSSとjavascriptファイルは自分のサーバーでホストされています。これまで、Cloudfrontからgzipで提供することはできず、gzipによる利益（約75％）がそれよりも大きいという印象がありました。 CDN（約50％）の使用から：Amazon S3（およびCloudfront）は、gzip圧縮のサポートを示すためにブラウザーから送信されるHTTP Accept-Encodingヘッダーを使用して、標準的な方法でgzip圧縮されたコンテンツの提供をサポートしませんでした。そのため、Gzipを実行してコンポーネントをその場で提供することができませんでした。 したがって、私は今まで、2つの選択肢から選択する必要があるという印象を受けていました。 すべてのアセットをAmazon CloudFrontに移動し、GZippingを忘れます。 コンポーネントを自己ホストし、受信リクエストを検出し、必要に応じてオンザフライのGZippingを実行するようにサーバーを構成します。これは、これまでのところ私が選択した方法です。 この問題を解決するための回避策はありましたが、基本的にこれらは機能しませんでした。[ リンク ]。 現在、Amazon Cloudfrontはカスタムオリジンをサポートしているようです。カスタムオリジン [ リンク ] を使用している場合、gzip圧縮されたコンテンツを提供するために標準のHTTP Accept-Encodingメソッドを使用できるようになりました。 今のところ、サーバーに新機能を実装することはできません。上記にリンクしたブログ投稿は、変更の詳細を確認した唯一の記事ですが、カスタムオリジンを選択した場合、gzip圧縮（バーの回避策、私は使用しない）のみを有効にできることを意味しているようです。どちらかといえば、Cloudfrontサーバーで対応するフィールドをホストし、そこからリンクする方が簡単だと思います。ドキュメントを注意深く読んだにもかかわらず、私は知りません： 新しい機能が、ファイルがカスタムオリジンを介して自分のドメインサーバーでホストされる必要があることを意味するかどうか。 cssおよびjavascriptヘッダーを構成して、Cloudfrontからgzipで提供されるようにする方法。