最大レベル11まで提供：Brotli圧縮とCompression Rulesの導入

CloudflareはSpeed Weekを通じて、パフォーマンスを最適化することの重要性について述べてきました。圧縮は、インターネット上で送信されるファイルサイズを小さくすることで、重要な役割を果たしています。ファイルサイズが小さくなると、ダウンロードが速くなり、Webサイトの読み込みが速くなり、ユーザーエクスペリエンスが向上します。

家庭用洗剤を実世界の例として挙げてみましょう。この洗剤は「一般的な洗剤のボトルは、90％が水で、実際の貴重な成分は10％以下である」と推定されます。一般的な500mlの家庭用洗剤の90％を取り除くと、重量は600gから60gに減ります。この削減は、使用者の受け取り時に水分を補給する指示とともに60gの小包だけを送付することを可能にします。ガロンに換算すると、この重量削減はビジネスにとって莫大な送料節約に直結し、環境への影響は言うまでもありません。

これが圧縮の仕組みです。送信者は、ファイルを可能な限り小さなサイズに圧縮し、受信時にそれをどのように扱うかを指示して、より小さなファイルを送信します。送信するファイルサイズを小さくすることで、インターネット上でファイルを送信するのに必要な帯域幅が大幅に削減されます。ファイルが AWSのような高価なクラウドプロバイダーに保存されている場合、送信されるファイルのサイズを小さくすることは、帯域幅における大幅なコスト削減につながります。

また、ファイルサイズが小さいことは、携帯通信ネットワーク上のモバイルデバイスやネットワーク速度が遅い地域のユーザーなど、インターネット接続が制限されているエンドユーザーにとって特に有益です。

Cloudflareは常にGzip形式の圧縮をサポートしてきました。Gzipは1992年から広く使われている圧縮アルゴリズムで、すべてのCloudflareユーザーにファイル圧縮を提供します。しかし、2013年にGoogleは、より高い圧縮レベルをサポートし、全体的なパフォーマンスを向上させるBrotliを導入しました。gzipからBrotliに切り替えると、ファイルサイズが小さくなり、Webページのロード時間が速くなります。Cloudflareとクライアントブラウザ間の接続においては、2017年からBrotliをサポートしています。本日、 Web コンテンツのエンドツーエンドでのBrotliのサポートを発表します。Brotli圧縮のサポートは、可能な限り高いレベルで、配信元サーバーからクライアントまで対応します。

オリジンサーバーのサポートがBrotliなら、機能を有効にし、圧縮レベルを上げて、パフォーマンスアップを楽しんでください。

11へのBrotli圧縮

Brotliには0から11までの12段階の圧縮レベルがあり、0は圧縮速度が最も速いが圧縮率が最も低く、11は圧縮率が最も高いが、より多くの計算リソースと時間を必要とします。5年前のBrotliの初期実装時に、 Cloudflareは圧縮レベル4がパフォーマンスを損なうことなく、保存バイト数と圧縮時間のバランスがとれていることを確認しました。

2017年以降、Cloudflare、エンドユーザーの「accept-encoding」ヘッダーに基づき、圧縮可能なすべてのアセットに対して最大圧縮率としてBrotliレベル4を使用しています。しかし、Cloudflare、オリジンがBrotliをサポートしていたとしても、オリジンからGzip圧縮しか要求されない場合があったり、さらに、Cloudflare、オリジンから受信したコンテンツを圧縮してエンドユーザーに送信する前に必ず解凍するため、処理時間が増えたりするという問題がありました。その結果、顧客はBrotli圧縮が提供するメリットを十分に活用することができませんでした。

以前の世界

CloudflareはBrotliをエンドツーエンドで完全にサポートするようになったため、お客様は更新されたaccept-encodingヘッダーがオリジンに到着するのを確認できるようになります。利用可能になると、お客様は、最大レベルの11まで、大きく圧縮されたBrotliファイルを直接転送、キャッシュ、提供することができます。これは、遅延と帯域幅の消費を削減するのに役立ちます。エンドユーザーデバイスがBrotli圧縮をサポートしない場合、当社は自動的にファイルを解凍し、Accept-Encodingヘッダーに応じて、解凍された形式またはGzip圧縮されたファイルとして提供します。

