新しい HTTP/2 プロトコルにより、同じサーバーへの HTTP リクエストの繰り返しによって生じるオーバーヘッドが大幅に削減されました。
これを念頭に置いて、JavaScript/CSS ファイルを縮小および連結し、画像をスプライトに結合することには、まだ大きなパフォーマンス上の利点がありますか? それとも、HTTP/2 が使用されている場合、これらのプラクティスはもはや役に立たないのでしょうか?
6305 次
5 に答える
49
それらはまだ役に立ちます。HTTP/2 は、これらのプラクティスの一部の影響を軽減しますが、それらの影響をなくすわけではありません。
縮小化は相変わらず便利です。HTTP/2 ではメッセージ ヘッダーに新しい圧縮が導入されていますが、これは縮小化 (メッセージ本文に関するもの) とは関係ありません。メッセージ本文の圧縮アルゴリズムは同じであるため、縮小によって以前と同じくらい多くの帯域幅が節約されます。
連結とスプライトの影響は以前より少なくなりますが、それでもある程度の影響はあります。HTTP/1 を使用して単一のファイルではなく複数のファイルをダウンロードする際の最大の問題は、実際には HTTP 側の問題ではありません。各ファイルを個別に要求すると、帯域幅ベースのオーバーヘッドが発生しますが、時間ベースの1 つのファイルを使い終わったときに TCP/IP セッションを破棄し、次のファイルのために新しいセッションを開始し、ダウンロードするファイルごとにこれを繰り返すオーバーヘッド。
HTTP/2 の最大の焦点は、その時間ベースのオーバーヘッドを排除することです。HTTP/1.1 はパイプライン処理でこれを行おうとしましたが、ブラウザーではうまくいきませんでした (Presto はそれを完全に正しく行った唯一のエンジンであり、Presto は死）。HTTP/2 は別の試みであり、HTTP/1.1 のメソッドを改善すると同時に、この種のことを非オプションにするものであり、より成功する可能性があります。また、ヘッダーを圧縮することにより、複数のリクエストを行う際の帯域幅ベースのオーバーヘッドの一部を排除しますが、そのオーバーヘッドを完全に排除することはできず、複数のファイルをダウンロードする場合は、それらのリクエストを(単一の TCP/IP セッションの一部として) 行う必要があります。であるため、オーバーヘッドは少なくなりますが、ゼロではありません)。したがって、連結とスプライトの影響は比例しますが、より小さくても、特に多くのファイルを使用する場合は、まだ影響があります。
連結とスプライトに関してもう 1 つ考慮すべきことは、圧縮です。類似したタイプの連結ファイルは、個々のファイルよりも圧縮率が高くなる傾向があります。これは、圧縮アルゴリズムが連結されたデータ間の類似性を利用できるためです。同様の原則がスプライトにも当てはまります。同じファイルの異なる領域に類似の画像を配置すると、通常はファイルが小さくなります。これは、画像の圧縮が異なる領域の類似性を利用できるためです。
于 2015-02-20T14:36:18.640 に答える
1
はい、まだ役に立ちます。
gzip 圧縮と並んで、ページの重量が軽減されます。
非常に遅い GPRS (56Kbps、500ms ping) ネットワークを使用しているとします。
50 個の小さな画像、30 個の JavaScript、および 20 個の css ファイルがあります。
つまり、2 つの並列接続では、要求だけで 100 * 500 ミリ秒以上待機する必要があります。
現在、各画像は約 3 ～ 4kb です。数ミリ秒 (5 ～ 8 秒?) かかる場合があります。
現在、CSS ファイルと Javascript の範囲は 20Kb から 600Kb です。
これにより、膨大な転送時間で Web サイトが停止します。
ファイルを転送する時間を短縮すると、Web サイトが読み込まれる「速度」が向上します。
はい、それでも役に立ちます！
于 2015-02-20T14:04:09.723 に答える