並行CSSダウンロードによりWebサイトのパフォーマンスを改善しますか？

ウェブサイトのページ読み込み時間を最適化していました。その方法の1つは、CSSの複数のHTTP要求を1つの結合HTTP要求に結合することでした。しかし、レビュアーの1人が興味深い質問をしました。複数のCSSファイルのダウンロードを並列化することで、ページの読み込み時間が短縮されないでしょうか？

インターネットで読んだ唯一のことは、（ブロックする）HTTPリクエストの数を減らすことがWebページを高速化するための鍵であるということです（ただし、Google Pagespeed Insightsはこれを明確に述べていないようです1）。

並列化によってパフォーマンスが改善されない、またはほとんど問題にならない（いくつかのHTTPリクエストを使用する利点に勝る）理由がいくつかあります。

新しい接続のセットアップには費用がかかります。複数の接続のセットアップは並行して行うことができますが、ブラウザーは最大で約4〜6の接続を使用するため（ブラウザーによって異なります）、CSSを並行してダウンロードするとJavaScriptや画像などの他のアセットのダウンロードがブロックされます。
HTTPS接続を設定するには、いくつかの追加データが必要です。これは簡単に数KBのデータになる可能性があります。これは、実際に送信したいCSSの代わりに、ネットワーク経由で送信する必要がある追加データです。
TCPスロースタートアルゴリズムにより、接続を介して送信されるデータが多いほど、接続は高速になります。そのため、実際に接続が長く接続されていると、新しい接続よりもはるかに速くデータが送信されます。たとえば、単一の接続を使用してページの読み込み時間を改善するSPDYプロトコルを参照してください。
TCPは抽象化です。まだ（通常）基礎となる接続は1つだけです。そのため、複数の要求が使用されている場合でも、回線を介して送信されるデータは、速度を向上させるために複数の接続から必ずしも恩恵を受けるとは限りません。
インターネット接続は、特にモバイルでは本質的に信頼できません。1つの要求が他の要求よりも大幅に速く終了する場合があります。CSSに複数のリクエストを使用するということは、最後のリクエストが完了するまでWebページのレンダリングがブロックされることを意味します。これは、平均的な接続よりもかなり遅れる場合があります。

それでは、CSSファイルのHTTPリクエストを並列化することに何か利点はありますか？

注/更新：すべてのCSSファイルはレンダーブロックです。まだクリティカルパスの外に移動されていないCSSファイル。

css performance

— アイケ
ソース

etsyのコードで、静的オブジェクト（css、img、js）に単一のcookielessドメインを使用することを推奨するクラフトサイトとして何かを見ました。最新のブラウザは、単一ドメインからの並行ダウンロードで素晴らしい仕事をすることがわかりました。同じドメインの複数のファイル（10個のcssファイルと1個の大きなファイル）については、1つの大きなファイルを結合して縮小し、1つの要求を作成する方が良いと思います。特にあなたのサイトが正しく見えるためにすべてのCSSを必要とするCSSで特に。

— フランク14

ある意味では、使用可能な接続の数に基づいて、ブラウザーは既に並行してダウンロードしています。ブラウザが読み込んでいるHTMLに基づいています。

— 日

HTMLドキュメントからリンクされたCSSファイルは、HTMLの解析時に並列ダウンロードキューに追加されます。重要なのは、非同期のJavaScriptリンクがHTMLパーサーをブロックし、そのJavaScriptがダウンロード、解析、実行されるまで、後のタグがダウンロードキューに追加されないようにすることです。^[1]

ブラウザに4つのファイルのうち3つを順番に（少なくとも3回の往復）強制的にダウンロードさせる例を次に示します。

<head>
  <script src="js/fizz.js"></script>
  <link rel="stylesheet" href="css/foo.css"/>
  <script src="js/buzz.js"></script>
  <link rel="stylesheet" href="css/bar.css"/>
</head>

以下の例は、4つのファイルすべてが並行して（少なくとも1回の往復）ダウンロードされるように作り直されています。

<head>
  <link rel="stylesheet" href="css/foo.css"/>
  <link rel="stylesheet" href="css/bar.css"/>
  <script async src="js/fizz.js"></script>
  <script src="js/buzz.js"></script>
</head>

別の注意：CSSファイルは（デフォルトでは）パーサーブロックではなくレンダーブロックです。ページは引き続き解析され、DOMが構築されますが、CSSOMが構築されるまでレンダリングは開始されません。

CSSを分割する主な理由は、スクロールせずに見えるコンテンツをクライアントにレンダリングし、できるだけ早く解析するために必要な最小限のルールを取得することです。すぐに表示されないもののための残りのルールmediaは、リンクタグ内のクエリで不必要にレンダリングをブロックするようにマークするか、非同期に読み込まれたJavaScriptによってページに追加できます。

そのため、CSSのダウンロードを並列化しても、それ自体のために明確な利点はありません。しかし、いつものように、測定してテストしてください！

さらに読むには、Googleの「Web Fundamentals：Optimizing Performance」に関する次の記事をお勧めします：https : //developers.google.com/web/fundamentals/performance/

[1]：これは、一部のブラウザーの投機解析機能を無視しています：

https://docs.google.com/document/d/1JQZXrONw1RrjrdD_Z9jq1ZKsHguh8UVGHY_MZgE63II/preview?hl=en-GB&forcehl=1

https://developer.mozilla.org/en-US/docs/Web/HTML/Optimizing_your_pages_for_speculative_parsing

— ロバート・K・ベル
ソース

同時にダウンロードするスクリプトを維持する方法についてのもう一つの良い読み取りは、ここにある：stackoverflow.com/questions/436411/...

— joshreesjones

すべての.jsファイルは、コードの最後でbodyの終了タグの直前にリンクする必要があり、そのように何もブロックしないことに注意してください。

— チャオリー14年

「だから、CSSのダウンロードをそれ自体のために並列化することには明確な利点はありません」私はどういうわけか上記の答えからそれを理解できませんでした

— -gaurav5430

@ gaurav5430 cssファイルを分割する理由は、スクロールせずに見える範囲での最適化（そしてキャッシュの最適化かもしれません）を超えているようには見えません

— ロバートK.ベル