サイトの読み込みを高速化する方法を探していましたが、探求したい方法の 1 つは、Cloudfront をさらに活用することです。
Cloudfront はもともとカスタム オリジン CDN として設計されておらず、gzip をサポートしていなかったため、これまですべてのイメージをホストするために Cloudfront を使用してきました。これらのイメージは、サイト コードで Cloudfront cname によって参照され、はるかに最適化されています。 -先物ヘッダー。
一方、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 形式で配信されるようにする方法。