動的圧縮を有効にする

動的圧縮を有効にすると、Cloud CDN から返されるレスポンスは自動的に圧縮されます。ネットワーク経由で送信されるデータのサイズは、通常のケースで 60%～85% 減少します。

サイズを縮小すると、コンテンツのダウンロードにかかる時間が短縮されます。スタイルシート（CSS）、スクリプト（JavaScript）、動画マニフェスト（HLS / DASH）などの重要なアセットの場合は、ページの読み込みにかかる時間や動画が開始するまでの時間を短縮できます。

レスポンスを圧縮する利点については、Web Fundamentals のガイドをご覧ください。

バックエンド サービスまたはバックエンド バケットで圧縮を有効にできます。

サンプル ユースケース

動的圧縮を使用すると、Cloud CDN のエッジからクライアントに送信されるデータのサイズが小さくなります。これにより、次のような結果になります。

  • CSS と JavaScript のサイズが縮小されます。これにより、ウェブページの表示を高速化し、重要なウェブ パフォーマンス指標である First Contentful Paint の時間を短縮できます。

  • JSON ペイロードなどの REST API レスポンスをキャッシュに保存する際に、大きな効果があります。これらのペイロードでは、キー、空白、波かっこが繰り返されているため、効果的に圧縮されます。公開 API を 5～10 秒間隔でキャッシュに保存すると、データの鮮度を保ちながら送信元の負荷を軽減できます。これは、よく使われている手法です。

    キャッシュに保存しなくても、これらのレスポンスを圧縮すると、合計で最大 90% のバイト数を削減できます。

  • 動画配信の再生開始時間とライブ ストリーミングの参加時のレイテンシが改善されます。サイズの大きいライブ再生リスト（マニフェスト）には繰り返しデータが大量に含まれています。たとえば、各セグメントのホスト + パス接頭辞、HLS または DASH 再生リスト メタデータなどが含まれています。再生リストの読み込みや再生リストの更新のダウンロードを高速に行うほど、クライアントが参照動画セグメントの解析とダウンロードを待機する時間が短くなります。多くの場合、HLS と DASH の再生リストの合計サイズは 90% 以上削減されます。

始める前に

次のように構成されていることを確認します。

  • Cloud CDN 対応バックエンドが構成されている。Cloud CDN を構成していない場合は、いずれかの設定ガイドの手順に沿って構成できます。
  • バックエンドには、1 KiB～10 MiB の配信可能な圧縮可能コンテンツ（ウェブアセットや動画マニフェストなど）が存在する。
  • クライアントが、範囲リクエストまたは強力な ETag を使って部分的なコンテンツを取得していない。これらは、動的圧縮に対応していません。
  • クライアントが、Content-Length ヘッダーなしでレスポンスを処理できる。たとえば、Cloud CDN が圧縮するキャッシュミスには Content-Length ヘッダーがありません。
  • バックエンドの構成を変更するために必要な IAM Compute ロードバランサ管理者ロール（roles/compute.loadBalancerAdmin）を持っている。

バックエンド サービスまたはバックエンド バケットで圧縮を有効にする

圧縮を有効にするには、次の手順を行います。

コンソール

新しい送信元を追加する

新しい送信元を追加して設定するには、バックエンドに適したタイプについて設定の概要の手順を行います。送信元を作成する場合は、[詳細オプション] セクションを使用し、[圧縮モード] リストで [自動] を選択して動的圧縮を構成します。

既存の送信元を編集する

既存の Cloud CDN 送信元を編集するには:

  1. Google Cloud コンソールで、Cloud CDN の [送信元] ページに移動します。

    Cloud CDN の [送信元] に移動

  2. 編集する送信元の名前をクリックし、[編集] をクリックします。

  3. [送信元の基本] セクションで、[次へ] をクリックします。

  4. [ホストとパスのルール] セクションで、[次へ] をクリックします。

  5. [キャッシュ パフォーマンス] セクションで、[詳細オプション] に移動します。

  6. [圧縮モード] リストで、[自動] を選択します。

  7. [完了] をクリックして変更を適用します。

gcloud

バックエンド サービスの場合は、gcloud compute backend-services create コマンドまたは gcloud compute backend-services update コマンドで --compression-mode フラグを使用します。

バックエンド バケットの場合は、gcloud compute backend-buckets create コマンドまたは gcloud compute backend-buckets update コマンドで --compression-mode フラグを使用します。

新しいバックエンド サービスの場合は、create コマンドを使用します。

gcloud compute backend-services create BACKEND_SERVICE_NAME \
    --compression-mode=AUTOMATIC

既存のバックエンド サービスの場合は、update コマンドを使用します。

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --compression-mode=AUTOMATIC