完全なエンドツーエンドのBrotli圧縮のサポート

エンドユーザー側でBrotli圧縮をサポートしていない場合

お客様は、適切なオンライン資料を参照して、オリジンでBrotli圧縮を実装できます。例えば、NGINXを使用しているお客様は、以下のチュートリアルに従ってBrotliを実装し、`nginx.conf`設定ファイル内で以下のように圧縮をレベル11に設定することができます。

brotli on;
brotli_comp_level 11;
brotli_static on;
brotli_types text/plain text/css application/javascript application/x-javascript text/xml 
application/xml application/xml+rss text/javascript image/x-icon 
image/vnd.microsoft.icon image/bmp image/svg+xml;

次に、Cloudflareは、一致するファイルbrotli_typesとまったく同じ圧縮レベル（11）で、これらのアセットをクライアントに提供します。つまり、SVGやBMPの画像はBrotliレベル11で圧縮されてクライアントに送信されます。

テスト

Cloudflareでは、単純なCSSファイルに対して圧縮を適用し、さまざまな圧縮アルゴリズムと圧縮レベルの影響を測定しました。私たちの目標は、圧縮技術を最適化することでユーザーが体験できる潜在的な改善点を特定することでした。これらの結果は、以下の表に示されています。

Brotliをレベル11で圧縮することで、ユーザーはファイルサイズを最高のGzip圧縮レベルと比較して19%小さくすることができます。さらに、最高のBrotli圧縮レベルは、 Cloudflareで使用されるデフォルトレベルより約18%小さくなります。これは、特に最高レベルのBrotli圧縮を利用することで達成される大幅なサイズ削減を強調するもので、Webサイトのパフォーマンス向上、ページのロード時間の短縮、エグレス料金の全体的な削減につながります。

より高いエンドツーエンドの圧縮率を利用するには、以下のCloudflareプロキシ機能を無効にする必要があります。

• メールの継続か
• Rocket Loader
• サーバー側の除外（SSE）
• Mirage
• HTML縮小 - JavaScriptとCSSは有効のままにしておくことができます。
• Automatic HTTPS Rewrites

これは、Cloudflareが、要求された設定を適用するために本体に解凍してアクセスする必要があるためです。また、Configuration Rulesを使用して、特定のパスに対してこれらの機能を無効にすることもできます。

これらの書き換え機能のいずれかが有効になっている場合でも、オリジンはより高いレベルでBrotli圧縮を送信することができます。しかし、ユーザーのaccept-encodingヘッダーに応じて、CloudflareのデフォルトのBrotliレベルを使用して、解凍し、Cloudflare機能を適用し、その場で再圧縮するか、4Gzipレベル8を使用してその場で再圧縮します。

Brotli圧縮を受け入れないブラウザに対しては、引き続き解凍してGzip圧縮または非圧縮の応答を送信します。

実装

オリジンからBrotliを実装するための最初のステップでは、 Cloudflare ソフトウェアスタックに統合可能な解凍モジュールを構築しました。これにより、オリジンから受け取った圧縮ビットを効率的に元の非圧縮ファイルに変換することができます。このステップは、Email Obfuscationや Cloudflare Workers Customersのような多くの機能は、カスタマイズを適用するためにレスポンスのボディにアクセスすることに依存しているため、非常に重要でした。

私たちは、解凍プログラムをCloudflareのコアリバースWebプロキシに統合しました。この統合により、Cloudflareのすべての製品と機能がBrotli解凍に簡単にアクセスできるようになりました。これにより、当社のCloudflare Workersチームは、BrotliをCloudflare Workersに直接組み込むことができ、当社のWorkersを利用中のお客様は、Brotliで返された応答と対話したり、そのままエンドユーザーに渡すことができるようになりました。

圧縮ルールの導入 - エンドユーザーへの圧縮のきめ細かな制御

デフォルトでCloudflareは、特定のコンテンツの種類を圧縮します。本日、Enterpriseのお客様向けにCompression Rulesも発表し、Cloudflareの圧縮方法と圧縮対象をさらに制御できるようになりました。

