圧縮効果を最大化するためのgzip、縮小、および両方の組み合わせに関するこの議論は、jQueryライブラリをHTMLファイル内に直接配置することで正味のパフォーマンス効果を得ることができるかどうか疑問に思いました。
HTTPリクエストの数を最小限に抑えるために、base64でエンコードしてCSSデータソースを介してロードするアイコンスプライトに対してすでにこれを行っています。
今私は尋ねます：公式の本番ダウンロードリンクで利用可能な生のmin + gzip形式でjQueryライブラリをロードする方が、CDNでホストされているGoogle AJAXライブラリを介してロードするよりも効率的かどうか知っていますか？
サーバー、ブラウザー、および途中の多くのノードでキャッシュできるため、常に共通のアイテム（JSライブラリなど）を外部ファイルに保持する必要があります。ページの全体的な速度を見ると、キャッシュ時間は圧縮時間または要求時間を大幅に上回ります。
この質問について考慮すべきことがいくつかあります。これが私の頭のてっぺんから外れたものです。
スクリプトとスタイルを縮小することは、常にスピードを上げるのに役立ちます。ここで議論することはあまりないと思います。
圧縮（およびブラウザーでの抽出）にはオーバーヘッドがあります。gzipモジュールを起動すると、リクエストの送信に時間がかかるため、小さなファイルやバイナリファイル（画像など）の場合は、通常、gzipをスキップすることをお勧めします。ただし、大きくてほとんどがASCIIで構成されているもの（JSライブラリなど）は、圧縮するのが良いので、チェックアウトしてください。
HTTPリクエストを減らすことは、一般的には良いことです。ただし、HTTP 1.1（すべての主要なブラウザでサポートされている）以降、新しいHTTPリクエストは新しいソケット接続を意味しないことに注意してください。を使用keep-aliveすると、同じソケット接続でWebページとすべての関連ファイルを一度に提供できます。リクエストの唯一の余分なオーバーヘッドは、リクエストヘッダーとレスポンスヘッダーです。これは、小さな画像やスクリプトがたくさんない限り、無視できる程度です。これらのファイルがCookieのないドメインから提供されていることを確認してください。
ポイント3に関連して、ページにコンテンツを埋め込むことにはHTTPリクエストを減らすという利点がありますが、ページ自体のサイズを増やすという欠点もあります。JSライブラリのような大きなものの場合、ライブラリのサイズは、追加のファイルに必要なHTTPオーバーヘッドのサイズを大幅に上回ります。
ここにキッカーがあります。ライブラリがページに埋め込まれている場合、キャッシュされることはほとんどありません。手始めに、ほとんどの（すべて？）主要なブラウザはデフォルトでメインのHTMLページをキャッシュしません。CACHE-CONTROL必要に応じてページヘッダーにメタタグを追加できますが、それがオプションでない場合もあります。さらに、そのページがキャッシュされている場合でも、残りのページ（おそらくライブラリも使用している）もキャッシュする必要があります。突然、JSライブラリの多くのコピーを含むサイト全体がユーザーのマシンにキャッシュされましたが、それはおそらくユーザーにしたいことではありません。一方、JSライブラリを外部ファイルとして使用している場合、特に（@Barmarが言うように）ライブラリがGoogleなどの一般的なCDNからロードされている場合は、それ自体を1回だけキャッシュできます。
最後に、キャッシュはクライアントのブラウザでのみ発生するわけではありません。エンタープライズレベルのサービスを実行している場合は、共有キャッシュと個別キャッシュを備えた複数のサーバープール、目がくらむほどの速度のCDNキャッシュ、ドメインに向かう途中のプロキシキャッシュ、さらには一部のルーターやその他のデバイスのLANキャッシュが存在する可能性があります。そこで、一番上にあるTL; DRに戻ります。つまり、（特にブラウザーで）キャッシュすることで得られるスピードアップは、遭遇する可能性のある他の考慮事項よりも優先されます。
お役に立てば幸いです。