新しいバックエンド バケットの場合は、create コマンドを使用します。

gcloud compute backend-buckets create BACKEND_BUCKET_NAME
    --compression-mode=AUTOMATIC

既存のバックエンド バケットの場合は、update コマンドを使用します。

gcloud compute backend-buckets update BACKEND_BUCKET_NAME
    --compression-mode=AUTOMATIC

compression-mode は、以下のいずれかになります。

  • AUTOMATIC: クライアントから送信された Accept-Encoding ヘッダーに基づいて、最適な圧縮を自動的に使用します。ほとんどの場合、これにより Brotli の圧縮が優先されます。
  • DISABLED（デフォルト）: 圧縮を無効にします。

API

バックエンド サービスの場合は、backendServices.insert メソッドまたは backendServices.update メソッドを使用します。

バックエンド バケットの場合は、backendBuckets.insert メソッドまたは backendBuckets.update メソッドを使用します。

次のいずれかのコマンドを使用します。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices

PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET

JSON リクエストの本文に次のスニペットを追加します。

"compressionMode": AUTOMATIC

compression-mode は、以下のいずれかになります。

  • AUTOMATIC（推奨）: クライアントから送信された Accept-Encoding ヘッダーに基づいて、最適な圧縮を自動的に使用します。ほとんどの場合、これにより Brotli の圧縮が優先されます。
  • DISABLED（デフォルト）: 圧縮を無効にします。

数分以内に、構成がすべてのエッジ ロケーションに反映されます。バックエンドから配信される圧縮可能なコンテンツは、クライアントに配信される前に圧縮されます。

圧縮モード

デフォルトの圧縮モードは DISABLED です。

AUTOMATIC モードを使用すると、Cloud CDN は次の点に基づいて最適な圧縮方法を選択できます。

  • クライアントが使用できるエンコード
  • レスポンスの予想圧縮率
  • Cloud CDN の圧縮速度（スループット）

Brotli は gzip と比べて、ほとんどのコンテンツ タイプでダウンロード サイズをさらに 10～20% 削減できます。同様の解凍パフォーマンスにより、ダウンロード時間全体およびクライアントでの解凍速度を考慮すると全体的に高速化されます。

Cloud CDN は、レスポンスの Content-Encoding ヘッダーで、選択した圧縮方法を gzip または brotli として示します。

Cloud CDN は、クライアントの合計ダウンロード サイズと CPU コストのバランスを考慮して圧縮レベルを決定します。圧縮レベルが高くてもパフォーマンスが向上するとは限りません（特に性能の低いモバイル デバイスの場合）。

Cloud CDN は、最初にコンテンツを圧縮するときに、レスポンスから Content-Length ヘッダーを削除します。レスポンス全体が圧縮されるまでコンテンツの全体長は不明であるため、レスポンスをできるだけ早く配信するには、この処理が必要になります。レスポンスが圧縮され、キャッシュに保存されると、Cloud CDN の以降のレスポンスに Content-Length ヘッダーが含まれることがあります（HTTP/1.1 以前では、Cloud CDN のレスポンスで Content-Length が使用されない場合、Transfer-Encoding: chunked が使用されます）。

レスポンスが圧縮される場合

リクエストに gzip または Brotli アルゴリズムのサポートを明示的に示す Accept-Encoding ヘッダーがあり、バックエンド（送信元）から送られる非圧縮レスポンスの Content-Type ヘッダーが圧縮可能なコンテンツ タイプに対応している場合、このレスポンスは gzip または Brotli で圧縮されます。リクエストに Accept-Encoding ヘッダーがない場合、または Accept-Encoding: * ヘッダーがある場合、レスポンスは圧縮されません。

たとえば、クライアント リクエストに Accept-Encoding ヘッダーがある場合、次の表の情報に従ってレスポンスが圧縮されます（または圧縮されません）。

Accept-Encoding リクエスト ヘッダー レスポンス エンコード
gzip, compress, br Brotli（br）
deflate 非圧縮
deflate, gzip gzip
identity 非圧縮
* 非圧縮

圧縮可能なコンテンツ タイプ

動的圧縮は、Content-Type HTTP レスポンス ヘッダーに基づいて次の MIME タイプに適用されます。Content-Type レスポンス ヘッダーのないレスポンスは圧縮されません。

一般的なコンテンツ タイプとその MIME タイプは次のとおりです。

  • HTML コンテンツ: text/html
  • スタイルシート: text/css
  • JavaScript: application/javascript
  • JSON: application/json
  • HLS 再生リスト: application/x-mpegURL または application/vnd.apple.mpegURL
  • DASH マニフェスト: application/dash+xml

次の表に、MIME タイプが圧縮に及ぼす影響を示します。

  圧縮可能な MIME タイプ
