Chromeで次のネットワークログを取得しました。
理解できないことが1つあります。塗りつぶされた灰色のバーと透明な灰色のバーの違いは何ですか。
回答:
Googleは、DevToolsのドキュメントの「ネットワークパフォーマンスの評価」セクションでこれらのフィールドの内訳を示しています。
ストール/ブロッキング
リクエストが送信される前に、リクエストが待機に費やした時間。この時間には、プロキシネゴシエーションに費やされた時間も含まれます。さらに、この時間には、ブラウザーが既に確立されている接続が再利用できるようになるのを待っているときも含まれ、発信元のルールごとにChromeの最大6つの TCP接続に従います。
（忘れた場合、Chromeのホバーツールチップと[タイミング]パネルの下に[説明]リンクがあります。）
基本的に、これが表示される主な理由は、Chromeではサーバーごとに一度に6ファイルしかダウンロードされず、他のリクエストは接続スロットが利用可能になるまで停止されるためです。
これは必ずしも修正が必要なことではありませんが、ストール状態を回避する1つの方法は、複数のドメイン名やサーバーにファイルを分散し、必要に応じてCORSを考慮に入れておくことですが、HTTP2がおそらくより良いオプションです。今後。リソースのバンドル（JSやCSSの連結など）も、停止した接続の量を減らすのに役立ちます。
file:///C:/...
DevTools：[ネットワーク]リクエストに先行する空のバーを説明します
さらに調査したところ、ストールとキューイングの範囲に大きな違いはないことがわかりました。どちらも、ネットスタックまたはレンダラーから提供されるのではなく、他のタイムスタンプのデルタから計算されます。
現在、ソケットが利用可能になるのを待っている場合：
- プロキシネゴシエーションが発生した場合は、ストールと呼びます
- プロキシ/ SSLの作業が不要な場合は、キューイングと呼びます。
これはChome-devtoolsの公式サイトからのもので、役立ちます。ここで私は引用します：
- キューイング リクエストがキューに入れられている場合、次のことを示しています。
- 重要なリソース（スクリプトやスタイルなど）よりも優先度が低いと見なされているため、リクエストはレンダリングエンジンによって延期されました。これは画像でよく起こります。
- 解放しようとしている使用できないTCPソケットを待機するために、要求が保留にされました。
- ブラウザーはHTTP 1のオリジンごとに6つのTCP接続しか許可しないため、要求は保留されました。ディスクキャッシュエントリの作成に費やされた時間（通常は非常に高速です）。
- 停止/ブロッキング 時間リクエストが送信される前に待機していた時間。キューイングについて説明されている理由のいずれかを待っている可能性があります。さらに、この時間には、プロキシネゴシエーションに費やされた時間も含まれます。
遅いウェブサイトをデバッグしている多くの人々がここに到着したので、Googleの説明で解決できなかった私のケースについてお知らせします。Windowsで実行されているApacheが接続を処理するにはワーカースレッドが少なすぎて、キューに入れられていたことが原因で、非常に長い時間（場合によっては1分）が滞っていました。
これは、Apacheログに次の注記がある場合に当てはまる可能性があります。
Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting
この問題はApache httpd.confで解決されています。コメント解除： conf / extra / httpd-mpm.confを含めます
そしてhttpd-mpm.confを編集します
<IfModule mpm_winnt_module>
ThreadLimit 2000
ThreadsPerChild 2000
MaxConnectionsPerChild 0
</IfModule>
2000スレッドが必要ない場合や、それ以上必要な場合があります。私の場合、2000年は問題ありませんでした。