圧縮率 (compression ratio) は、データ圧縮の効率を示す指標です。元のデータサイズを D、圧縮後のサイズを C とすると、日本語で「圧縮率 75%」と言うときは (1 - C/D) × 100% を指す用法があり、本文ではこの意味で使います。100KB のテキストファイルが 25KB に圧縮されれば、圧縮率は 75% ということになります。圧縮率が高いほど、より少ないストレージやネットワーク帯域でデータを扱えます。

やや厄介なのは、この語が 2 通りの意味で使われる点です。英語の compression ratio は D/C の比を指し、同じ例は「4:1」や「4 倍」と表現されます。一方の (1 - C/D) は英語では space savings (削減率) と呼び分けられます。日本語の記事や設定画面では両者が「圧縮率」に混ざるため、「圧縮率 25%」という表記が「4 分の 1 になった (75% 減)」を意味することもあります。数値だけを見て比べると桁を取り違えるので、判断の前に「減った割合か、サイズの比か」を確かめるのが確実です。圧縮ツールの設定にある「圧縮レベル」は、また別の軸で、時間をかけてより小さくするかの度合いを指します。

テキストデータは画像や動画と比べて圧縮率が高くなる傾向があります。自然言語のテキストには文字の出現頻度の偏り (英語では「e」が最頻出)、単語の繰り返し、定型的なフレーズなど、多くの冗長性が含まれているためです。日本語の場合、UTF-8 では漢字やかなが 1 文字 3 バイトになるため元のバイト数は膨らみますが、同じ 3 バイト列が何度も現れるので圧縮も効きやすく、圧縮後のサイズで英語に大きく劣るとは限りません。効き方を左右するのは言語よりも内容で、同じ語句や決まった書式がどれだけ繰り返されるかがほぼそのまま結果に出ます。数値が必要な場面では、配信する実データで測るのが唯一確実な方法です。

ウェブでは、HTTP レスポンスの gzip/Brotli 圧縮がテキストデータの転送量を大幅に削減します。HTML、CSS、JavaScript はすべてテキストデータであり、圧縮の恩恵が大きいファイル形式です。Brotli は gzip より小さく圧縮できる傾向があり、主要ブラウザが対応しています。ただし差の大きさは対象データと圧縮レベルで変わるので、どれだけ縮むかは自分が配信するファイルで両方試して比べるしかありません。10KB の HTML ファイルが 2.5KB になれば、転送するバイト数は 4 分の 1 です。転送時の圧縮は Content-Encoding ヘッダーで伝えられ、受け取ったブラウザ側が展開するため、保存してあるファイル自体を小さくする作業とは別物です。

テキスト圧縮のアルゴリズムは大きく 2 種類に分かれます。ハフマン符号化は文字の出現頻度に基づいて可変長のビット列を割り当てる方式で、頻出文字ほど短いビット列で表現します。LZ77/LZ78 系のアルゴリズムは、テキスト内の繰り返しパターンを検出し、「前に出現した位置と長さ」で参照する方式です。gzip は両者を組み合わせた DEFLATE アルゴリズムを使用しています。

文字数と圧縮率の関係は興味深い性質を持ちます。同じ文字数のテキストでも、内容によって圧縮率は大きく異なります。「ああああああああああ」(同じ文字の繰り返し) は極めて高い圧縮率になりますが、ランダムな文字列はほとんど圧縮できません。これは情報理論のエントロピー (情報量) の概念と直結しており、冗長性の高いテキストほど圧縮率が高くなります。

実務では、圧縮率はストレージ容量とネットワーク帯域の見積もりに直結します。ログファイルやチャット履歴は同じ書式が延々と繰り返されるため、テキストの中でも特に圧縮が効きやすい部類です。逆に、圧縮しても無駄になる場面を見分けることも重要になります。JPEG や PNG、動画、zip などは既に圧縮済みで、もう一度圧縮してもほとんど縮まず、わずかに大きくなることさえあります。数バイト程度の短いデータも同様で、圧縮形式そのものが持つヘッダーの分だけ膨らみます (2 バイトの文字列を gzip 形式にすると 20 バイト強になります)。効くのは「長く、繰り返しが多く、まだ圧縮されていない」データで、長文テキストの配信はその条件をよく満たします。