Revision 1130621 of HTTP の圧縮

<div>{{HTTPSidebar}}</div>

<p class="summary"><strong>圧縮</strong>は、ウェブサイトのパフォーマンスを向上させるための重要な手段です。ドキュメントによっては、必要な帯域を最大 70% 削減するほどサイズが縮減します。長年かけてアルゴリズムはより効率的になり、またクライアントおよびサーバーが新たなアルゴリズムをサポートしました。</p>

<p>実際のところ、圧縮の仕組みはブラウザーやサーバーがすでに実装していますので、ウェブ開発者が実装する必要性はありません。しかし、サーバーが適切に設定されるように注意しなければなりません。圧縮は、3 種類の異なるレベルで実施します:</p>

<ul>
 <li>始めに、一部のファイル形式は、固有の最適化された方法で圧縮されます。</li>
 <li>そして、一般的な暗号化が HTTP レベルで行われれる場合があります (リソースはエンドツーエンドで圧縮されて転送されます)</li>
 <li>最後に HTTP コネクションの 2 つのノード間で、コネクションレベルで圧縮が定義される場合があります。</li>
</ul>

<h2 id="File_format_compression" name="File_format_compression">ファイル形式の圧縮</h2>

<p>それぞれのデータ形式には、<em>{{Gengoheiki("無駄なスペース", "wasted space")}}</em> と呼ばれる冗長な領域が内部にあります。テキストが一般的に 60% もの冗長性を持つのであれば、この割合は音声や動画といった他のメディアよりはるかに高くなります。これらのメディア形式はテキストとは異なり、保存するために多くの領域を占めており、早期に無駄なスペースを取り戻すことが必要です。技術者は特定の用途向けに設計されたファイル形式で使用される、最適化された圧縮アルゴリズムを設計しました。メディアファイルで使用される圧縮アルゴリズムは、大きく 2 つのカテゴリーに分類できます:</p>

<ul>
 <li><em>可逆圧縮</em>。圧縮・展開のサイクルで取り出したデータは変化しません。これは元のデータに (バイト単位で) 一致します。<br />
  画像では <code>gif</code> や <code>png</code> が可逆圧縮を使用しています。</li>
 <li><em>非可逆圧縮</em>。圧縮・展開のサイクルで、ユーザーが感知できない方法で元のデータを変更します。<br />
  ウェブ上の動画形式や <code>jpeg</code> 画像で使用されています。</li>
</ul>

<p><code>webp</code> のように可逆圧縮と非可逆圧縮のいずれかを使用できる形式もありますが、通常は非可逆圧縮で高圧縮・低圧縮を設定でき、当然ながらそれは品質の高低に結びつきます。サイトのパフォーマンスを高めるには、満足できる品質レベルを維持しながら、できるだけ圧縮することが理想です。画像の場合は、ツールが生成する画像はウェブ向けに十分最適化されていない場合があります。要求する品質で可能な限り圧縮するツールを使用することをお勧めします。この用途に特化した <a href="https://www.creativebloq.com/design/image-compression-tools-1132865">多くのツール</a> があります。</p>

<p>非可逆圧縮アルゴリズムは一般的に、可逆圧縮より効率がよくなります。</p>

<div class="note">
<p>特定の種類のファイルは圧縮が良好に機能しているため、通常は 2 度目の圧縮を行いません。実際のところ、大きなファイルの圧縮によって得られる追加の利益よりもオーバーヘッド (アルゴリズムは一般的に、初期のサイズに追加する辞書が必要です) のコストが上回る場合があります。圧縮済み形式のファイルで、以下の2つの技術は使用しないでください。</p>
</div>

<h2 id="End-to-end_compression" name="End-to-end_compression">エンドツーエンドの圧縮</h2>

<p>エンドツーエンドの圧縮は、ウェブサイトのパフォーマンスをもっとも向上させます。エンドツーエンドの圧縮は、サーバーによって行われるメッセージボディの圧縮を指しており、圧縮されたデータはクライアントに到達するまで変更されません。中間のノードはすべて、ボディ部分に手をつけないままにします。</p>

<p><img alt="" src="https://mdn.mozillademos.org/files/13801/HTTPEnco1.png" style="height:307px; width:955px" /></p>

<p>All modern browsers and servers do support it and the only thing to negotiate is the compression algorithm to use. These algorithm are optimized for text. In the 1990s, compression technology was advancing at a rapid pace and numerous successive algorithms have been added to the set of possible choices. Nowadays, only two are relevant: <code>gzip</code>, the most common one, and <code>br</code> the new challenger.</p>

<p>To select the algorithm to use, browsers and servers use <a href="/ja/docs/Web/HTTP/Content_negotiation">proactive content negotiation</a>. The browser sends an {{HTTPHeader("Accept-Encoding")}} header with the algorithm it supports and its order of precedence, the server picks one, uses it to compress the body of the response and uses the {{HTTPHeader("Content-Encoding")}} header to tell the browser the algorithm it has chosen. As content negotiation has been used to chose a representation based on its encoding, a {{HTTPHeader("Vary")}} header containing at least {{HTTPHeader("Content-Encoding")}} must be sent alongside this header in the response; that way, cache will be able to cache the different representations of the resource.</p>

<p><img alt="" src="https://mdn.mozillademos.org/files/13811/HTTPCompression1.png" style="height:307px; width:771px" /></p>

<p>As compression brings significant performance improvements, it is recommended to activate it for all files, but already compressed ones like images, audio files and videos.</p>

<p>Apache supports compression and uses <a href="https://httpd.apache.org/docs/current/mod/mod_deflate.html">mod_deflate</a>; for nginx there is <a href="https://nginx.org/en/docs/http/ngx_http_gzip_module.html">ngx_http_gzip_module</a>; for IIS, the <code><a href="https://www.iis.net/configreference/system.webserver/httpcompression">&lt;httpCompression&gt;</a></code> element.</p>

<h2 id="Hop-by-hop_compression" name="Hop-by-hop_compression">Hop-by-hop compression</h2>

<p>Hop-by-hop compression, though similar to end-to-end compression, differs by one fundamental element: the compression doesn't happen on the resource in the server, creating a specific representation that is then transmitted, but on the body of the message between any two nodes on the path between the client and the server. Connections between successive intermediate nodes may apply a <em>different</em> compression.</p>

<p><img alt="" src="https://mdn.mozillademos.org/files/13807/HTTPTE1.png" /></p>

<p>To do this, HTTP uses a mechanism similar to the content negotiation for end-to-end compression: the node transmitting the request advertizes its will using the {{HTTPHeader("TE")}} header and the other node chooses the adequate method, applies it, and indicates its choice with the {{HTTPHeader("Transfer-Encoding")}} header.</p>

<p><img alt="" src="https://mdn.mozillademos.org/files/13809/HTTPComp2.png" /></p>

<p>In practice, hop-by-hop compression is transparent for the server and the client, and is rarely used. {{HTTPHeader("TE")}} and {{HTTPHeader("Transfer-Encoding")}} are mostly used to send a response by chunks, allowing to start transmitting a resource without knowing its length.</p>

<p>Note that using {{HTTPHeader("Transfer-Encoding")}} and compression at the hop level is so rare that most servers, like Apache, nginx, or IIS, have no easy way to configure it. Such configuration usually happens at the proxy level.</p>