インフラ担当の森井康平です。 「Web エンジニアなら知っておきたい」シリーズということで、今回は「HTTPの圧縮」について紹介します。 HTTP圧縮は古くからある技術ですが、今でもパフォマーンス改善やトラブルシューティングに役立ちます。
HTTP圧縮とは
HTTP圧縮は、サーバーがレスポンスを圧縮し、クライアントがそれを伸長する仕組みで、主にWebサイトのパフォーマンス向上を目的として使用されます。通常、CDNやWebサーバーの設定によって簡単に導入できます。
HTTP圧縮を利用することでレスポンスのデータサイズを削減することができます。データサイズが小さくなることにより配信速度が向上し、サーバー側の帯域使用量の削減や、クライアント側の通信量の削減といった利点も得られます。
ただし、圧縮や伸長にはCPUやメモリなどのリソースを消費し、それ自体に処理時間を必要とするため、すべてのデータに一律で適用すべきではありません。
例えば、PDFやPNGなどはすでに圧縮されているファイル形式であるため、サーバー上で圧縮してもデータサイズの削減効果が低いです。 圧縮の効果が高い、テキストベースのデータ(HTML、CSS、JavaScriptなど)に対して適用するのが効果的だとされています。
圧縮形式
圧縮に使用する形式はgzipが一般的です。
また、最近はBrotliという圧縮形式も人気があります。これはGoogle によって開発されたもので、gzipよりも圧縮率が高いことを謳っています。
HTTP圧縮の流れ
HTTP圧縮が提供される流れは以下のようになります。
- クライアントはリクエストに
Accept-Encoding
ヘッダーを付与し使用できる圧縮形式をサーバーに伝えます。今回はgzip
、Brotli
の両方が使えることを示しています。 - サーバーは圧縮するかどうかを決定します。圧縮する場合は
Accept-Encoding
の中から使用する圧縮形式を決定します。 - サーバーはレスポンスを圧縮します。今回は圧縮形式として
gzip
が選択されました。 - サーバーは
Content-Encoding
ヘッダーでgzip
で圧縮したことを示して、レスポンスします。 - クライアントは
Content-Encoding
ヘッダーを読み、gzip
でレスポンスを伸長します。
HTTP圧縮の実装方法
HTTP圧縮をWebサイトに実装する方法を紹介します。 HTTP圧縮はCDNまたはWebサーバーを使用することが一般的です。 冒頭でお伝えした通り簡単に設定できますが、その自由度には違いがあります。
Webサーバーでの圧縮
アプリケーションサーバーの前段にWebサーバーを配置し、そこでHTTP圧縮を行うことができます。
設定例:Nginx
Webサーバーでの設定例としてNginxを見てみましょう。
Ngninxにおいてgzip圧縮はngx_http_gzip_module
を使用して実現できます。
以下のようにnginx.confに記載することで設定できます。
gzip on; gzip_min_length 1000; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain application/xml;
CDNでの圧縮
オリジンサーバーの前段にCDNを配置し、そこでHTTP圧縮をおこなうことができます。 CDNでのHTTP圧縮は静的コンテンツ配信でも動的コンテンツ配信でも利用できますが、特に静的コンテンツ配信の場合にCDNでHTTP圧縮をおこなうことが多いと思います。
設定例:CloudFront
CDNでの設定例として、CloudFrontを見てみましょう。
CloudFrontでHTTP圧縮を有効化するには、オブジェクトを自動的に圧縮
をYes
に設定し、キャッシュポリシーをCachingOptimized
などに設定するだけです。
Nginxでは細かく設定できていたのに、CloudFrontでは設定できる項目が少ないことにお気づきでしょうか。 CloudFrontでHTTP圧縮をおこなうかどうかの条件は仕様として決まっており、これは公式ドキュメントの「CloudFront がオブジェクトを圧縮する場合」という項目に記載されています。 どのような条件で圧縮されるかどうかを知りたい場合はこちらを確認してください。
圧縮ファイルを供給する - Amazon CloudFront
おわりに
今回はHTTP圧縮について紹介しました。 HTTP圧縮を活用し、軽快なWeb配信を実現しましょう。 この記事が参考になれば幸いです。