JS / CSSファイルを縮小および連結し、画像にスプライトを使用しても、HTTP / 2を使用する場合にパフォーマンス上の利点はありますか？
新しいHTTP/2プロトコルにより、同じサーバーへのHTTPリクエストの繰り返しによって生じるオーバーヘッドが大幅に削減されました。
これを念頭に置いて、JavaScript/CSSファイルを縮小および連結し、画像をスプライトに結合することには、パフォーマンス上の大きな利点がありますか？または、HTTP/2が使用されている場合、これらのプラクティスはもはや有用ではありませんか？
彼らはまだ便利です。 HTTP/2はこれらのプラクティスの一部の影響を軽減しますが、それらの影響を排除しません。
最小化はこれまでと同じくらい便利です。 HTTP/2ではメッセージヘッダーに新しい圧縮が導入されていますが、それは縮小（メッセージ本文に関するもの）とは関係ありません。メッセージ本文の圧縮アルゴリズムは同じであるため、縮小により、以前と同じだけの帯域幅が節約されます。
連結とスプライトの影響は以前より少なくなりますが、影響はあります。 HTTP/1で単一のファイルではなく複数のファイルをダウンロードする場合の最大の問題は、実際にはHTTP側の問題ではありませんper se：thereis各ファイルを個別に要求する際の帯域幅ベースのオーバーヘッドがいくつかありますが、完了時にTCP/IPセッションをティアダウンする時間ベースのオーバーヘッドによって小さくなります1つのファイルを使用して、次に新しいファイルを起動し、ダウンロードするすべてのファイルに対してこれを繰り返します。
HTTP/2の最大の焦点は、時間ベースのオーバーヘッドを排除することです。HTTP/ 1.1はパイプラインを使用してこれを実行しようとしましたが、ブラウザーでキャッチされませんでした（Prestoは完全に正しく動作する唯一のエンジンであり、Prestoはデッド）。 HTTP/2は別の試みであり、HTTP/1.1のメソッドを改善すると同時に、この種のオプションを非オプションにして、より成功することを示しています。 ヘッダーを圧縮することにより、複数のリクエストを行う際の帯域幅ベースのオーバーヘッドのsomeも排除しますが、そのオーバーヘッドを完全に排除することはできません。複数のファイルをダウンロードする場合、それらの要求は依然として行われる必要があります（単一のTCP/IPセッションの一部として、オーバーヘッドは少なくなりますが、ゼロではありません）。したがって、連結とスプライトの影響は比例して小さくなりますが、特に多くのファイルを使用する場合は、依然として影響があります。
連結とスプリッティングに関して考慮するもう1つのことは、圧縮です。 類似したタイプの連結されたファイルは、個々のファイルよりも圧縮率が高い傾向があります。これは、圧縮アルゴリズムが連結されたデータ間の類似性を利用できるためです。 同様の原則がスプライトに適用されます：同じファイルの異なる領域に類似した画像を配置すると、通常、ファイルが小さくなります。これは、画像の圧縮が異なる領域の類似性を利用できるためです。
これまでのところ、すべての回答は暗黙的に、すべてのページのすべての.CSSファイルと.JSファイルをダウンロードすることを想定しています。 http/2を使用し、.CSSファイルと.JSファイルを分離しておくことの利点は、必要なファイルのみをダウンさせることができ、何かをダウンロードしない方が、効率的にダウンロードするよりも常に速いということです。
これは少し遅いかもしれませんが、カバーする必要があるいくつかの代替ポイントを指摘したいと思います。
1つ目は、ミニフィケーションは通常JavaScriptに何らかの醜化を採用することです。これは帯域幅の外でメリットがあります。これにより、コードを簡単に分析できなくなり、通常のユーザーが冗長なメソッドやアイデアを使用して悪意のあるアクションを実行できなくなります。適切に構築されたサイトでも問題が発生する可能性がありますこれとともに。もちろん、これはセキュリティに代わるものではなく、上級ユーザーはいつでも醜いコードを解読することができます。
もう1つは、すべてのブラウザまたは接続がHTTP/2を使用しているわけではないことです。少なくともすぐにではないため、HTTP/2クライアントで一部のHTTP/2機能のパフォーマンスがほとんど目立たない場合は、HTTP経由で接続しているユーザーにメリットがないのはなぜですか。 /1.1？
最後に、結局のところ、何かがサーバーの速度にどのように影響するかを判断する最善の方法は、サーバーのベンチマークを行うことです。
はい、それはまだ便利です。
Gzip圧縮を併用すると、ページの重みが軽くなります。
非常に遅いGPRS（56Kbps、500ms ping）ネットワークを使用しているとしましょう。
50個の小さな画像、30個のJavaScript、20個のCSSファイルがあります。
つまり、2つの並列接続では、リクエストのためだけに100 * 500ミリ秒以上待機する必要があります。
現在、各画像は約3〜4 kbです。どれが数ミリ秒かかるかもしれません（5-8？）。
現在、CSSファイルとJavaScriptの範囲は20Kbから600Kbです。
これはあなたのウェブサイトを巨大な転送時間で殺します。
ファイルを転送する時間を短縮すると、Webサイトがロードされる「速度」が向上します。
それで、[〜＃〜]はい[〜＃〜]、それでも便利です！
JSを縮小しても、多くのシンボルのサイズを縮小できます。 inflatedJargonSymbolizerTokenManagerは_aになります。私が見つけた1つの例は、JQuery GZippedがまだJQuery.min GZippedのサイズの2倍であることを示しました。
私はまた、あなたが他のことを示唆しなかったものの、dystroyのコメントは正しいこと、そして実際、不適切に記述されたWikipediaの説明と矛盾していることにも注意したいと思います。 JavaScriptファイルの「連結」は、今ではあまり役に立たない可能性があります。それらを縮小することには、まだその利点があります。あなたがたまたまそこにいくつかの情報を取得した場合に備えて、それを言及したかっただけです。実際、編集バトルに参加することを心配していなかった場合は、自分でページを編集しました。
CSSはシンボルを削減する機会が少ないようです。理論的には、取得できるのは空白文字とコメントの削除だけです。