Googleはこれらのフィールドの詳細をDevToolsのドキュメントの ネットワークパフォーマンスの評価 セクションに示しています。
リソースネットワークタイミング からの抜粋：
ストール/ブロッキング
要求が送信されるまでに待機していた時間。この時間には、プロキシネゴシエーションに費やされた時間が含まれています。さらに、今回はブラウザがすでに確立されている接続が再利用可能になるのを待っていて、Originごとの 最大6 TCPの接続に従っています。ルール。
（忘れた場合、Chromeのホバーツールチップと[タイミング]パネルの下に[説明]リンクがあります。）
基本的に、これが見られる主な理由は、Chromeがサーバーごとに一度に6ファイルしかダウンロードしないため、接続スロットが使用可能になるまで他の要求が停止するためです。
これは必ずしも修正が必要なものではありませんが、失速状態を回避する1つの方法は、 CORS を維持しながら、ファイルを複数のドメイン名またはサーバーに分散することです。 /あなたのニーズに当てはまるのであれば念頭に置いてください、しかしHTTP2はおそらく今後のより良いオプションです。リソースのバンドル化（JSとCSSの連結など）も、失速した接続数を減らすのに役立ちます。
DevTools：[ネットワーク]リクエストの前に空のバーを説明する
さらに調査し、ストールとキューイングの範囲に大きな違いはないことを確認しました。両方とも、netstackまたはレンダラーから提供されるのではなく、他のタイムスタンプのデルタから計算されます。
現在、ソケットが利用可能になるのを待っているならば：
- 何らかのプロキシネゴシエーションが発生した場合は失速します。
- プロキシやSSLの作業が不要な場合は、キューイングと呼びます。
これはChome-devtoolsの公式サイトから来ていて、それは役立ちます。ここで私は引用します：
- 待ち行列要求が待ち行列に入っている場合は、次のように示されます。
- 要求は重要なリソース（スクリプトやスタイルなど）より優先度が低いと見なされるため、レンダリングエンジンによって延期されました。これは画像でよく起こります。
- 解放しようとしている使用不可のTCPソケットを待つために要求が保留されました。
- ブラウザはHTTP 1上のOriginごとに6つのTCP接続しか許可しないため、要求は保留されました。
- 停止/ブロック要求が送信されるまでに待機していた時間。キューイングで説明されている理由のいずれかを待っている可能性があります。また、この時間には、プロキシネゴシエーションに費やされた時間が含まれています。
私の場合は、開いているときに、ページがさまざまなパラメータで複数のリクエストを送信しているということです。だからほとんどが「失速」しています。すぐに送信された次のリクエストは「失速」します。不必要なリクエストを避けた方がいいでしょう（怠惰になるためには…）。