Google Chromeのネットワークパネルを使用してパフォーマンスのトラブルシューティングを行うと、さまざまな時間が表示され、それらが何を意味するのか疑問に思うことがよくあります。
誰かが私がこれらを正しく理解していることを検証できますか？
では、誰かが長いブロッキング時間をどのように修正するでしょうか？
では、誰かが長い待ち時間をどのように修正するでしょうか？
回答:
送信とは、データ/リクエストをサーバーにアップロードするために費やされる時間です。ブロッキングと待機の間に発生します。たとえば、ASPXページをポストバックすると、リクエスト（フォームの値とセッション状態を含む）をASPサーバーにアップロードするのにかかった時間が示されます。
待機とは、要求が送信されてから、サーバーからの応答が受信されるまでの時間です。基本的に、これはサーバーからの応答を待つために費やされる時間です。
受信は、サーバーから応答をダウンロードするために費やされた時間です。
ブロッキングとは、UIスレッドがリクエストを開始してからHTTPGETリクエストがネットワークに到達するまでの時間です。
これらが発生する順序は次のとおりです。
*ブロッキングとDNSルックアップが入れ替わる場合があります。
[ネットワーク]タブには、処理に費やされた時間が表示されません。
ブロッキング時間が長い場合は、ブラウザを実行しているマシンの実行速度が遅くなります。これは、マシンをアップグレードする（RAMを増やす、プロセッサを高速化するなど）か、ワークロードを減らす（不要なサービスをオフにする、プログラムを閉じるなど）ことで修正できます。
待機時間が長い場合は、サーバーがリクエストに応答するのに長い時間がかかっていることを示しています。これは次のいずれかを意味します。
2つの問題（長い待機+長いブロッキング）は関連しています。キャッシュ、新しいサーバーの追加、アクティブページに必要な作業の削減によってサーバーのワークロードを削減できる場合は、両方の領域で改善が見られるはずです。
あなたはここでグーグルチームからの詳細な公式の説明を読むことができます。これは非常に役立つリソースであり、情報はタイムラインビューセクションに表示されます。
リソースネットワークのタイミングは、タイムラインビューのリソースバーと同じ情報を表示します。あなたの質問に答える：
ブロッキング：すでに確立されている接続が再利用できるようになるのを待つためにリクエストが費やした時間。別の回答で述べたように、それはサーバーに依存しません-これはクライアントの問題です。
私は上記の声明に同意しません。他のすべてが同じ[私のマシンワークロード]-私のブラウザは、あるWebサイトの「ブロック」時間が非常に短く、他のWebサイトのブロック時間が長いことを示しています。
したがって、6つのスレッドの1つとプロキシネゴシエーション**の待機時間が長い場合は、主にサーバーの速度低下のカスケード効果またはページのデザインの悪さ[ネットワークを介して送信される回数が多すぎる]が原因です。
**-「プロキシネゴシエーション」が意味するものは何でも！、特にローカル/ CDNプロキシが実際に関与していない場合、誰もこれをうまく説明しません