動的圧縮を有効にする

動的圧縮を有効にすると、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）を持っている。

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

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

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

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

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

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

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

"compressionMode": AUTOMATIC

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

圧縮モード

デフォルトの圧縮モードは 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 ヘッダーがある場合、次の表の情報に従ってレスポンスが圧縮されます（または圧縮されません）。

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

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

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

• HTML コンテンツ: text/html
• スタイルシート: text/css
• JavaScript: application/javascript
• JSON: application/json