完全一致 application/x-javascript
application/x-sdch-dictionary
application/javascript
application/xml
application/csv
application/json
application/json+protobuf
application/signed-exchange
application/vnd.apple.mpegurl
application/wasm
application/x-plist
application/x-protobuffer
application/x-protobuf
application/x-nacl
application/x-pnacl
font/ttf
font/otf
font/eot
image/svg+xml
image/pwg-raster
image/x-icon
image/vnd.microsoft.icon
video/vnd.mpeg.dash.mpd
audio/mpegURL
application/dash+xml
application/vnd.ms-sstr+xml
パターン一致 application/*+json
application/*+xml
application/*mpegURL
text/*

ほとんどの画像と動画の形式（image/jpeg、image/png、video/mpeg4 など）はすでに圧縮されているため、Cloud CDN では圧縮されません。すでに圧縮されたレスポンスを圧縮しても、ファイルサイズが小さくなることはほぼありません。このようなレスポンスを受信したときに、クライアントで予期しない動作が発生することがあります。

レスポンスが圧縮されない場合

動的圧縮では、次の 1 つ以上の特性を持つレスポンスは圧縮されません。

  • レスポンスに、圧縮可能なコンテンツ タイプに一致する Content-Type ヘッダーがない。
  • Content-Length ヘッダーがない。

  • 1 KiB 未満である。

    多くの場合、圧縮と解凍にかかる時間でメリットが相殺されます。また、圧縮できるコンテンツが少ないため、圧縮効果が低下し、圧縮率が低下する可能性があります。

  • 10 MiB を超える。

  • Cache-Control: no-transform ヘッダーがある。

  • Vary: Accept-Encoding ヘッダーがある。

範囲リクエスト

Cloud CDN でレスポンスが圧縮されると、Cloud CDN は Accept-Ranges: none ヘッダーを追加し、既存の Accept-Ranges ヘッダーを置き換えます。このようなレスポンスのキャッシュ ヒットは、Range ヘッダーを無視します。

これにより、圧縮または非圧縮形式のリソースからクライアントが想定するバイト範囲を予測する手段がなくなるため、クライアントに間違った部分的なコンテンツが配信されることを回避できます。

ETag

動的圧縮でレスポンスが圧縮されると、ETag ヘッダーの強度が低下します（RFC 7232 のセクション 2.3 を参照）。たとえば、ETag: "xyzzy" は ETag: W/"xyzzy" に置き換えられます。

Vary ヘッダー

リクエストに応じて圧縮される可能性のあるレスポンスが配信されると、Cloud CDN は Vary: Accept-Encoding ヘッダーをレスポンスに追加します。

レスポンスの変更の概要

次の表は、圧縮の発生時に Cloud CDN がレスポンスのヘッダーに加える変更をまとめたものです。

レスポンス ヘッダー 圧縮後のヘッダー値
Content-Encoding gzip または brotli に設定します。
ETag 強力なエンティティ タグは、弱いバージョン（接頭辞 W/ で示される）に置き換えられます。
Accept-Ranges none の値に設定します。
Content-Length 完全に削除されるか、圧縮された本文コンテンツがある場合は、その長さに設定されます。
Transfer-Encoding HTTP/1.1 以前のプロトコルの場合、Cloud CDN によって Content-Length が削除されると、このヘッダーが追加され、値が chunked に設定されて、レスポンスの本文が分割されます。

ロギング

Cloud CDN ログの jsonPayload には、レスポンスが圧縮とロードバランサによって圧縮されたかどうかを示す compressionStatus フィールドが含まれます。

{
  insertId: "1c02hw9g3gjay67"
  jsonPayload: {
    @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
    statusDetails: "response_sent_by_backend"
    cacheId: "IAD-862d661f"
    compressionStatus: "br"
  }
}

請求

Cloud CDN または Cloud Load Balancing によってレスポンスが圧縮されると、クライアントに送信される最終的な圧縮バイト数に対して、関連する送信キャッシュ データ転送または送信インターネット データ転送がそれぞれ測定されます。

圧縮可能なレスポンスが大量に送信されている場合、毎月の送信データ転送料金が減少し、エンドユーザーのパフォーマンスが向上する可能性があります。

指標

圧縮が有効になっている場合、loadbalancing.googleapis.com 下にある https/response_bytes_count 指標で圧縮レスポンス サイズが報告されます。

合計レスポンス バイト数（および送信データ転送スループット）が減少しているはずです。

圧縮率が高いテキストベースのコンテンツ（HTML、CSS、JavaScript、JSON など）を大量に配信すると、レスポンス バイト数が大幅に減少することがあります。

詳細については、モニタリングをご覧ください。

次のステップ