ナビゲーションをスキップ
部 IV 章 19

圧縮

Hero image of Web Almanac characters using a ray gun to shrink an HTML page to make it much smaller.

序章

HTTP圧縮を使用すると、ウェブサイトの読み込みが速くなるため、より良いユーザー体験が保証されます。HTTP圧縮を行わない場合は、ユーザー体験が低下し、関連するウェブサービスの成長率に影響を与え、検索ランキングにも影響を与えます。 圧縮を効果的に使用することで、ページウェイトを減らし、ウェブパフォーマンスを向上させることができるため、検索エンジン最適化の重要な部分となります。

画像やその他のmediaタイプでは非可逆圧縮を許容することが多いのですが、テキストの場合は可逆圧縮、つまり解凍後に正確なテキストを復元したいと考えています。

どのようなコンテンツを圧縮すべきか?

HTMLCSSJavaScript、JSON、SVGなどのほとんどのテキストベースのアセットや、woff、ttf、icoなどの特定の非テキストフォーマットについては、圧縮を使用することをオススメします。

図19.1. コンテンツタイプ別の圧縮方法

この図は、あるコンテンツタイプのレスポンスのうち、Brotli、Gzip、またはテキスト圧縮なしのいずれかを使用している割合を示しています。 驚くべきことに、すべてのコンテンツタイプで圧縮が有効であるにもかかわらず、その割合の範囲はコンテンツタイプごとに大きく異なっています。たとえば、text/htmlで圧縮を使用しているのはわずか44%であるのに対し、application/x-javascriptでは93%です。

画像ベースの資産では、テキストベースの圧縮はあまり役に立たず、広く採用されていません。データによると、BrotliやGzipを採用している画像レスポンスの割合は非常に低く、4%未満です。テキストベース以外のアセットの詳細については、メディアの章を参照してください。

図19.2. デスクトップ上の画像タイプの圧縮方法

HTTP圧縮はどのように使うのですか?

たとえば、HTMLMinifierCSSNanoUglifyJSなどの最小化ツールを使用できます。しかし、圧縮機能を使うことで、より大きな効果が期待できます。

サーバー側で圧縮を行うには2つの方法があります。

  • 事前圧縮(事前にアセットを圧縮して保存しておくこと)
  • 動的圧縮(リクエストがあったときに、その場でアセットを圧縮する)

事前に圧縮されているので、アセットの圧縮に時間をかけることができます。一方、動的に圧縮されたリソースの場合は、非圧縮ファイルと圧縮ファイルの送信時間の差よりも圧縮にかかる時間が短くなるように圧縮レベルを選択する必要があります。この違いは、両方式の推奨圧縮レベルを見るとよくわかります。

Brotli Gzip
事前圧縮 11 9かZopfli
動的圧縮 5 6
図19.3. 使用する推奨圧縮レベル

現在、実質的にすべてのテキスト圧縮は、2つのHTTPコンテンツエンコーディングのいずれかによって行われています。GzipBrotliです。どちらもブラウザで広くサポートされています。Brotliを使用できます/Gzipを使用できます

Gzipを使用したい場合は、より小さいGzip互換ファイルを生成するZopfliの使用を検討してください。これは、とくに圧縮済みのリソースに対して行うべきです。なぜなら、ここでは最大の利益が期待できるからです。Gzipの異なる圧縮レベルを考慮した GzipとZopfliの比較を参照してください。

多くの一般的なサーバは、動的および/または事前に圧縮されたHTTPをサポートしており、その多くがBrotliをサポートしています。

HTTP圧縮の現状

HTTPレスポンスの約60%は、テキストベースの圧縮を行わずに配信されています。これは驚くべき統計のように思われるかもしれませんが、データセット内のすべてのHTTPレスポンスに基づいていることを覚えておいてください。図19.2に示すように、画像などの一部のコンテンツは、これらの圧縮アルゴリズムの恩恵を受けないため、あまり使用されていません。

コンテンツのエンコード デスクトップ モバイル 組み合わせ
テキスト圧縮なし 60.06% 59.31% 59.67%
Gzip 30.82% 31.56% 31.21%
Brotli 9.10% 9.11% 9.11%
その他 0.02% 0.02% 0.02%
図19.4. 圧縮アルゴリズムの採用

圧縮されて提供されているリソースのうち、大部分はGzip(77%)またはBrotli(23%)のいずれかを使用しています。その他の圧縮アルゴリズムはあまり使用されていません。

図19.5. HTTPレスポンスの圧縮アルゴリズム。

下のグラフでは、上位11種類のコンテンツタイプが表示されており、ボックスの大きさは回答数の相対的な増減を表しています。各ボックスの色は、これらのリソースのうちどれだけが圧縮されて提供されたかを表しており、オレンジは圧縮の割合が低いことを、青は圧縮の割合が高いことを示しています。メディアコンテンツのほとんどがオレンジ色に塗られていますが、これはGzipやBrotliではほとんどメリットがないことから予想されます。 ほとんどのテキストコンテンツは、圧縮されていることを示すために青く塗られています。しかし、一部のコンテンツタイプの淡い水色は、他のコンテンツほど一貫して圧縮されていないことを示しています。

図19.6. デスクトップページのタイプ別圧縮

前述の図19.1では、コンテンツタイプごとの圧縮の割合を示していますが、図19.6では、この割合を色で表しています。この2つの図は似ており、非テキストベースのアセットはほとんど圧縮されておらず、テキストベースのアセットはよく圧縮されていることがわかります。また、圧縮率は、モバイルとデスクトップの両方で似ています。

ファーストパーティとサードパーティの圧縮

