新しい HTTP/2 プロトコルにより、同じサーバーへの HTTP リクエストの繰り返しによって生じるオーバーヘッドが大幅に削減されました。
これを念頭に置くと、JavaScript/CSS ファイルを縮小して連結し、画像をスプライトに結合することで、パフォーマンス上の大きな利点がまだあるのでしょうか? それとも、HTTP/2 が使用されている場合、これらの方法はもはや役に立たないのでしょうか?
ベストアンサー1
それらはまだ役に立ちます。HTTP/2はこれらの慣行の影響の一部を軽減しますが、影響を完全に排除するわけではありません。。
縮小は相変わらず有用であるHTTP/2 ではメッセージ ヘッダーの新しい圧縮が導入されていますが、これは縮小 (メッセージ本文に関するもの) とは関係ありません。メッセージ本文の圧縮アルゴリズムは同じなので、縮小によって以前と同じだけの帯域幅が節約されます。
連結とスプライトは以前よりも影響は少なくなりますが、それでもある程度の影響はあります。HTTP/1で1つのファイルではなく複数のファイルをダウンロードする場合の最大の問題は、実際にはHTTP側の問題ではなく、それ自体： そこにはは各ファイルを個別に要求する際には帯域幅ベースのオーバーヘッドが多少発生しますが、1 つのファイルの処理が完了したら TCP/IP セッションを切断し、次のファイル用に新しいセッションを開始し、ダウンロードするファイルごとにこれを繰り返すことによる時間ベースのオーバーヘッドに比べれば大したことではありません。
HTTP/2 の最大の焦点は、時間ベースのオーバーヘッドを排除することです。HTTP/1.1 では、パイプラインを使用してこれを実行しようとしましたが、ブラウザーでは普及しませんでした (Presto は、これを完全に正しく実行した唯一のエンジンですが、Presto は廃止されました)。HTTP/2 は、HTTP/1.1 の方法を改善しながら、この種のことを必須にするというもう 1 つの試みであり、より成功する見込みがあります。また、いくつかのヘッダーを圧縮することで、複数のリクエストを行う際の帯域幅ベースのオーバーヘッドを削減できますが、そのオーバーヘッドを完全に排除することはできません。また、複数のファイルをダウンロードする場合、それらのリクエストは依然として（単一のTCP/IPセッションの一部としてなので、オーバーヘッドは少なくなりますが、ゼロではありません）。そのため、連結と分割の影響は比例してサイズが小さくても、特に多くのファイルを使用する場合は、ある程度の影響が残ります。
連結とスプライト化に関して考慮すべきもう 1 つの点は、圧縮です。類似した種類のファイルを連結すると、個々のファイルよりも圧縮率が高くなる傾向がある。圧縮アルゴリズムは連結されたデータ間の類似性を利用できるためです。同様の原理がスプライトにも当てはまる: 同じファイルの異なる領域に類似した画像を配置すると、通常はファイルサイズが小さくなります。これは、画像の圧縮で異なる領域の類似性を活用できるためです。