本日、Enterpriseのお客様向けにCompression Rulesを発表いたします。Compression Rulesでは、Cloudflareの圧縮機能の制御が強化され、どのコンテンツをCloudflareがどのように圧縮するかをカスタマイズして、Webサイトのパフォーマンスを最適化できます。

例えば、 .ktxファイル用にCloudflareのCompression Rulesを利用することで、WebGLアプリでのテクスチャ配信を最適化し、全体的なユーザーエクスペリエンスを向上させることができます。圧縮を有効にすることで、帯域幅の使用量を最小限に抑え、大きくて詳細なテクスチャを扱う場合でも、webGLアプリのロードが迅速かつスムーズになります。

また、圧縮を無効にしたり、圧縮方法を指定することもできます。別の例として、インフラストラクチャ企業が、 IoTデバイスでのみGzipをサポートしたいが、他のすべてのホスト名にはBrotli圧縮を許可したい場合があります。

圧縮ルールは、他のルール製品がメディアタイプとエクステンションタイプのフィールドを追加した上で構築されているフィルターを使用します。これにより、圧縮したいコンテンツを簡単に指定できます。

Brotliトグルの廃止

Brotliは、2016年以降、いくつかのWeb ブラウザで長い間サポートされてきており、Cloudflareは2017年にBrotliのサポートを開始しました。すべての新しいWebテクノロジーと同様に、Brotliは未知であり、私たちはAPIと私たちのUIを介して選択的にBrotliを有効または無効にできるようにしました。

Brotliが進化し、すべてのブラウザでサポートされるようになったため、今後数ヶ月のうちに、すべてのゾーンでBrotliをデフォルトで有効にする予定です。現在サポートしているGzipの動作をミラーリングし、ダッシュボードからトグルを削除します。ブラウザがBrotliをサポートしない場合、CloudflareはGzipや非圧縮などのエンコーディングタイプを引き続きサポートします。また、Enterpriseをご利用中のお客様は、圧縮ルールを使用して、ユーザーに対するデータの圧縮方法をきめ細かく制御することができます。

Web圧縮の未来

私たちは、 Webの新しい圧縮技術として、Brotliが大いに採用され、素晴らしいパフォーマンスを発揮していることを目の当たりにしてきました。今後、私たちは、zstdのような新しい圧縮アルゴリズムの動向を次世代の圧縮アルゴリズムとして注視しています。

同時に、Brotliで改善できる点に鋭意取り組んでいます。特に力を入れている開発のひとつが、Brotliの辞書共有です。この機能は、アセットを圧縮する際に「辞書」を使用して、圧縮をより効率的に行うことを可能にします。簡単に例えるなら、iPhoneのメッセージにOMWと入力するようなものです。iPhoneは内蔵辞書を使って自動的にOMWを「On My Way（今向かっています）」に翻訳します。

この内部辞書は、3つの文字を9つの文字（スペースを含む）に変換したもので、内蔵辞書には6文字が保存されており、ユーザーのパフォーマンス上のメリットを提供します。

デフォルトでは、Brotli RFCは、クライアントとオリジンサーバーの両方が使用する静的辞書を定義しています。この静的辞書は、汎用的で誰にでも適用できるように設計されており、辞書のサイズを大きすぎないように最適化することで、最良の圧縮結果を生成することができます。しかし、オリジンが特定のWebサイトに合わせた特注の辞書を生成できるとしたらどうでしょうか。例えば、Cloudflareに特化した辞書があれば、「Cloudflare」のようなサイト上に繰り返し現れる単語やフレーズを圧縮することができます。特注の辞書は、これを可能な限り大きく圧縮するように設計され、同じ辞書を使用するブラウザはこれを翻訳して返すことができます。

Web Incubator CGによる新しい提案はまさにそれを目指しており、Webサイトが圧縮をさらに最適化できるように、ブラウザが使用できる独自の辞書を指定できるようにします。私たちはこの提案に貢献し、近々研究結果を公表する予定です。

今すぐお試しください！

Compression Rulesは現在入手可能です！エンドツーエンドのBrotliは今後数週間の間に発表が予定されています。パフォーマンスを向上させ、帯域幅を削減し、Cloudflareがエンドユーザーに対してどのように圧縮を処理するかを細かく制御することができます。