サードパーティの章では、サードパーティとそのパフォーマンスへの影響について学びます。サードパーティの使用は、圧縮にも影響します。

デスクトップ モバイル
コンテンツのエンコード ファースト・パーティ サードパーティ ファースト・パーティ サードパーティ
テキスト圧縮なし 61.93% 57.81% 60.36% 58.11%
Gzip 30.95% 30.66% 32.36% 30.65%
br 7.09% 11.51% 7.26% 11.22%
deflate 0.02% 0.01% 0.02% 0.01%
その他 / 無効 0.01% 0.01% 0.01% 0.01%
図19.7. デバイスタイプ別のファーストパーティ対サードパーティの圧縮率

ファーストパーティとサードパーティの圧縮技術を比較すると、サードパーティのコンテンツはファーストパーティのコンテンツよりも圧縮される傾向にあることがわかります。さらに、Brotliの圧縮率はサードパーティのコンテンツの方が高くなっています。これは、GoogleやFacebookなど、通常Brotliをサポートしている大規模なサードパーティから提供されるリソースの数が多いためと考えられます。

昨年の結果と比較すると、ファーストパーティでのBrotliを中心とした圧縮の使用が大幅に増加し、ファーストパーティとサードパーティ、デスクトップとモバイルの両方で圧縮の使用が約40%になっていることがわかります。しかし、圧縮を使用している回答のうち、ファーストパーティではBrotliの圧縮率はわずか18%、サードパーティでは27%となっています。

あなたのサイトの圧縮率を分析する方法

Firefox Developer ToolsまたはChrome DevToolsを使用すると、ウェブサイトがすでに圧縮しているコンテンツをすばやく把握できます。これを行うには、[ネットワーク]タブを開き、右クリックして[応答ヘッダー]の[コンテンツエンコード]を有効にします。個々のファイルのサイズにカーソルを合わせると、「ネットワークでの転送量」と「リソースサイズ」が表示されます。サイト全体で集計すると、Firefoxではサイズ/転送サイズ、Chromeでは「転送」と「リソース」がネットワークタブの左下に表示されます。

DevToolsを使用して、サイトでコンテンツのエンコーディングが使用されているかどうかを確認する
図19.8. DevToolsを使用して、サイトでコンテンツのエンコーディングが使用されているかどうかを確認する

また、サイトの圧縮について理解を深めるためのツールとして、GoogleのLighthouseというツールがあり、ウェブページに対して一連の監査を実行できます。テキスト圧縮監査では、サイトがテキストベースの圧縮を追加することで利益を得られるかどうかを評価します。この監査では、リソースの圧縮を試み、オブジェクトのサイズを少なくとも10%および1,400バイト削減できるかどうかを評価します。スコアに応じて、結果に圧縮の推奨事項が表示され、圧縮可能な特定のリソースのリストが表示されます。

HTTP Archive Lighthouseの監査を実施はモバイルページごとに行われるため、すべてのサイトのスコアを集計して、より多くのコンテンツを圧縮する機会がどれだけあるかを知ることができます。全体では74%のウェブサイトがこの監査に合格していますが、約13%のウェブサイトが40点以下のスコアを記録しています。これは、昨年の62.5%の合格スコアと比較すると、11.5%の改善となります。

図19.9. テキスト圧縮Lighthouseのスコア

結論

昨年のAlmanacと比較すると、より多くのテキスト圧縮を使用する傾向が明らかになっています。テキスト圧縮を一切使用していない回答は2%強減少し、同時にBrotliの使用が2%近く増加しています。Lighthouseのスコアは大幅に向上しました。

テキストの圧縮は、関連するフォーマットに広く使用されていますが、HTTPレスポンスの中には、さらなる圧縮を必要とするものがかなりの割合で存在しています。サーバーの設定をよく見て、必要に応じて圧縮方法やレベルを設定するとよいでしょう。もっとも一般的なHTTPサーバーのデフォルトを注意深く選択することで、よりポジティブなユーザー体験に大きな影響を与えることができます。

著者

  • Moritz Firsching
    Moritz Firschingは、Google Switzerlandのソフトウェアエンジニアで、プログレッシブ画像フォーマットとフォント圧縮に取り組んでいます。それ以前は、数学者としてポリトープの研究をしていました。
  • Luca Versari
    Luca Versariは、Googleのソフトウェアエンジニアで、JPEG XLの開発に携わっています。グラフ圧縮に関する博士号を取得中で、数学のバックグラウンドを持っています。
  • Sami Boukortt
    Samiは、工学数学の研究を終えてGoogleに入社しました。圧縮に遠隔で興味を持って数年後、最終的には2018年にフルタイムの仕事になりました。
  • Jyrki Alakuijala
    Jyrki Alakuijalaは、オープンソースソフトウェアコミュニティの活発なメンバーであり、データ圧縮の研究者でもあります。最近の研究テーマは、Zopfli、Butteraugli、Guetzli、Gipfeli、WebP lossless、Brotli、JPEG XLなどの圧縮フォーマットとアルゴリズム、およびCityHashとHighwayHashという2つのハッシュアルゴリズムです。Googleに入社する前は、神経外科や放射線治療の治療計画用ソフトウェアを開発していました。

引用

BibTeX
@inbook{WebAlmanac.2020.圧縮,
author = "Firsching、MoritzとVersari、LucaとBoukortt、SamiとAlakuijala、JyrkiとCalvano、PaulとTsai、AbbyとExterkamp、Shane",
title = "圧縮",
booktitle = "2020 Web Almanac",
chapter = 19,
publisher = "HTTP Archive",
year = "2020",
language = "日本語",
url = "https://almanac.httparchive.org/en/2020/compression"
}